Thursday, October 15, 2009

ClickOnce Deployment Problems

We have recently moved to ClickOnce for all our application deployment needs, and it is fantastic in so many ways, but there are still some scenarios where it fails. I will collect these together in one post and keep it up-to-date as new information becomes available. If anyone else has any ClickOnce war-stories, please add them to the comments.

Useful Links



MSDN Server and Client Configuration Issues in ClickOnce Deployments

ClickOnce and Setup & Deployment Projects MSDN forum.

RobinDotNet's Blog has some useful tips, including .NET 4.0 logging. Robin is an MVP and ClickOnce forum moderator.

Proxy Servers



UPDATE: Thanks to Robin for this link to a fix for the proxy issue.

If your customers are behind an authenticated proxy server, ClickOnce may fail to work. This is because the authentication settings are usually stored in Internet Explorer, but the ClickOnce deployment libraries (System.Deployment.Application) do not use them by default. The bug is documented here, but opinion varies about whether it should be fixed or not: Microsoft says it shouldn't, everybody else says it should.

When it goes wrong a typical error report looks like this:


PLATFORM VERSION INFO
Windows : 5.2.3790.131072 (Win32NT)
Common Language Runtime : 2.0.50727.3053
System.Deployment.dll : 2.0.50727.3053 (netfxsp.050727-3000)
mscorwks.dll : 2.0.50727.3053 (netfxsp.050727-3000)
dfdll.dll : 2.0.50727.3053 (netfxsp.050727-3000)
dfshim.dll : 2.0.50727.3053 (netfxsp.050727-3000)

SOURCES
Deployment url : http://overtureonline.com/Applications/Keima/Overture/Overture.application

ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of http://OvertureOnline.com/Applications/Keima/Overture/Overture.application resulted in exception. Following failure messages were detected:
+ Downloading http://overtureonline.com/Applications/Keima/Overture/Overture.application did not succeed.
+ The remote server returned an error: (407) Proxy Authentication Required.

COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.

WARNINGS
There were no warnings during this operation.

OPERATION PROGRESS STATUS
* [25/09/2009 15:59:15] : Activation of http://OvertureOnline.com/Applications/Keima/Overture/Overture.application has started.

ERROR DETAILS
Following errors were detected during this operation.
* [25/09/2009 15:59:16] System.Deployment.Application.DeploymentDownloadException (Unknown subtype)
- Downloading http://overtureonline.com/Applications/Keima/Overture/Overture.application did not succeed.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)
at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
at System.Deployment.Application.FileDownloader.Download(SubscriptionState subState)
at System.Deployment.Application.DownloadManager.DownloadManifestAsRawFile(Uri& sourceUri, String targetPath, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
--- Inner Exception ---
System.Net.WebException
- The remote server returned an error: (407) Proxy Authentication Required.
- Source: System
- Stack trace:
at System.Net.HttpWebRequest.GetResponse()
at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)

COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.


A smart customer of ours actually found an answer: she ran an NTLM proxy, but we shouldn't expect all our customers to be computer geniuses.

The recommended solution is for the customer to edit their machine.config file - I can't see how that could possibly go badly ;-)

Internet Explorer Security


If the Internet Explorer security option "Run components not signed with Authenticode" option is set to "Disable", then your .application file will not work. The reason why would be clearer if the wording was "Run components not signed with Authenticode certificates that I trust", because even if your installer is actually signed, it is not necessarily a trusted publisher on the customers machine.

The error looks like this:


PLATFORM VERSION INFO
Windows : 6.0.6001.65536 (Win32NT)
Common Language Runtime : 4.0.20506.1
System.Deployment.dll : 4.0.20506.1 (Beta1.020506-0100)
clr.dll : 4.0.20506.1 (Beta1.020506-0100)
dfdll.dll : 4.0.20506.1 (Beta1.020506-0100)
dfshim.dll : 4.0.20428.1 (Beta1.020428-0100)

SOURCES
Deployment url : http://cadenza.keima.co.uk/Applications/Keima/Test/ConsoleApplicationClickOnce/ConsoleApplicationClickOnce.application
Server : Microsoft-IIS/7.0
X-Powered-By : ASP.NET

ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of http://cadenza.keima.co.uk/Applications/Keima/Test/ConsoleApplicationClickOnce/ConsoleApplicationClickOnce.application resulted in exception. Following failure messages were detected:
+ Your Web browser settings do not allow you to run unsigned applications.

COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.

WARNINGS
There were no warnings during this operation.

OPERATION PROGRESS STATUS
* [10/15/2009 3:21:06 PM] : Activation of http://cadenza.keima.co.uk/Applications/Keima/Test/ConsoleApplicationClickOnce/ConsoleApplicationClickOnce.application has started.

ERROR DETAILS
Following errors were detected during this operation.
* [10/15/2009 3:21:06 PM] System.Deployment.Application.InvalidDeploymentException (Manifest)
- Your Web browser settings do not allow you to run unsigned applications.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.ApplicationActivator.BrowserSettings.Validate(String manifestPath)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.


I don't know of any tidy workaround for this. If the client installs your certificate prior to product installation then it will work, but then it's no longer ClickOnce is it? One might argue that they asked for this by changing the setting, but it is more likely that their IT department did it and they know nothing about it. The irony is that if you run the bootstrap setup.exe, as you must from browsers like Chrome, then it works fine, but this means you are forcing clients to run a full-trust executable instead of a potentially low-trust .application file.

UPDATE: Robin points out in the comments below that this is an IE6 only issue.

Missing Local Files


A ClickOnce install puts files in a special folder called Apps (%localappdata%\Apps on Vista at least). I'm not sure the exact purpose of all of the folders and files, but I do know if you delete some of them it can cause web-launch failures. For instance, I installed a simple application, deleted the folder which held the application binary files and then tried to relaunch the application. This failed with the following message:


PLATFORM VERSION INFO
Windows : 6.0.6001.65536 (Win32NT)
Common Language Runtime : 4.0.20506.1
System.Deployment.dll : 4.0.20506.1 (Beta1.020506-0100)
clr.dll : 4.0.20506.1 (Beta1.020506-0100)
dfdll.dll : 4.0.20506.1 (Beta1.020506-0100)
dfshim.dll : 4.0.20428.1 (Beta1.020428-0100)

SOURCES
Deployment url : http://cadenza.keima.co.uk/Applications/Keima/Test/ConsoleApplicationClickOnce/ConsoleApplicationClickOnce.application
Server : Microsoft-IIS/7.0
X-Powered-By : ASP.NET

IDENTITIES
Deployment Identity : ConsoleApplicationClickOnce.application, Version=1.0.0.1, Culture=neutral, PublicKeyToken=39bbeb210852ebe6, processorArchitecture=msil

APPLICATION SUMMARY
* Online only application.

ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of http://cadenza.keima.co.uk/Applications/Keima/Test/ConsoleApplicationClickOnce/ConsoleApplicationClickOnce.application resulted in exception. Following failure messages were detected:
+ The directory name is invalid. (Exception from HRESULT: 0x8007010B)

COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.

WARNINGS
There were no warnings during this operation.

OPERATION PROGRESS STATUS
* [10/15/2009 3:32:28 PM] : Activation of http://cadenza.keima.co.uk/Applications/Keima/Test/ConsoleApplicationClickOnce/ConsoleApplicationClickOnce.application has started.
* [10/15/2009 3:32:28 PM] : Processing of deployment manifest has successfully completed.

ERROR DETAILS
Following errors were detected during this operation.
* [10/15/2009 3:32:28 PM] System.Runtime.InteropServices.COMException
- The directory name is invalid. (Exception from HRESULT: 0x8007010B)
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.NativeMethods.CorLaunchApplication(UInt32 hostType, String applicationFullName, Int32 manifestPathsCount, String[] manifestPaths, Int32 activationDataCount, String[] activationData, PROCESS_INFORMATION processInformation)
at System.Deployment.Application.ComponentStore.ActivateApplication(DefinitionAppId appId, String activationParameter, Boolean useActivationParameter)
at System.Deployment.Application.SubscriptionStore.ActivateApplication(DefinitionAppId appId, String activationParameter, Boolean useActivationParameter)
at System.Deployment.Application.ApplicationActivator.Activate(DefinitionAppId appId, AssemblyManifest appManifest, String activationParameter, Boolean useActivationParameter)
at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

