views:

1329

answers:

3

I have a relatively simple support application which I have chosen to deploy to our support staff via click once.

I assume it's still called Click-Once. I'm using the publish tab of the project's properties in VS2008.

Several users have managed to click through to the url, download and run the application.

One specific user cannot.

He has .Net 3.5 SP1 installed and indeed reaches the publish page where he is offered the option to install. upon clicking this he is greeted with an error message

The error message contains the following phrases

  • Cannot start Application
  • Application download did not succeed
  • check your network connection or contact your system administrator Network service Provider
  • No connection could be made because the target machine actively refused it

I would love to know what might be causing this...

I cannot understand why the server I have published to, would treat this user differently.

Any ideas?

A: 

He's not even to the point where he is installing the application. Things to try: a) Give the user the link to the .application file instead of to the setup.exe and see if that helps at all (probably not). b) Turn off the user's firewall and try it again. If this works, you need to figure out how to get through the firewall. c) Are you protecting the ClickOnce deployment files on the server by giving specific users access to it? If so, this guy doesn't have it. d) Create another user account on the same machine and try installing the application. Does it work? Then it's something funky about this guy's profile.

RobinDotNet
+1  A: 

One thing to consider is clearing the users application cache. I've run into this problem a number of times and it seems that for some reason ClickOnce apps can become corrupted and they don't have a mechanism to fix themselves.

For Vista the app cache is located at C:\Users\\AppData\Local\Apps\2.0. After that it becomes a bunch of random folder names (like NXJW1HVZ.DQH). I've had luck in just deleting the 2.0 directory. Any installed applications will get reinstalled the next time the user opens them from the web.

WARNING! Deleting everything could delete data associated with an installed app so you might want to be more surgical than just deleting everything (if you dig through the folders a bit you'll find your app).

Brian
Thanks for the suggestion. We tried this but continued to have the same error.
Rory Becker
+1  A: 

Ask your user to click on the Details... button and send you the full contents in an e-mail. In the ERROR SUMMARY section you'll probably see something like the following:

CASE 1: Following failure messages were detected: + Downloading APPLICATION_FILE_URL did not succeed. + The remote server returned an error: (407) Proxy Authentication Required.

The user should have been getting prompted with a Proxy Authentication Required dialog, but if they didn't see it then your proxy server is returning NON-STANDARD responses. Basically you need to bore it up your proxy server's vendor to fix their broken software, but you might be able to get the user around the problem by having them edit their workstation's MACHINE.CONFIG file to include the following:

<configuration> <system.net> <settings> <httpWebRequest useUnsafeHeaderParsing="true" /> </settings> </system.web> </configuration>

CASE 2: Following failure messages were detected: + Downloading APPLICATION_FILE_URL did not succeed. + The remote server returned an error: (403) Forbidden.

This usually means that the origin server (your web server hosting the application) is actively refusing your user access. This is due to either: 1. IP ADDRESS RESTRICTIONS - if it's an internal corporate web server this is likely. If you have an IP Address-restricted web site find out your user's IP (assuming it's static) and add it to the access list. 2. FILE SYSTEM PERMISSIONS - another common one on internal corporate servers. Find out what (group/)username your user is authenticating to your server with and ensure that the .application file and all contents of that directory (including the directory itself) have correct permissions for his account.

Hope this helps!