Take the 2-minute tour ×

I have several .NET Windows Forms applications that I'm preparing to convert into a ClickOnce/smart-client deployment scenario. I've read the isn't-this-great tutorials, but are there pitfalls or "gotchas" that I should be aware of?

There are several minor applications used off and on, but the main application is in C#, runs 24/7, is quite large, but only changes every few weeks. It also writes to a log file locallly and talks to local hardware devices.

share|improve this question

closed as not constructive by templatetypedef, gnat, competent_tech, Troy Alford, raven Jan 3 '13 at 0:52


closed as 'not constructive' - yet the answers to this question were extremely helpful to me...in deciding not to use ClickOnce deployment ;) –  Steven A. Lowe Dec 4 '13 at 19:27
I read many people complaining about clickonce, things have changed since then, dont let these answer intimidate you, it is easy to set up and has good advantages –  meda Sep 25 at 20:01

11 Answers 11

up vote 12 down vote accepted

Here are a few that I am aware of.

  1. Can't put an icon on the desktop. You can now.

  2. I can't install for all users.

  3. I need to jump through hoops to move the deployment to a different server. It is not a problem if you are developing internally, and the users can see the server that you are publishing to or if you are deploying to the public web, but it is not great if you need to roll out to multiple customer sites independently.

  4. Since .NET 3.5 SP1 you do not need to sign the deployment manifest anymore which makes it much easier to move deployments to new servers.

  5. I can't install assemblies in the GAC. You can get around this by creating regular install packages that are pre-requisites of the ClickOnce application.

share|improve this answer
Can't change expired signing key (without reinstall) unless you're on .NET 3.5 SP1. –  romkyns Jan 13 '10 at 19:56
Actually, you CAN move it to a different server just by publishing it with a new update URL (see robindotnet.wordpress.com/2010/01/17/…;. And you can install assemblies in the GAC by putting them into a setup & deployment package and deploying them as a prerequisite. –  RobinDotNet Aug 7 '10 at 6:59
@RobinDotNet It is not exactly easy to publish from our build environment directly to multiple customer's internal server. Anyway, .net3.5 sp1 fixed all my problems by removing the signing requirement. –  Darrel Miller Aug 7 '10 at 14:30
@RobinDotNet Does a user need admin privileges to install the pre-requisites? –  Darrel Miller Aug 7 '10 at 14:31
Yes, a user DOES need admin privileges to install the prerequisites –  RobinDotNet Aug 8 '10 at 16:35
  • When updates are deployed, the built-in dialog will make it appears as if the entire application is being re-downloaded. In fact, only the changed DLLs are being downloaded, and the progress bar displayed is misleading/wrong. Don't waste time trying to figure out why all the assemblies are being re-deployed only to discover that they actually aren't. Not that I did that or anything.
  • When the certificate that you used to sign the original deployment manifest expires and you are issued a new one, you're in for a world of hurt (clients will all need to uninstall and reinstall). Details are at the horse's mouth.
share|improve this answer

Most issues have been addressed but several people mentioned not being able to create a desktop shortcut. In fact, you can create a desktop shortcut with Visual Studio 2008 SP1.

Also, if you aren't using the latest version of Visual Studio, you can always write code to create a shortcut to the installed start menu shortcut.

share|improve this answer
Though, sadly, it won't be uninstalled cleanly. –  romkyns Jan 13 '10 at 19:57

We had an app we were going to deploy as a ClickOnce app. We needed the user to be able to modify some settings in the installation (such as the deployment path - IT wants to serve the files from their network share, not known at build time). When you change any of the files in your deployment, you need to re-calculate all of the hashes, and re-sign everything. So, if this solution is internal, you may not have problems passing around a signing cert, but if this is for clients, you will need to architect a fancy solution to bypass this issue.

I have heard rumblings from somewhere within the bowels of the internets that a future version of ClickOnce will remove some of this headache.

share|improve this answer
I hope the rumblings you hear are correct...this is a huge issue for us! –  Aaron Mar 28 '09 at 16:44

You can't silently uninstall ClickOnce deployed applications. Also I think it's impossible to add parameters to the startup shortcut.

share|improve this answer

One of the pitfalls with ClickOnce is the fact that you can't install to the GAC. This is a problem if you want to install multiple applications that share DLL files. Each application will require a local copy of the DLL files. Also, multiple user installs are out. See the list comparing Window Installer to ClickOnce.

share|improve this answer
If the dll's are strongly named, ClickOnce caches them. So if you have multiple applications that use the same dll (we have several, including log4net), ClickOnce will keep just one copy of it in the cache. –  RobinDotNet Aug 7 '10 at 7:00

There's a whole lot of things you can't do with ClickOnce apps, like install a shortcut to the user's desktop or have any sayso in where the app gets installed. For some people these are dealbreakers.

Also it's been a while since I used it but there's a special way you can use to figure out and display the ClickOnce version/build number, which is separate from the application's version/build number. You have to do a try/catch and if the ClickOnce version/build number throws an exception then the app is not running as a ClickOnce-deployed app (i.e., it's running as a regularly compiled app or from Visual Studio).