COMPONENT STORE TRANSACTION DETAILS
* Transaction at [10/15/2009 3:32:28 PM]
+ System.Deployment.Internal.Isolation.StoreOperationSetDeploymentMetadata
- Status: Set
- HRESULT: 0x0
+ System.Deployment.Internal.Isolation.StoreTransactionOperationType (27)
- HRESULT: 0x0


Thanks to Russell Christopher for blogging the only solution I have found that works: delete everything in the Apps folder. This should be safe given that ClickOnce applications repair themselves if completely removed. Apart from Start Menu shortcuts, they are completely defined by the files on the disk (I think).

Obviously this is the clients fault for messing with the files in the first place, but I was surprised it didn't repair itself.

Plain Text / XML .application File


Pathology: When the .application file is clicked, the browser shows the plain text XML file instead of launching the ClickOnce installer.

I only get this problem with IE6, and in my case it is a MIME issue. My server labels .application files with the generic application/octet-stream MIME types, and IE6 doesn't do a good job at deducing the correct type by inspecting the content.

It appears that IE7 and above have more sophisticated ways of resolving the .application file MIME than simply looking at the MIME type that the server reports, which is often difficult or impossible to change for exotic types like application/x-ms-application if you don't have root access to the server. In this case, you can serve up the EXE bootstrapper instead of the .application file to anyone with IE6.

Clue 1: Probably a server MIME encoding issue.
Clue 2: More evidence of MIME encoding.

The ClickOnce Graveyard


Here lies all the problems I am currently experiencing for which I do not have a definitive solution. As they are resolved, I will move them up into the body of the main article.

Setup EXE Bootstrapper Fails to Launch


Pathology: On a virgin XP installation, the EXE bootstrapper fails to launch.

Clues: Saving the bootstrapper and launching it manually throws a dialog with the following example text:

Unable to satisfy all prerequisites for [Application]. Setup cannot continue until all system components have been successfully installed.

Prerequisite check for system component .NET Framework 3.5 SP1 failed with the following error message:
"Installation of the .NET Framework 3.5 SP1 requires Windows XP SP2, Windows 2003 SP1, Windows Vista, or later. Contact your application vendor."

See the setup log file located at
[Log file location]

This doesn't happen on XP SP2 or above, but I don't know how to make this a prerequisite. More to the point, I don't know how to throw a friendly dialog if this prerequisite is not met.

8 comments:

Unknown said...

Hi im arby, how do i reproduce this error "Proxy server issue" ? because i will be testing hotfix from microsoft.

Rupert said...

Hi Arby,

I'm not sure. We never managed to reproduce the issue on the bench because we couldn't match the customers proxy setup closely enough. If you manage it, please post some info.

Unknown said...

Okay... thanks rupert, i will post info if ever i reproduce this error.

RobinDotNet said...

Just want to let you know there is a solution to the proxy authentication capability. Here's a link to the thread in the forum, which has info at the bottom about the workaround. http://social.msdn.microsoft.com/Forums/en/winformssetup/thread/3e9cebad-9630-4bbc-a0ca-0d2f20335454
This is also referenced in a pinned post at the top of the MSDN ClickOnce and Setup & Deployment Forum.

Also, the 'not signed with authenticode' problem only occurs with IE6. It works fine with IE7 and IE8 now.

Rupert said...

Thanks Robin. I've updated my post to reflect your comments.

Interesting thread you linked to; it is hard to believe the ClickOnce folks hadn't heard of the proxy issue! Their product manager needs to buy you a beer and find out where all the pain-points are.

Unknown said...

Hi Robin and Rupert,

Thanks for the additional information about the IE6. All i did was to focus on the proxy setting setup and never thought about the IE version. It is hard to reproduce the error. It sure helps a lot! I will try IE6 and reproduce the error.

Jamie Snell said...

I've had issues with ClickOnce and people using mobile broadband modems. The broadband modem tends to compress image files, and the MD5 hash will fail when it downloads them. I haven't figured out a solution other then adding them as embedded resources or having the user use a non-mobile broadband connection

Rupert said...

@Jamie That's a tricky one! My mobile provider also re-compresses images over their mobile data service, but I've never used it as a modem for a ClickOnce install.

I would have assumed that the operator detects image from the MIME type the web server reports, but all ClickOnce .deploy files should have the application/octet-stream MIME type. You could check this is true (I always use Fiddler). If so, then they must sniff out the file type from the data stream itself, in which case your options might be limited.