People frequently ask about the future of ClickOnce deployment. I hear and read things like “Microsoft hasn’t updated their ClickOnce blog since 2006.” “They never change anything in ClickOnce.” “You never hear anything about ClickOnce deployment updates.” “Are they going to keep supporting it?” “Why doesn’t Microsoft use ClickOnce themselves?”
The answers to those questions are: 1. It’s not sexy so nobody talks about it. 2. Yes they do. .NET 3.5 included ClickOnce deployment for VSTO applications, which is awesome. And SP-1 included optional signing and hashing, file associations, and other fun stuff. 3. You do if you know where to listen. 4. Yes. 5. They use it for many of their apps used internally. I don’t think they can use it for Visual Studio or Office. Can you imagine what the prerequisite list would look like?
Silverlight is sexy. Windows Phone 7 is sexy. WPF is sexy. Deployment? Not so much. The release of Silverlight 4 was even noted on one of the Apple News sites. How does “I created this really cool component that you can embed in a WPF application and it cleans your computer screen and tidies up your desk” compare with “I figured out how to install this really cool component on your computer.” See what I mean?
Deployment is like Amazon.com delivery. You don’t ever think about how your books get from that cool page on the web to your Kindle in two minutes (or, if you’re a traditionalist, to your front porch in two days), but aren’t you excited when they show up?
Even though Microsoft doesn’t go on Oprah to discuss their feelings about ClickOnce deployment, I have discovered over the past few months that they really do care about it.
Saurabh Bhatia, the ClickOnce expert at Microsoft, has been helping me over the past year to respond to some of the more difficult questions in the forums. When I attended the MVP Summit in February, I met with Saurabh and some of the other people who work in and around ClickOnce. The 1-hour meeting stretched into 3-1/2 hours as we discussed feedback and information I had collected from the MSDN Forums, StackOverflow, blog articles, and from individuals who e-mailed me or talked to me after my presentations. I passed on complaints, common problems, and most frequently requested new features. They really wanted to know, and were glad to get the information.
In return, they provided me with a look at what’s coming in .NET 4.0 (that’s the next blog post). Since I’ve returned, they have followed up with answers to my questions. (They were sending me e-mails with answers before I’d even left Washington!) Saurabh and one of his cohorts, Jason Salameh, continue to provide resources to help me support the ClickOnce Deployment community, and Saurabh set up regular meetings just to touch bases and help me with any difficult issues or questions that come up that I can’t answer. I think of it as a “Stump Saurabh!” session, but so far I’ve only managed to stump him once (proxy authentication). I learn something new with every conversation.
Also coming soon is an update of the Patterns and Practices Smart Client Software Factory and the ClickOnce documentation for it. (I know that because they asked me to do the update to the docs. I was so flattered!)
It’s safe to say that Microsoft will continue to support and enhance ClickOnce deployment. My next blog post will be a summary of the new features available in .NET 4.0. If there are features you want, post a comment and I’ll pass it along. If you have questions about problems you’re having with ClickOnce deployment, please post a question in the MSDN ClickOnce and Setup & Deployment Forum. I’ll see you there.
Tags: ClickOnce
RobinDotNet's Blog 
April 18, 2010 at 12:59 pm |
Happy to have someone watching out for us. Thanks Robin!
April 22, 2010 at 8:29 am |
Hi
It would be nice to hear if there is a solution to the Proxy problems that stops alot of companies using ClickOnce deployed apps…
Will ClickOnce work with a non integrated NTLM/kerberos proxy that requires non-default user username/password?
I hope the solution doesnt include any changes or modifications on or by the user or on his system in any way.
🙂
Best regards
Tobias
April 23, 2010 at 11:02 am |
Hi; thanks for your feedback. I get this question intermittently, and have passed it on to the ClickOnce team as one of the features repeatedly requested. The most recent thread has the best information on it; it is here. Not to put too fine a point on it, but apparently it’s a big damn deal. It probably is difficult because of ClickOnce apps not having admin privs. I’ll keep passing the information on to the team though.
April 26, 2010 at 12:08 am |
Great, thanks for the feedback!
Hope the MS Teams will listen, because like you wrote it ‘s not only “…a big damn deal” it’s huge!.
As an example, we are delivering software solutions to big industrial companies with thousands of users behind proxies and what not. And still the latest autoupdating solution from Microsoft just falls flat without any way of of solving it. This forces us to look for other solutions like older updating components or web based services, which is not necessarily a MS solution.
/Tobias
September 21, 2010 at 5:29 am |
I have a partial fix to the proxy issue on my blog.
http://bronumski.blogspot.com/2009/06/clickonce-updates-via-authentication.html
I say partial because you need to get the application onto the client machine first but once it is on there my solution works fine. To get the first install on there you can use a local deployment such as a file share or a CD as long as the update path points to web location.
Bronumski
November 17, 2010 at 7:51 am
Yes, I read your article, nice one! We have actually tried a simillar method but without any way of inputing proxy information. One issue still remains, most users don’t know the proxy settings for their network. Internet Explorer usally get’s any proxy info automatically so the user is often unaware of any such issues.
/Tobias
November 28, 2010 at 3:14 am
Not sure what the answer to this is. If you’re inside a corporate firewall, the IT guys should be able to provide the proxy settings. If your ISP requires proxy settings, they should be able to provide them.
December 2, 2010 at 1:50 am |
Well, that exactly the problem. Many larger companies do not want to give out the proxy information to their users. They are content that IE works and that everything else is blocked. It’s a security thing I guess.
April 22, 2010 at 11:58 am |
We have been using click once deployment with our clients, because it helps to not have a body going around over to a hundred machines to install the application. We have been using a similar concept built on the click once that allows a client machine to use the application (non-installed) to dynamically receive new applications without doing click once on the other applications.
April 23, 2010 at 9:10 am |
I have been happy with the ClickOnce deployment for the last two years. I have developed several applications that were originally to be converted to web application until I showed them that with a ClickOnce deployment you can still develop the windows application but deploy from a web site. I see a Microsoft continuing to support the clickonce deployment it is better than losing functionality by converting to html and javascript.
April 23, 2010 at 11:10 am |
I agree. I used to think they had deserted the field altogether, so I stuck my nose into it and started beating the drum. I was fortunate that my good friend Beth Massi hooked me up with Saurabh when she heard I was having problems answering some of the questions in the forums. Then I found it wasn’t true that they had forgotten about ClickOnce — quite the opposite. It just gets lost in the din of the new and sexy technologies like Silverlight. I do feel like I’m helping — to bring them information and feedback from the community is really valuable to them, and helps them decide what features to add in the future. I’m more than glad to be able to do that. My company (GoldMail) has used ClickOnce deployment for the last three years, and have had really good success with it.
Good luck!
April 27, 2010 at 10:36 am |
Do you have any advice on marketing the ClickOnce applications like you GoldMail? I would like to take our application to the next level but like the post says Silverlight and Web Apps Saas seem to be sexy, but they forget you lose functionality by going from a Windows App to the Web. At least in the Click Once you still use the windows application.
April 28, 2010 at 11:48 am |
Hi Michael,
I’m not a marketing guru, but I would think pointing out the things you can do in a desktop application that you can’t in Silverlight can be a compelling argument. It depends on what your application does. Ours uses DirectX to do recording, and we do a lot of image manipulation and editing, among other things that are not possible to do in a web application. As Silverlight becomes more fully featured and becomes more mature, the gap between Silverlight apps and WPF apps will get smaller. So it basically boils down to what you need to do, and how you can do it.
At least deploying a desktop app from a webserver using ClickOnce does give you that instant-updated-always-running-the-right-version deal.
Good luck!
Robin
May 2, 2010 at 9:41 pm |
[…] The Future of ClickOnce Deployment (RobinDotNet) […]
May 16, 2010 at 8:39 pm |
I disagree with your assessment that ClickOnce doesn’t get much attention because it’s not a sexy type of product like Silverlight which is obviously has more visibility and name recognition among end users. If you look at products like Git you will see that mundane things like VCS can become a very hot topic among geeks in the field and the reason doesn’t have to do with it being sexy as much as it has to do with it being a well crafted product. Git and other DVCS have a very impressive feature set and solve real-world problems for many developers. ClickOnce on the other hand aims to solve several problems related to traditional deployment scenarios but in truth, from my experience, it tends to have many quirks and is very difficult to use for even slightly complex deployments. A few examples of where ClickOnce chokes is on any type of rapidly changing set of prerequisites (.NET Framework, new versions Crystal Reports, …) and re-branding scenarios. I think it is in-flexibility and other such inadequacies that make ClickOnce not so popular otherwise you would be seeing the bulk of apps or at least demo aps on CodePlex released using ClickOnce type technology when Silverlight doesn’t apply but this isn’t the case.
May 23, 2010 at 11:48 pm |
Thank you for your feedback. I think we’re going to have to agree to disagree. Deployment is not something you use every day, and it’s not something that most people think about. When they do have to deploy an application, they figure out how they want to do that, set it up, and don’t think about it again unless something goes wrong or something changes. Have you actually deployed an application with ClickOnce deployment? My company’s product has its own complexities, and we are using ClickOnce quite successfully.
The deal about prerequisites is they are not actually part of the ClickOnce bit of the deployment. They are installed by the bootstrapper, which then installs the ClickOnce application itself. In my experience in software development, you don’t change your prerequisites lightly. You have to install the new versions and test them out and make sure everything works. Most people wouldn’t change from .NET 2.0 to .NET 4.0 without doing major regression testing. I have figured out how to handle the changing-prerequisite issue by programmatically uninstalling the application and installing the new version with different prerequisites from a different URL. This is how we are going to update the .NET Framework target of our application. Since it’s something I’ve seen discussed quite a bit, I guess I should write a blog entry on how to do it, because it might benefit others.
I think ClickOnce has specific design goals, and people want it to do more than it was intended to do, such as install for ‘all users’ on a computer. It does meet its design criteria very successfully, and I think if people want something more between a setup & deployment package and a ClickOnce deployment, maybe that’s something Microsoft will offer in the future.
BTW, Dell’s Download Manager, Amazon’s Kindle reader for the PC, and GoToMeeting.com use ClickOnce deployment, as does Google for some of its products. So it IS out there in the wild.
Thanks again for your feedback!
July 7, 2010 at 4:13 am |
Hi,
We have a product that is deployed using ClickOnce. The product and ClickOnce installation target .NET 2.0. However we are recently using Visual Studio 2010 and have upgraded the product to .NET 4 framework. I want to also upgrade the ClickOnce deployment to .NET 4 in order to take advantage of new features.We have mentioned the .NET 4 framework as pre-requisites in publish tab of the project properties.
When I try to upgrade it, the update doesn’t download the prerequisites.
however, some of the discussion forum’s have suggested to programatically uninstall and install the application. is it the right way to do it?, is there any security issues with this?
If you have any suggestions, please let us know.
Thanks in advance.
Regards,
Girish
July 11, 2010 at 4:00 pm |
Hi Girish,
The setup.exe that the user runs when first installing the ClickOnce application installs the prerequisites, and then runs the C/O app. From that moment on, the C/O app runs on its own and does its own updates. You can update the application to .NET 4 and add it as a prerequisite, and have people install it via the setup.exe again. The other way to handle this is to programmatically or manually uninstall and reinstall the application. Another idea is if you have some way of tracking, you could have the application install .NET 4 and then after everybody has installed it, upgrade the application itself. We have no way to making sure everybody using our product has upgraded, so we’re going to go the uninstall/reinstall route. If you need to do that, post back and I’ll give you the link to an MSDN article I wrote that shows how to do that.
Robin
July 12, 2010 at 2:15 am |
Hi Robin,
Thank you very much for you response.
RE:To making sure that everybody is using our product has upgraded or not,
–Yes, please send me the link to an MSDN article.
RE:To uninstall/install the application programatically,
— I am trying this option, and code for this is here http://msdn.microsoft.com/en-us/library/ff369721.aspx,
but I am getting the exception at
ApplicationSecurityInfo asi = new ApplicationSecurityInfo(AppDomain.CurrentDomain.ActivationContext);
in GetPublicKeyToken() function.
Exception is “value cannot be null. Parameter name: activationContext ”
If possible please help me with this code or if you have any other solution to programatically uninstall/install please let me know.
Thanks in advance.
Regards,
Girish
July 15, 2010 at 2:20 am |
You have the right link; I wrote that article. In regards to the GetPublicKeyToken, are you running it as a deployed application, or trying to test it in Visual Studio? You have to run it as a deployed application to test the uninstall/reinstall.
November 10, 2010 at 10:58 am |
Is it possible use click once to update a web service (wcf) application? We want to distribute our application as an appliance (basically an application server) but we want it to automatically update itself as well as the client applications that access the server?
November 28, 2010 at 3:07 am |
Sorry, but no. ClickOnce is for deploying smart clients, such as those developed with Windows Forms or WPF, or console applications. ClickOnce apps install with no admin privileges, so they can not run a service.
December 13, 2010 at 6:06 pm |
Is there a recognised or recommended strategy for providing failover onto a standby server – or even better, a way of load-balancing between servers so we have a hot-hot configuration ?
We currently have 00’s of users who all have a dependency on a single server – what happens if this goes down ?
January 11, 2011 at 4:52 am |
You can’t get an update or even check for an update if the installation URL is different. However, there’s nothing saying that installation URL can’t point to a different IP address.
So the way to handle this is to use a DNS entry to point to your deployment folder. For example, you might use install.yourcompany.com and have it point to http://yourserver.com/YourFolder/. Then if your server fails, you just re-assign install.yourcompany.com to point to the other server.
December 15, 2010 at 9:51 pm |
Is there an easy way to use ClickOnce to change the URL of where the server should be that holds the updates?
As an ISV we would like to pubish the software to each of our customers servers and then there clients hit there own servers (not ours). We do not want to have to do a custom deployment for 400+ customers. can the URL for the server be set in a config file?
Thank you.
January 11, 2011 at 4:55 am |
You have a couple of choices. You can automate the creation of the manifests and set the installation URL for each customer, using mage to sign the manifests.
Your other choice is to check the box in the Options dialog that says “Exclude the deployment provider URL”. What will happen is the package won’t have a URL in it, but it will set it on the user’s machine when he installs it, and look for updates there from then on.
The down side to this is that it’s not terribly secure, but if you’re not putting it on the internet, it’s probably okay.
February 2, 2012 at 10:56 am |
As an IT Adminstrator, I hope click one and everyone associated with its development are condemned to such a hot area of hell that all they can ever think of for eternity, is that they are sorry they were ever associated with it.
Why? Because software vendors are abusing it and using it for things it should never be used for. Enterprise software should be MSI based, and have the option of by machine or by user. I’m on my second vendor that has created a click-once app that I have to deploy to 1000+ users that installs per user, but requires admin privs. WTF?
Got to hell, click once advocates, and burn forever.
February 12, 2012 at 8:33 pm |
Thank you for your feedback. That’s certainly one opinion. ClickOnce was designed with system admins in mind, becasue it is installed under the user’s profile, and won’t do anything that requires administrative privileges. It’s pretty well sand-boxed. I’m sure this is why vendors use it. The only reason I can think of for a vendor to require admin privs is if it installs some kind of prerequisite, like SQLExpress or the .NET Framework. Maybe you can work with them to figure that out, and handle the deployment of the prerequisite, so their non-admin application will work.
August 9, 2012 at 5:48 pm |
Hi Robin, Are you aware if a ClickOnce application can be tested for Windows 7 and Windows 8 in the Microsoft Platform Ready program? I tried to copy the published folder to see if I could test it against that but it didnt install the application.
October 8, 2012 at 10:02 pm |
Sorry, I don’t know the answer to that question. If you still need an answer, reply back and I’ll ping someone at Microsoft.
July 23, 2013 at 8:27 am |
Thank GOD for ClickOnce. Visual Studio 2012 is now DROPPING the default MSI installer. If you want to create MSI files, you have to download a severely disabled version of InstallShield and then either upgrade to a really expensive professional version to get anything done or install VS2010 and use it to create a setup project.
July 29, 2013 at 10:03 pm |
Totally agree. There was a uservoice entry for bringing back S&D packages, and Microsoft just closed it and said they would work with InstallShield (Flexera?) to make it work better. (They can start by making it work for 64-bit targeted applications.) It’s very frustrating for a lot of people.
Robin
October 10, 2013 at 9:20 am |
Hi Robin, I’ve been an enthusiastic user of ClickOnce since it first appeared and have been using it to deploy/distribute apps. from my site ever since. It never, ever fails.
However recently my WSP said they intend to withdraw support for Windows Server 2003 and want me to upgrade my site to Server 2012/IIS8.
I’m currently using VS2012 for app. development . When I remove FrontPage extensions from the server (either version) I am unable to deploy using ClickOnce. Is there a workaround that will enable me to continue using ClickOnce without FP extensions ?
Thanks for being a great evangelist for ClickOnce. Who cares if it’s sexy or not – it just does it’s job well !
October 13, 2013 at 10:29 am |
I found your answer to this and just changed the publishing folder location to ftp://www.mysite.com and the installation folder to http://www.mysite.com/myapp. Hopes this helps others.
November 1, 2013 at 2:41 pm |
As you have found, you can use FTP to publish the files by changing the publishing file location, but use HTTP for the installation URL.
Robin
October 17, 2013 at 11:49 am |
Hi,
A friend told me, a couple of months ago, that Microsoft is going to stop developing ClickOnce and drop support in a near future, but i’ve been looking any info about it and I couldn’t find anything about the future of ClickOnce? Do you have any idea of this?
October 17, 2013 at 4:08 pm |
Microsoft has no plans to drop support of ClickOnce deployment (that I know of). They got rid of Setup & Deployment packages in VS2012, leaving ClickOnce as the only option included in VS. Plus, they use it internally quite a bit. Microsoft *would* like to see more people creating Windows 8 applications, which use a different deployment model (through the store), but that’s a separate topic altogether.
–Robin
January 2, 2014 at 4:16 am |
Hi,
I’m using ClickOnce a few years now, but I always have to explain my customers that they have to switch their IE to compatibility view to be able to start my ClickOnce apps instead of seeing its XML. With the coming of IE that compatibility view is even hidden further in IE… With a lot of helpdesk calls and emails as result….
If Microsoft will continue to support and use ClickOnce, why are they making IE not recognizing its XML by default without compatibility view?
February 21, 2014 at 2:54 pm |
You don’t have to change IT to compatibility view. The only reason the user ever sees the XML is because you have the MIME types set incorrectly on the deployment files. Check out this article for the list of MIME types.