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