ClickOnce deployment issues

Question

I'm working on a project deployed with ClickOnce, and I'm running through several issues.

There are two components in my software solution: a desktop client which needs .NET framework 3.5 to run, and a server (ASP.NET application) which lists available documents and provides a way to install the desktop client with ClickOnce.

My first problem is the prerequisites' one: I need a way to install the 3.5 framework prior to the client installation. Visual studio creates a setup.exe which takes care of that, but in order to make it work, it has to be run directly (instead of linking to the .application file), and the deployment URL has to be known when creating the ClickOnce manifest.

So I have two more problems: there is apparently no way to run the client application with query string arguments after installing it with setup.exe, so instead of having a server displaying the documents list linking to a URL like ".../client.application?document=doc1" I can only have a link to setup.exe.

The other problem is the worst: the server is intended to be used in relatively small private networks, and not on a single web server. The problem is: I do not know the deployment URL of the ClickOnce client at build time, so the setup.exe cannot run properly when the "install from a web site" option is checked. For now, the workaround is to have an offline installer which contains the setup.exe, prerequisites and the ClickOnce deployment files in a big ZIP file.

An user with the proper framework version can still use the .application link with querystring to the document to install/update the client and open the document. An user without the framework gets an error message ("System update required blablabla 3.5.0.0 blabla GAC"), and has to download the ZIP file, extracts it to his local machine and run the setup.exe file to install the framework, and then the client. And after that, he has to go back to the documents list and use the link to launch the client with proper arguments.

Needless to say, I'm not very proud of this strategy, which ruins all ClickOnce deployment advantages.

Is it possible to get rid of the prerequisites issue in a more elegant way? Is there a simple way to modify the installation URL of the ClickOnce application when deploying the server in a network (like writing the URL in a configuration file or something)?

Bemire

about the prerequisites, i had to change the url used to lookup the downloaded files ("setup.exe -url=my.application.com") it didn't work at the first try with prerequisites downloaded from the same location as my application because of the webserver config : mime types were not registered for msp and msu, so the setup.exe couldn't get the prerequisites files – Bemire

A small suggestion is to try to ask single questions on StackOverflow as it is easier for people to read through and address. Also it's hard to accept partial answers which makes it unfair to those who may want to assist you. If you need to provide more context you can link to your other questions to help give some background on the array of issues your facing. – Vahe

Answer 1

I too have been trying to solve the "I do not know the deployment URL of the clickonce client at build time" problem.

The best I can come up (I just started writing it so this is still speculation) is to write a utility that the end-user will run that will set the deploymentURL. This appears to be possible in .NET but you need to:

• Read in the manifest with ManifestReader.ReadManifest
• set the DeploymentUrl
• ManifestWriter.WriteManifest

Then you have to sign the manifest again using SecurityUtilities.SignFile

The signing process bothers me. Either I have to use a throwaway certificate (which makes the signing meaningless) or I need to use a cert from a CA and then I have to distribute my password in order to resign the manifest (which is stupid since it makes my cert insecure). So I seem to be left with the user seeing "Unknown Publisher" and a Yellow exclamation mark...

Discommon

thanks ! i wasn't sure if i could distribute mage.exe with my application, but your solution is simpler and better ! about the yellow exclamation mark : as far as it works, i'm fine with it – Bemire

redistributing mage is likely not allowed. It doesn't seem to be in any list of MS redistributables that I can find. MS is pretty strict about what can and cannot be redistributed. – Discommon

I've basically have had the same issue with having to decide to use my own self generated cert or a trusted cert. Another option that I've considered and left open is for customers to provide their own cert when gets used by my ASP.NET based deployment server which is responsible for resigning and re-branding and all of that. So at least our customers still have options but it's unfortunate we can't just use options like the "Use application manifest for trust" option and still have some custom branding in the deployment manifest. If you don't need to rebrand then I would suggest that option. – Vahe

For any lost souls who wander by here, mage.exe and mageui.exe are listed as redistributable in Windows SDK v7.1. – Romaic

Answer 2

In order to build ClickOnce applications in our continuous build system and deploy to several test servers, I spent some time with Mage and the article Walkthrough: Manually Deploying a ClickOnce Application.

I am not sure if this will solve your second problem, but it might at least take some pain out of the build process if you deploy to multiple servers. If you can distribute mage.exe (not sure if Microsoft allows it), you can modify your manifests on-site during installation.

Concur

Answer 3

Maybe a solution would be:

Use PublishUrl=http://clickonce/is/kinda/cool and on the client computer alter the Windows hosts file located on
%windir%\system32\drivers\etc\hosts and point the host clickonce to the fixed IP address of the server.

Maybe ClickOnce should have an option to detect the server where the application was downloaded from; If somebody knows please post here;

Elmore

Answer 4

Perhaps NAnt could be leveraged to automate the change of the deployment URL. I use it to automate my ClickOnce builds and change the build version of the manifest. ClickOnce with NAnt describes how I did it.

Haldis

The "ClickOnce with NAnt" link is broken. – Preliminaries

This appears to be the new url: aaronsprague.com/blog/post/Automate-ClickOnce-with-Nant.aspx – Cheeseparing

Answer 5

If the users are on a domain then I would have the sysadmin push .NET 3.5 out using Group Policies / Windows Update or whatever other strategy is being used to manage the desktops.

It does sound like an environment issue. If the organization is large enough to have a system administrator then it should be that person's responsibility to provide an environment for the application to run.

If the organization doesn't have a person in this role then I do believe you're back to your manual solution. Also, doing it manually doesn't necessarily break 'all the advantages of ClickOnce'... The advantages for ClickOnce is that you can modify the client, republish and the client machines will automatically upgrade...

I suppose the other option is to write a script that gets and installs .NET 3.5 and then installs the application, I haven't done this before... I'm reasonably sure it would work... Actually, you could deploy a startup script via Group Policies that gets .NET 3.5 as well, that would be very simple.

Disenthral

Answer 6

Second question:

You can use the MSBuild publish target on a project, solution, or MSBuild file like so:

C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe "C:\path\foo.vbproj" /target:Publish /property:"PublishUrl=http://clickonce/is/kinda/cool/" /property:"PublishUrl=http://clickonce/is/kinda/cool/" 

PublishUrl is the location where the application will be published to in the IDE. It is inserted into the ClickOnce application manifest if neither the InstallUrl nor UpdateUrl property is specified.

InstallUrl (not shown) is the location where users will install the application from. If specified, this value is burned into the setup.exe bootstrapper if the IsWebBootstrapper property is enabled. It is also inserted into the application manifest if the UpdateUrl is not specified.

First question:

If the above answer doesn't take care of your needs, then it seems to me that you are facing a typical problem; how does one get a Windows executable (in your case the .NET Framework 3.5) installed on multiple desktops. There are multiple solutions like Group Policy (GP) scripts or WMI.

Damal