Clickonce trying to install Package DotNetFX48 when it is already installed RRS feed

  • Question

  • Hi,

    We have migrated one of our applications that is installed via ClickOnce to use .Net Framework 4.8. We changed the publishing settings to need .Net Framework 4.8. Now, in a couple of machines we are unable to install the application. When starting, it checks if the framework is installed, it decides it is not (when in fact it is installed), and when trying to install it fails (because the framework is already installed), aborting the installation of our application. The same installation works in other machines.

    Analyzing both scenarios, these are the differences:

    - The machines working are running Windows 7 SP1, and there we installed first the .Net Framework 4.8 runtime, and then the 4.8 developer pack.

    - In the machines not working we are running Windows 10 and we just installed the developer pack, not the runtime (which we guess is included in the other installation)

    Looking at the log of the installation, comparing the one from a machine where is working against the one of a machine not working, we can see that the "Product.xml" file in the DotNetFx48 folder is checking if this entry is present in the registry:

    <RegistryCheck Property="DotNetFull_MSPDetection" Key="HKLM\SOFTWARE\Microsoft\Updates\Microsoft .NET Framework 4.8\KB4503575" Value="ThisVersionInstalled" />

    It turns out that the entry is missing in the machines having the problem, and it is present in the ones working correctly.

    Is this some kind of bug? Is is not enough to have installed the developer pack, and we need to install first the runtime?

    Thanks you in advance.

    Friday, September 20, 2019 10:01 AM

All replies

  • Hi,

    Have you tried to add package in "Prerequisites", select "Download from component vendor's website" and republish it?



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Monday, September 23, 2019 2:23 AM
  • Hi Kyle,

    Yes, we have it like that in the project configuration and we get the behaviour I described. I think we have narrowed the issue. The problem is that, despite this entry being present in the machine registry:

    <RegistryCheck Property="DotNetFull_Win10BX86Identity" Key="HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_for_KB4486153~31bf3856ad364e35~amd64~~" Value="CurrentState" />

    the clickonce installation fails to read it. Text from the install.log:

    "Reading value 'CurrentState' of registry key 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_for_KB4486153~31bf3856ad364e35~amd64~~'
    Unable to read registry value
    Not setting value for property 'DotNetFull_Win10BX86Identity'"

    I thought it might be related to the installation process not having permissions accessing the registry, but in the same log there are registry entries successfully read:

    "Running checks for package 'Microsoft .NET Framework 4.8 (x86 and x64)', phase BuildList
    Reading value 'Release' of registry key 'HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full'
    Read integer value 528049"



    Monday, September 23, 2019 7:43 AM
  • The problem with the registry entry seems to be that the setup.exe file with the clickonce installation is a 32 bit application. So it might be looking in:

    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Component Based Servicing...

    And such "Component Based Servicing" does not exist in the WOW6432Node branch.

    Maybe it is a bug in the DotNetFX48 Product.xml file. I'm thinking about filing a bug report.



    Monday, September 23, 2019 11:11 AM
  • We are experiencing exactly the same problem, Windows 7 Setup working and Windows 10 Setup failing with almost identical log file like yours (but with .NET 4.7.2 references instead of 4.8, since we target 4.7.2) - please let us know if you managed to find a solution!
    Monday, September 23, 2019 12:48 PM
  • Hi,

    I filed a bug report. I explained a little bit longer why I think it is failing both in 4.7.2 and 4.8. Here is the link just in case you want to follow the evolution:



    Monday, September 23, 2019 1:13 PM