none
ClickOnce Fails to Detect .NET Framework 4.0 Client Profile on x64 Machine

    Question

  • Hello Friend,

    I've decided to use ClickOnce technology to deploy my new WPF application. By and large, ClickOnce works as advertised but I've hit a minor glitch regarding Bootstrapping and framework detection.

    Some background:
    - I'm using the standard Visual Studio-generated publish.htm page as my launch page.
    - The only prerequisite is the .NET Framework 4.0 Client Profile.
    - All clients using IE 8.
    - All clients already have the .NET 4.0 Client Profile installed.
     
    ClickOnce works as advertised on the vast majority of machines. The VS-generated JScript correctly detects that the framework is installed and presents the user with a Run button. The app launches just fine.

    I'm getting odd results on one of the machines, however. On the offending machine, the VS-generated JScript tells the user that the prereqs may not be installed -- or rather, it FAILS to detect that the framework is already installed. The "launch" link successfully launches the application but the Run link points to the bootstrapper setup.exe. Why is it failing to detect the framework on this one machine?

    It occurred to me that framework detection is largely a matter of examining the useragent string that's submitted by the browser. So, what you see below are two UserAgent strings. The first is from a machine where things are working properly. The second is from the offending machine.

    THIS ONE WORKS:
    2011-01-11 15:14:14 W3SVC1 192.168.0.36 GET /publish.htm - 80 - 72.130.187.100 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.0;+Trident/4.0;+SLCC1;+.NET+CLR+2.0.50727;+Media+Center+PC+5.0;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+.NET4.0C) 304 0 0

    THIS ONE DOESN'T:
    2011-01-11 18:49:12 W3SVC1 192.168.0.36 GET /publish.htm - 80 - 76.212.204.169 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.1;+WOW64;+Trident/4.0;+GTB6.6;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C) 200 0 0

    The useragent string of both machines clearly states, "hey the .NET 4.0 client profile is installed here" -- yet the second machine seems unable to detect it.  I don't know enough about useragent strings to understand why the former works and the latter fails. The only difference as far as I can tell is that the offending machine is running 64bit. But that shouldn't make a difference. Should it? Any ideas?

    Dexter Morgan

     


    Jules Winfield
    • Moved by Bob_BaoMVP, Moderator Wednesday, January 12, 2011 1:59 AM (From:Windows Presentation Foundation (WPF))
    Tuesday, January 11, 2011 11:30 PM

Answers

  • PROBLEM SOLVED!

    I took a close look at the publish.htm file that VS.NET generates. There's an error in the JScript code. The offending line is:

    checkClient=false;

    I changed the line to read:

    checkClient=true;

    Unless this line of code is changed, the browser won't bother to check if the .NET 4.0 Client Profile is installed and as a result, a user who already has installed the 4.0 Client Profile will always be presented with an unnecessary list of prerequisites.

    The bad line of code must be the result of some error in the VS.NET publishing logic. Hopefully MSFT will fix. Until then, you'll have to correct it by hand every time you run the publish wizard. Ugh.


    Jules Winfield
    Friday, January 14, 2011 1:01 AM

All replies

  • Hi,

    I've seen this before on one of my machines, and yet both machines have very similar specs. I don't know if it uses the user agent string. You'd probably have to do a lot of trial & error to figure out exactly why this works differently on each machine.

    I think the question you have to ask yourself is how much time and effort do you want to put into it? Ultimately it doesn't matter. Even if the user clicks on [Install], it won't reinstall the prerequisites, it will check for them and then continue with the ClickOnce part of the application.

    The other thing you could do is make your own attractive publish page without the version number or prerequisites listed, and link an install button to the Setup.exe file.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Wednesday, January 12, 2011 9:46 AM
  • The other thing you could do is make your own attractive publish page without the version number or prerequisites listed, and link an install button to the Setup.exe file.

    The problem is that my application will eventually be deployed to Internet users who may or may not have the Framework installed. So it's pretty important that the framework detection mechanism works. I didn't mention this in my original post because I thought it would be helpful to narrow down the scope of my question by using a test case where everyone already had the Framework installed.

    You make a valid point that even if the user does have the Framework installed and clicks the Setup.exe link anyway, the program will eventually launch. But only after setup.exe is downloaded and it does its own detection, shows popups, etc.

    Not a deal-killer but definitely bums me out. :(

     


    Jules Winfield
    Wednesday, January 12, 2011 8:29 PM
  • The problem is the web page, not the setup.exe (bootstrapper). If the webpage is wrong and doesn't mention .NET 4, and the user hits the Install button, it will still run the .NET Framework check, and will download and install it.

    You still might think of making a more attractive publish page. We actually have an aspx page that detects the browser and provides different directions for Firefox versus IE. Here's an example: http://www.goldmail.com/install/publish2.aspx

    Does it make you feel better knowing it's the publish.htm page and not the actual bootstrapper that has the problem?

    RobinDotNet

     


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Thursday, January 13, 2011 6:45 AM
  • The problem is the web page, not the setup.exe (bootstrapper). If the webpage is wrong and doesn't mention .NET 4, and the user hits the Install button, it will still run the .NET Framework check, and will download and install it.

    You still might think of making a more attractive publish page. We actually have an aspx page that detects the browser and provides different directions for Firefox versus IE. Here's an example: http://www.goldmail.com/install/publish2.aspx

    Does it make you feel better knowing it's the publish.htm page and not the actual bootstrapper that has the problem?

    RobinDotNet

     


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev


    Yes, I suppose it does since the web page can be changed but the bootstrapper can't. I'll check out your sample page.

    I'll most certainly want to make a more attractive publish page. But to do that, I need to understand the logic of the VS-generated page and more specifically, what it's currently doing wrong. So it sounds like you're saying there is some flaw in the JScript on that page that's preventing it from properly detecting the Framework?

     


    Jules Winfield
    Thursday, January 13, 2011 2:18 PM
  • PROBLEM SOLVED!

    I took a close look at the publish.htm file that VS.NET generates. There's an error in the JScript code. The offending line is:

    checkClient=false;

    I changed the line to read:

    checkClient=true;

    Unless this line of code is changed, the browser won't bother to check if the .NET 4.0 Client Profile is installed and as a result, a user who already has installed the 4.0 Client Profile will always be presented with an unnecessary list of prerequisites.

    The bad line of code must be the result of some error in the VS.NET publishing logic. Hopefully MSFT will fix. Until then, you'll have to correct it by hand every time you run the publish wizard. Ugh.


    Jules Winfield
    Friday, January 14, 2011 1:01 AM
  • Does anybody know if this problem will be fixed? Finding this solution was hard enough; having to manually download the .htm file after publishing, then edit it, then upload it back again, does spoil the idea of "ClickOnce" in my opinion.

    Wednesday, June 08, 2011 1:22 PM
  • I'll ask Microsoft.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Friday, June 10, 2011 3:54 AM