views:

1958

answers:

6

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

There are 2 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 url like ".../client.application?document=doc1" i can only have a link to setup.exe.

The other problem is 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 to install the framework, 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.

My questions are : 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 config file or something) ?

I'm new to clickonce deployment, and i haven't understand yet what and how i can do with it.

Any suggestion is welcome.

+1  A: 

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

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.

Dag
A: 

Perhaps NAnt could be leverage to Automate the change of the deployment URL. I use it to automate my Clickonce Builds and change the Build version of the manifest. Here is how I did it. ClickOnce with Nant

Aaron
A: 

If the users are on a domain then I would have the sysadmin push .net 3.5 out using GP's / 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 sysadmin 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 your back to your manual solution. Also, doing it manually doesn't necessarily break 'all the advantages of click once'... The advantages for Click Once 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 GP's that get's .NET 3.5 as well, that would be very simple.

Good luck,

Gary

Gary
+2  A: 

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...

GrendleM
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
alfred barthand
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.
GrendleM
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.
jpierson
A: 

Second question:

You can use the msbuild publish target on a proj, 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 or 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 GP scripts or WMI.

Solracnapod
A: 

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;

Tony