Parameters in ClickOnce

Question

Is it possible in any possible way to add to/change the .application file (or another way) of a ClickOnce deploy file to allow parameters to be specified without the need for the parameters to be passed via the URL?

The assembly may be compiled at run time/re-signed/etc, or stated otherwise, I am not worried about the bounds of "what else" I would have to do.

Answer 1

No, I don't think this can be done. You might consider putting the parameters in the app.exe.config file and reading them with the System.Configuration.ConfigurationManager class in your application.

You can use the mageui SDK tool to re-sign the application and deployment manifests once you have changed the contents of the .config file.

Answer 2

Take a look at these two links for a really thorough analysis of what and how you can communicate between the website from which you launch the clickonce app and the app itself.

• Securing ClickOnce Deployments
• Make ClickOnce Work With ASP.NET Forms Authentication

The basic technique is to dynamically modify the manifest file(s) on the web server from which the application is launched, (and remember that those manifest files need to be re-signed after they're changed).

Although, it still would not allow you to pass "parameters" per se, you might be able to simulate "parameters" by dynamically including an additional config file that your app can read at startup.

Answer 3

I asked this question to the ClickOnce product team last month, and they said it can be done. Assuming you are targeting .NET 3.5 SP-1, you can pass arguments in to the appref-ms file (the shortcut on the start menu).

MyApp.appref-ms "my arguments"

Then you can retrieve them using this:

string[] activationData = AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData;

Answer 4

Another approach might be to load what ever parameters/configuration you need via a web service call (or similar) when the application starts up.

That way you can centrally control the parameters, rather than having them embedded in the application.

You can always implement some kind of local caching if you don't want the performance hit of a web service call every time you launch the application.