ClickOnce is harder than it seems
We’re using ClickOnce to deploy the windows forms client that I’m currently working on. ClickOnce is sweet, its awesome to not have to worry about updating your users’ applications, knowing they will get updated the next time they run them, but thats not to say that it doesn’t have its drawbacks.
One problem I ran into was the issue of .config files. In our app we have some settings stored in the app.config file. We want to have different settings for our development environments from the production environments. The problem is that once you’ve created a ClickOnce deployment, you can’t modify the files, otherwise the hash codes won’t match anymore and ClickOnce will refuse to install the application. After doing some digging and not finding much, we just have separate .config files for development vs. deployment, which is usually the case, but using ClickOnce basically means that you can’t modify the files once they’re deployed, or so it seems. You can’t just build from Visual Studio and put the files out there, you really need to have a separate build environment setup. I think I’m going to setup an automated build that will generate the ClickOnce deployment files so that we can alleviate this problem. (I know, I know, we should be doing this anyways I’m just pointing out that its got some barrier to entry sometimes).
One thing that is nice about ClickOnce is the portability of the deployment files. You have several publishing options, File System, Web Site, FTP site, etc. Since the files need to go from our environment to the client’s environment behind a VPN and firewall, we can’t simply publish the files right out there, we have to publish them locally, then copy the files over to their web server. Its nice that you can simply copy the files over and it just works, no extra steps neccessary.
Since we are developing a windows forms app, we are taking advantage of encrypting app settings that .net 2.0 introduces, but more on that later.
Anonymous said,
Wrote on April 16, 2006 @ 7:13 pm
Am I the only person who thinks that ClickOnce is a piece of crap?
breichelt said,
Wrote on April 16, 2006 @ 8:16 pm
why do you think ClickOnce is a piece of crap?
Anonymous said,
Wrote on April 17, 2006 @ 11:46 am
I think overall ClickOnce is “good enough” but definately there are areas for improvement. I understand that it does not allow you to change config files since it creates a hash with all the files included in publish. Once thing you can do is to remove the app.config from the Application files and add manually. And as far as copying files around goes you can setup a frontpage extension at the web server have a login and publish directly to it. It will save the copying process.
I have
Anonymous said,
Wrote on April 17, 2006 @ 11:49 am
Check out Mage/MageUI.. They might help…
http://coolthingoftheday.blogspot.com/2006/04/mageui-can-be-your-clickonce-stage-to.html
Anonymous said,
Wrote on April 18, 2006 @ 8:53 am
It amazes me that you can not add existing files to the list of Application Files that get deployed. For example, one of my cab modules contains an xslt that needs deployed, so I was forced to add a linked file in my main executable project.
Anonymous said,
Wrote on April 21, 2006 @ 5:03 am
It’s great for rapid/agile development and deployment into UAT, but useless for production deployment & configuration management. No-one wants to open up VS and republish just to change a config file setting - it’s no better than hardcoding settings as constants within the assembly.
Perhaps a clickonce admin tool (or a clickonce setup project) would be the answer - something much simpler than mageUI that even our admins could use.
breichelt said,
Wrote on April 21, 2006 @ 8:55 am
Sam, I totally agree with you, its a huge pain in the ass to change config settings once its deployed. I definitely got more than I bargained for
Anonymous said,
Wrote on May 4, 2006 @ 9:08 pm
You might find this helpful: http://blog.gatosoft.com/PermaLink,guid,d0a0dd1e-c9ac-4fa9-a408-615454d49702.aspx
Shylesh C said,
Wrote on December 23, 2008 @ 5:45 am
If you really want to edit/replace the config files, please dont create hash values for those files. This may help you to solve your problem. But on the other hand, you will not be able to sign your deployment manifest with a publisher certificate.
Thank you
Neil Arnold said,
Wrote on March 20, 2009 @ 8:03 am
I may be missing something, but in this case what is the point of .exe.config files?
I can enter some application settings into them, which get deployed with the application. Great, however on most production systems the settings will change dependant upon the environment. As an example, I connect to a database for storage - the connection string changes for every deployment I have, but is the same for every user. I don’t want the users changing the settings themselves thus don’t want to put it into user settings, I would have thought the .exe.config file was perfect for it, edit on deploy then update the app through click once. But no, clickonce will overwrite the .exe.config file when it updates, thus what’s the point? I may as well hard code the settings into the exe itself if the settings can’t be edited once deployed? Or am I missing something?
Neil.