What’s New in ClickOnce Deployment in .NET 4.0

There are some cool new features in .NET 4.0 and VS2010 for ClickOnce deployment. I’m going to summarize the new features here and provide some links to the details.

The ClickOnce engine has been updated and strengthened, and the team that supports the runtime says that the errors that seem to have no solution, such as "dfsvc.exe has stopped working", should be fixed. They have also added enhanced logging and the option to set the location (and name) of the ClickOnce log file — no more searching through your Temp folder! What’s cool about these changes is that they apply if you install .NET 4.0 on the computer, regardless of the version your application targets. So if you have a Windows Forms application that targets .NET 2.0 and you are having problems installing it, you can install .NET 4.0 on the computer and turn on the verbose logging. This has already been useful to me, so I will blog about it next.

They have fixed “the certificate problem” in all cases. The problem is discussed in detail here. The basic problem was that when you changed the certificate used to sign the ClickOnce deployment, the customers would have to uninstall and reinstall the application. They fixed this in .NET 3.5 SP-1 if you used automatic updates, but not for programmatic updates, and not for VSTO projects. Now they have fixed it in all cases when targeting the .NET 4.0 Framework.

With VS2010, you can configure your application to target multiple versions of the .NET Framework. Of course, this doesn’t mean it will run on multiple versions – you will have to verify that yourself. To use this feature, you have to manually edit the manifest files and app.config file and re-sign the manifests. For details, click here.

For XBAP applications (browser-hosted WPF applications), these can now elevate to Full Trust just like any other ClickOnce application. For more info, check out this article.

For VSTO projects, you can now deploy multiple Office solutions together with one ClickOnce installation. Like the Three Musketeers, it’s all for one and one for all. All of them are installed together, and if you uninstall through Programs, it uninstalls all of them. 

For VSTO projects, you also now have the ability to do some post-deployment actions. For example, you can create registry keys, modify a config file, or copy a document to the end user computer.

Another interesting change for VSTO projects is if you are targeting the .NET 4.0 Framework, you no longer have to include the Primary Interop Assemblies as a prerequisite. The type information for the PIAs that you use in your add-in is embedded into the solution assembly and used at runtime instead of the PIAs.

And last, but not least — in .NET 3.5 SP-1, they quietly introduced the ability to create your own custom UI for your ClickOnce deployment, while still using the ClickOnce engine to install and update your application. They have improved this feature for .NET 4.0; check out the walkthrough example here.

I think there’s something useful in the new features for everyone. If there are other features you would like to see – other than “install for all users”, which is a complete paradigm shift – please leave a comment. I will summarize the requests and pass them on to the ClickOnce team at Microsoft.