For an app which is simple (i.e., not Microsoft Word but rather a quick-and-dirty app to do something) and needs a lot of regular deployment, ClickOnce is great. But you rather quickly hit the wall of "oh, this can't be done by ClickOnce, please choose MSI or something else).

share|improve this answer
Rather than use Try/Catch while attempting to get the deployed version number, wrap it in an "If System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed Then . . ." Much cleaner. If it's network deployed, you can get the version. If not, you can't. Easy-peasy :) –  Kevin Fairchild Jan 9 '09 at 20:11

You'll have less system access than your normal .NET app.

That's because you'll get a lower trust level, more about that: .NET Framework Developer's Guide: ClickOnce Deployment and Security

My biggest problem with that was that It's not possible to encrypt sections of your config file with the machine key, because you don't have the access to that key (when you think about it it makes sense to protect that key).

share|improve this answer
Hmm, not sure ... you can request a higher trust level, the user may just get a warning dialog. You can encrypt the sections of the config file in code on the first run, but not during deployment, because that's the deployment machine's key, not the client's, which the client can't read. –  Nicholas Piasecki Nov 16 '08 at 4:36
Correct, but to decrypt it you'd always have to have a higher trust level.... –  Davy Landman Nov 16 '08 at 18:35

I didn't know that SP1 allowed you to create the desktop icon. Here's how we have been doing it (now known as "the hard way"):

            string company = string.Empty;
            string product = string.Empty;
            if (Attribute.IsDefined(asm, typeof(AssemblyCompanyAttribute)))
                AssemblyCompanyAttribute asCompany = (AssemblyCompanyAttribute)Attribute.GetCustomAttribute(asm, typeof(AssemblyCompanyAttribute));
                company = asCompany.Company;
            if (Attribute.IsDefined(asm, typeof(AssemblyProductAttribute)))
                AssemblyProductAttribute asProduct = (AssemblyProductAttribute)Attribute.GetCustomAttribute(asm, typeof(AssemblyProductAttribute));
                product = asProduct.Product;
            if (!string.IsNullOrEmpty(company) && !string.IsNullOrEmpty(product))
                string desktopPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Desktop),
                    product + ".appref-ms");
                string shortcutPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Programs),
                    Path.Combine(company, product + ".appref-ms"));
                File.Copy(shortcutPath, desktopPath, true);
            // Shortcut could not be created
share|improve this answer

In case someone refers to this in a search, we have found many customers concerned with the lack of security 'distributing' their application. The application must be available in a public location - without any authentication - for it to be able to check for updates. The only exception is if you have Windows NT authentication. I think Securing ClickOnce Applications explains what I mean.

Desktop icons are fairly trivial to do via code, and as mentioned, with 3.5 SP1, baked in - so that is no longer an issue.

There is still an unfixed bug with the xmlSerializer - it doesn't get deployed properly in some cases. An easy workaround is to manually add this file to the deployment. PITA, but it is easy enough... It can be shocking when your deployment suddenly fails though...

share|improve this answer

You can't install if the client is behind a proxy that requires authentication.

share|improve this answer
Yes you can. There's a workaround. Check out the end of this thread: social.msdn.microsoft.com/Forums/en/winformssetup/thread/… –  RobinDotNet Aug 7 '10 at 7:01
Hi Robin, if you're refering to your own post there - that's limited to upgrading only is it not? My comment was regarding the initial install, which you said yourself you then have to do by USB/CD, etc. with this workaround. I actually stumbled across that post the other day while working on this issue, and was temporarily excited as a solution. But for an internet deployed app like ours (qiqqa.com) it doesn't really help unfortunately. –  Nik Aug 9 '10 at 9:30