47 Responses to “What’s New in ClickOnce Deployment in .NET 4.0”

  1. Vaxman2 Says:

    If only you could change the processor type (AnyCPU -> x86) without deinstall/reinstall..

    • robindotnet Says:

      Oh yeah, I know; I learned the hard way that the target CPU is part of the identity of the application, so updates won’t work. Early on in the life of GoldMail, I had this brilliant idea of changing my company’s desktop application to target x86 so it would work on a 64-bit machine. I deployed a new version, and sent out an e-mail noting the new version was available. Within about 3 minutes, I got phone calls from several of the Powers That Be (starting with the CEO and the chairman…) telling me their update failed and they could no longer run the application. Thank goodness you can roll back a deployment by taking the earlier version of the deployment manifest (the .application file) and putting it in the top folder of the webserver folder! I had a bad couple of minutes there, but at least it was a quick recovery.
      We did finally migrate our application and changed the processor as well as some other things (assembly name). To push this to the customers, we had our application programmatically uninstall itself and install a new version with the new settings. It was pretty painless.

      • Girish Khemani Says:

        This is the same problem i.e. Any CPU to x86 type change that we are dealing with currently.

        You mentioned this –

        “We did finally migrate our application and changed the processor as well as some other things (assembly name). To push this to the customers, we had our application programmatically uninstall itself and install a new version with the new settings. It was pretty painless.”

        Can you please help me with more technical details of your solution, how you uinstalled current app and installed new one seamlessely.

        • robindotnet Says:

          This MSDN article about certificate expiration includes the code I used for uninstalling and reinstalling our application. I am still using this code when I need it. The only change I have made to it is that I no longer bother retrieving the publickeytoken, I just check the DisplayName in the registry entry for the uninstall string for a match to my ClickOnce application’s ProductName. You’ll see what I’m talking about when you look at the code — it’s just a little simpler. I realized that we don’t ever have two ClickOnce apps with the same product name.

          • Matthew Says:

            What happens though if there are user specific config settings that you would like to keep? I assume that the automated uninstalling and reinstalling of the app will blow those user settings away? Is there an easy way to persist those settings between the two apps?

          • robindotnet Says:

            You are correct, those settings are blown away if you store them the way that ClickOnce stores them by default. You should check out this article, which tells you how to keep your data safe from ClickOnce updates. This will persist your settings even if the user uninstalls and reinstalls. The down side is there’s no way to clean those files up if the user uninstalls permanently, so that’s the tradeoff.

  2. Windows Client Developer Roundup for 5/24/2010 - Pete Brown's 10rem.net Says:

    […] What's new in ClickOnce Deployment in .NET 4 (RobinDotNet) […]

  3. kevin Says:

    Regarding creating your own custom UI, I think I’m missing something. The walthrough indicates that you can modify your ClickOnce application to use the InPlaceHostingManager stuff to download and install. But how does that code get executed? Wouldn’t it have to be called from an already-deployed app? What am I missing here?

    • robindotnet Says:

      Hi Kevin,

      Did you know this feature was available in .NET 3.5 SP-1? I did, but I couldn’t find any info about how to implement it. So when I heard they had beefed it up in 4.0, I was pretty excited. I’ve taken a look at it though, and you’re right.

      So I talked to the ClickOnce Product Lead about it today. Basically, you have to create an unmanaged exe file that will check and make sure the .NET Framework is installed, and then call a managed component (small .NET app) that will call the InPlaceHosting manager. Because the real issue is the install, isn’t it? Doing updates — you could do those by calling the ClickOnce API, and put whatever UI you want on them.

      The problem is the link in MSDN is the reference documentation, and they really need a white paper. So I volunteered to write one, and if/when I do that, I will post it on my blog here. They have to shake free some resources on the ClickOnce side to provide some information, so I don’t know when they will be. When I have more information, I’ll post it here though.


  4. Bronumski Says:

    Intereseted to read about the post install hook but what I am really after is a post uninstall hook.

    • robindotnet Says:

      Everybody would like a post-uninstall hook. I’ve mentioned that to the ClickOnce product lead more than once. I’d like to do clean-up of some cached files we write to LocalApplicationData. What would you like to use it for? (The more feedback I can provide to him, the better.)

      • bronumski Says:

        Sorry I have been in the middle of a move and must have missed your response.

        The requirement was for a project at a previous company. The application downloaded a large amount of data from the net for use on the client (up to 10 gigs depending on the users access and what they content they wanted). Initially we had the content download to the users click once data folder but this caused problems during upgrades as the content had to be copied from the old folder to the new folder.

        To resolve this we left the client SqlCe database in the ClickOnce data folder so that rollbacks were possible but put the downloaded data in the users windows profile data folder but this meant that the content was not removed after doing an uninstall. Essentially the same reason as yours.

        Apart from a post install hook the only other thing I could think of is a data folder that is consistent for all versions of an installed application.

      • bronumski Says:

        What I didn’t make clear was that when copying the data between the old and new data folders was that it took a very long time. This was made worse by the fact it is done when the application starts up after doing the upgrade and you have no opportunity for a UI hook to show some kind of progress.

  5. Nuwan Says:

    I’d like to see an uninstall hook too. The main reason is that I create some additional shortcuts in the start menu (since ClickOnce supports only one link), and need to remove them on uninstall.

    Actually, the reason I need these additional shortcuts in the first place is because ClickOnce doesn’t support multiple executables in a project. As a workaround, we’ve merged our executables into one main exe and launch the appropriate startup window based on command line parameters. The shortcuts create the illusion that there are several applications. Ideally though, ClickOnce should support multiple executables with shortcuts per executable.

    • robindotnet Says:

      I agree about the uninstall hook; I’ll pass your other request on to the C/O team.

      • JohnZ Says:

        I just stumbled to your blog looking for some feature of click once that I fear it is not supported (yet).
        Anyway, about the topic at hand I think that is worth mentioning that MS (rightfully) claims that the custom ‘post install’ step is called both on installs and uninstalls. The arguments supplied to your custom code provide information about what is actually happening. The unfortunate thing is that post install/uninstall steps are currently supported for office solution. So, unless you have a way for your app to mimic an office solution and provide a .vsto manifest (and even then IMHO believe that you have an ugly scar to your installation process) you are out of luck

  6. John Amerisun Says:

    One thing that the ClickOnce Deployments is sorely missing is the ability to publish the application to different environments. We have a Development, Quality Assurance, User Acceptance and Production environment. With the 2008 (3.5) version of ClickOnce I had to modify the .proj file and put my own custom directives to facilitate different publishing locations per environment.

    I don’t see or read anywhere that the new ClickOnce addresses this, although I read somewhere before they put the VS2010 beta that it would have this feature? It would be great to have this clarified, and if it does have it how to use it, and if it doesn’t Microsoft should know this is a big feature that I think most bigger companies sorely need.

    • robindotnet Says:

      Hi John, Thanks for your feedback. You’re right, it would be nice if this was easier to handle. I know that Microsoft is aware of this, and I suspect at some point in the future they will do something about it, maybe with the next version of Visual Studio. I don’t have any firm facts that I can share about that.

      I think most people handle this by using scripts to do the builds, like mage or msbuild.

      You can have different app.config files for each environment that get incorporated according to environment as well. This article explains how to handle the different app.configs.

      That’s about the best I can offer right now. If I hear anything else, I’ll blog about it.

    • bronumski Says:

      We dealt with this same issue. I think when you start doing things like this you cannot have one size fits all which is why there is no easy tool to do this with as what I need for my environments may not work for yours.

      Anyway to get this to work for use we used MSBuild within our CI environment (TeamCity). I am a little hazy on the details but it went something like this:

      1 – Any checkin kicked of the main build and test runner as you would for any CI

      2 – A successful build was then elagable to be used in the QA publish build. This was an MSBuild project that used the same sources from step 1. This project took in an environment variable which indecated which properties to import which were then used in turn to tweak the applications configuration followed by an MSBuild task that ran the applications project fill with the “publish” target. This resulted in a published output which could then be coped to the QA deployment environment.

      3 – When we were ready to release to UAT the UAT publish build was called. This used the most resent succesfull build (or possibly pinned build) from the QA publish build and called the same MSBuild project as in step 2 but instead passed in the UAT environment variable.

      4 – Again this chained from the previous build but used the Live environment variable.

      NB One thing you do need to do is use a different certificate to sign with for each environment. We used internal certificates for dev, QA and UAT and valid certificate for Live.

      This may sound complicated but really there wasn’t much to the actual build files it is really just understanding your own requirements and implementing it.

      The only thing that I felt was lacking was the ability to re use artifacts generated in the first build. The problem I had with trying to do this was that I could not reuse the application manifest because the configuration file had changed and the check sum was no longer valid. With a little more time I think the build process could have been cleaned up so that the MSBuild task didn’t need to be used to call the publish target on the applications project file.

      Hopefully I have been clear but if I have left any gaps please say.

    • George Gomez Says:

      Here is a blog post that walks thru deploying the same version of the application to Dev, QA and Production environments using ClickOnce. I hope it helps. Thanks.


  7. tim Says:

    Can we have a automatic name other than setup.exe? (w/o going through msbuild or self-renaming)

  8. Alex V Says:

    Hi, I would like to know with a better walktrough how to use the custom UI clickonce feature. Actually I dont get it. Does this feature replace the “Publish” option in the properties section of the project?. I mean, i create a simple windows form project with a form and a button that fires a MessageBox saying “Hello World”. I want to customize its clickonce instalation. What I understand is that if I custom it I dont need to do a publish from Visual studio, the installation will be done by my custom code… but here is the question…. where doest the installation execution will be located because if I do that in Program.cs then when does the real application will be fired. Actually its very confusing, Does any one has any project or example on how to do this I would really appreciate it. Thanks a lot

    • robindotnet Says:

      I would really like to know how to do this, too, and have pinged the ClickOnce team about it without a lot of success. Here is what they said: You have to create an exe and run it as setup.exe. The gotcha is that you really need to create this in unmanaged code, like C or C++, or it will require the .NET Framework in order to run, and you can’t run your program and check for the .NET Framework if it is a .NET application. So the basic idea is that you are creating your own setup, and you need an unmanaged component that hands off to the managed component. He thought there was some kind of “configurator tool” on Codeplex or Code Gallery, but I couldn’t find it. I’ll ping them about it again, but the information is definitely scarce. I’m sorry I can’t help you more.

  9. Kevin Warner Says:

    I have a VSTO Document Customization that I want to make available Department wide, but I only want a few (2-3) people to actually be able to install and use it. The individuals who would be able to use the document would change periodically using an XML file to check usage credentials, so I would have to check their userId when the document starts up if they already have it installed.
    My question is, how do I stop the installation if they are not on the allowed list? There is no sense having them install it if they are not going to be able to use it.
    I am already using a Post-Deployment Action, is there such a thing as a Pre-Deployment Action? Or maybe have the install fail during the post-deployment action with a custom fault?
    Thanks for any help,
    Kevin Warner

    • robindotnet Says:

      Unfortunately, there is no pre-deployment action, unless you can figure out something clever to do with the bootstrapper, such as create a prerequisite that fails if it’s not the people you want to have the application isntalled. There is only one sure way to protect a ClickOnce deployment from being installed, and that is to set the protection on the deployment manifest (.application file) in the top folder of the deployment on the web server or on the network share on which the deployment resides. (Neither is practical for a public application such as the one my company has, but can be used on an intranet inside a company.)

      Why do you want to make it available department-wide, but only have a couple of people be able to use it? Why not just provide it to those 2-3 people?


  10. Tom Says:

    It would be nice to have a setting, or mode, that would eliminate the need to “sign” assemblies when an application is installed on an Intranet where security is not an issue. Sometimes source code is not available to sign 3rd party assemblies. In this case, the whole plan of doing ClickOnce is dead just due to this one issue.

    I think more developers, like myself, would like to use ClickOnce, but the many issues related to security, the change in the location of where the program files are installed, and limited support for it makes ClickOnce not worth the extra effort required to make it work.

    Thanks for considering these comments!

    • robindotnet Says:

      Thanks for your feedback, I’ll pass it on to the ClickOnce team. Some comments in response…

      I don’t understand why you think you need source code to sign 3rd party assemblies. With ClickOnce, you sign the entire deployment, it’s not strong naming, that’s a separate issue. The point of signing the deployment is to hash the files and the manifests. Then when the application is installed and looks for updates, it checks to make sure the hashes haven’t changed, to make sure the deployment hasn’t been messed with. This keeps someone from hijacking your application and deploying an update containing malware in place of your update.

      Second, you could uncheck the “sign the click once manifests” checkbox in the signing tab and it wouldn’t sign the deployment if that’s what you wanted to do.

      They have to put the files under the user profile because one of the design goals of ClickOnce deployment is to deploy without impacting any other applications on the system, and to install without requiring privileges. I’ve never understood why it matters where the files are installed. The user shouldn’t be going to where the executable is anyway, and with Windows Vista and following on into Windows 7, you shouldn’t store any files that will be updated in Program Files. Since you can find the location of the running deployment programmatically in code, why does it matter if it’s in c:\users\username\local\apps\2.0\weirdfolder or it’s in C:\ProgramFiles\touchingThisFolderRequiresAdminPrivs? (That’s an honest question, I really don’t get this.)

      You do have to give up some control when using ClickOnce, but having incremental updates and forced updates makes it well worth it for me.

      Good luck with whatever solution you are using…

    • sliderhouserules Says:

      This is one of the things they did away with in .NET 2.0 I believe. You don’t have to sign anything anymore, not your assemblies and not the manifests. An application deployed on the intranet doesn’t need all the security so this was very nice. I eliminated all the extra stuff for our ClickOnce apps a couple years ago when we moved to .NET 2.0.

  11. Jose Carlos Says:


    I recently change our VS2008 to TFS 2010, and when we publish to our webpage a clickonce application, it cannot be downloaded because it stops and say: operation has time out.

    How can I find out in logging a trace to solve this error? Is there a post in your talking about it?


    • robindotnet Says:

      How are you publishing your application? Are you uling Visual Studio or msbuild? How many people are impacted by the download problem? This is not usually a problem caused by CLickOnce. If you have published your application and your URLs are correct, then this is usually some kind of network problem, especially if even one person can install it successfully. I’m confused by your first statement. Did Visual Studio is a completely different product from Team Foundation Server. Which one did you update, or was it both?

  12. Rodrigo Castro Says:

    Let me ask you a question: what if the user tries to install / run an app coded in .NET 4 and the user hasn’t installed any CLR version? Does the ClickOnce check and advises to install the .NET framework first? Thank you!

    • robindotnet Says:

      ClickOnce itself won’t, but the bootstrapper will. Go to the Prerequisites dialog found in the Publish tab where you publish your ClickOnce application and select the version of the .NET Framework that you are targeting. Then you can have the user run the application through the setup.exe the first time (this is the bootstrapper). It will check and see if he has the prerequisites installed. If he does, it will continue on and call the ClickOnce application. If he doesn’t, it will install it and then continue to call the ClickOnce application.

  13. Greg Burns Says:

    “Thank goodness you can roll back a deployment by taking the earlier version of the deployment manifest (the .application file) and putting it in the top folder of the webserver folder!”

    Can you elaborate on this? I’ve tried copying the .application file from the specific version’s folder i would like to roll back to, but encountered this error:

    “Cannot activate a deployment with earlier version than the current minimum required version of the application.”

    As you can probably guess, I had a minimum required version set (to force everyone to update to latest build). Is there a work around? It is no fun pushing an update and not being able to easily “undo” it if something is wrong.

    • robindotnet Says:

      You can’t roll back a deployment if you set the minimum version. What you CAN do is copy the deployment you want to roll back to and change the version of it. To do this, download the version you want to roll back to. Copy the deployment manifest to the root folder (.application file), and rename the versioned folder to 1 version higher than the current version. Use MageUI to edit the deployment manifest and change the version IN the manifest, then select the application manifest (yourapp.exe.manifest) in the newly-named versioned folder. Sign the deployment and save the changes. Then copy the versioned folder back to the server, and then put the .application file in the root deployment folder on the server. The deployment does not become “active” until the deployment manifest is put in place.

  14. tim Says:

    In ClickOnce 3.5, sometimes updates are unable to access the settings (Settings.settings) and the new version ends up with all the defaults again. Is this solved in ClickOnce 4.0?

    • robindotnet Says:

      No. I’ve seen this happen when one of the properties of the deployment changes, most notably the certificate used to sign the deployment. They no longer require an uninstall/reinstall when you change the certificate, but some part of ClickOnce still register it as a different deployment and don’t respond how you’d like them to (like the settings.settings).

      I’ve handled this by creating my own config manager (it’s just a list of key/value pairs that I serlalize when the user changes one) and storing the data in LocalApplicationData.This is always available, and if the user needs to uninstall and reinstall the app, his settings are still there. The only downside is the settings are left behind if the user uninstalls the app forever.

      string userFilePath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
      string myFolder = Path.Combine(userFilePath, “MyCompany”);
      if (!Directory.Exists(myFolder))


  15. Jan Romell Says:

    Any news on ClickOnce failing on Windows 8 Consumer Preview? It worked fine in Developer Preview, but stopped working in CP. Turning of the “Smart Screen Filter” in Control Panel, works as a workaround.

    • robindotnet Says:

      I have posted a bug in Connect for this. They closed it as “fixed”, and I double-checked with the ClickOnce guy, and he confirmed it. I think there’s a new version of Windows 8 coming out soon (June?), and hopefully it will have the fix in it. I’m watching this closely, because my company uses ClickOnce deployment for our applications (SAAS), and we won’t be able to support Windows 8 if ClickOnce doesn’t work!

    • robindotnet Says:

      I’ll be posting a blog entry about this in the next week.

  16. andyblackman Says:

    Can you offer any advice on setting up an application to install via ClickOnce from 2 or more load-balanced servers?

    • robindotnet Says:

      Everything I know about load balancing, I learned from Windows Azure (where it’s pretty much invisible to my client calling my WCF services in the cloud). A ClickOnce application always has to be installed and updated from the same location. If the load-balanced servers are represented by the same URL, this will work fine. If the two deployments have different installation URLs, then they will always be two deployments. You can check the box in the Options dialog to exclude the deployment provider URL, and then the customer’s URL will be set when he installs the application, but he will always get updates from the same URL regardless. Does that answer your question?

  17. N Prasad Says:

    0 down vote favorite


    I have a requirement of publishing three different applications( WPF – *exe) using ClickOnce deployment approach. This is very much similar to the MS Office suite where we have multiple office application which gets installed in one go.Basically multiple executable in One Click with each app having separate shortcuts option in the start menu. Do we have this option in ClickOnce? please suggest the ways to achieve this using VS 2012.

    • robindotnet Says:

      You have to publish them differently and the user has to install them separately. However, if you give them the same company name in the properties of the main project, they will show up in the same place in the Start menu. You can also fill in the Suite Name, so you can have multiple levels in the start menu.

      p.s. I have a feeling of deja vu — did I answer this on stackoverflow?

  18. Todd Armstrong Says:

    The new features sound great. One of the things that I always run into is the certificate binding being compile time instead of install time. The lifecycle of my app is very long at my clients, and they continually have new locations coming up. So once my certificate is expired, my click-once deployments stops working. Is there any way you know to get around this or apply a new certificate?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: