How to extend an existing certificate, even if it has expired

In many cases, when the certificate you use to sign your ClickOnce deployment expires, your customers have to uninstall and reinstall the application. This is the problem discussed in my MSDN article on Certification Expiration in ClickOnce Deployment.

Part of that article discusses the use of a program called RenewCert to extend your signing certificate, and tells you why you might want to do that. The following GoldMail shows you how.

View in browser

The basic command looks like this:

RenewCert oldpfxfile newpfxfile CN=newName password-to-old-pfx-file

Let’s say I have a certificate called NightbirdPFX.pfx that has expired. If I want to create a new version with the same public/private key pair, I would use this command:

RenewCert NightbirdPFX.pfx NightbirdPFX5Yrs.pfx CN=”Nightbird 5 Yrs” MYpassw0rd

Now I can replace the old certificate with the new and publish an update, and the users will be able to pick up the update without having to uninstall and reinstall the application.

As noted in the GoldMail above, if you have a vendor certificate, it does change it to a test certificate. So if you still want to have a trusted deployment, you have to purchase a new certificate.

The compiled version of RenewCert that I used to extend my vendor certificate can be downloaded here. This requires the C runtime libraries from Visual Studio 2005 in order to run, so I have included those in the zip file as well.

I’d like to thank Cliff Stanford for taking the C++ code from MSDN and enhancing it so it works for both test certificates and vendor certificates. If you’re interested, the code and compiled binary can be found here.

If you want to read the original article in MSDN and/or see Microsoft’s code, you can find it here.

[Edit 7/7/2011 Move zip file to Azure blob storage]

How to move a ClickOnce deployment

One of the questions I see in the MSDN ClickOnce Forum is how to move a ClickOnce deployment to a different location. You might want to move your deployment because your company is setting up a new webserver, or because you change hosting companies for your deployment.

You can’t just change the URL because it’s part of the security built in to ClickOnce. It checks the update location for the installed application against the URL for the update, and if they don’t match, it won’t install the new version. This keeps someone from hijacking your deployment and substituting their own files.

This GoldMail will show you how to move your deployment to a different URL.

View in browser

This download contains the source code (VS2008, C#) for the three versions of the application used in the GoldMail. If you are a VB developer and can’t figure out how to translate the code to VB, please post a comment and I’ll post a VB version of the code.

 Click here to get the source code.

(edit) I couldn’t see how this could work with an Office Solution (VSTO), so I did some looking around. VSTO doesn’t use the update URL at all, so it looks like your customers have to uninstall and reinstall if you have to move a VSTO deployment. Dang.

Installing a ClickOnce Application for all users

I gave a talk in Mountain View at the South Bay .Net User Group meeting on August 5th. This was a general talk about ClickOnce Deployment and how to use it. Almost everyone in the room was a Windows Forms or WPF developer, which seems rarer and rarer these days as people migrate to web applications. There were a lot of questions, and a lot of good discussion about things that people would like changed in ClickOnce deployment.

The most frequently requested feature in that meeting and in the MSDN ClickOnce Forum is to install a ClickOnce application for all users rather than a specific user.

This is difficult because the files are stored in the user’s profile, where the user has read/write privileges. One of the design goals of ClickOnce is to provide a deployment technique that allows customers to install applications without elevated privileges. Installing an application for all users requires privileges.

Another design goal was to protect the client machine from problems caused by software installations. Do you remember “dll hell”? This was the problem that happened when another application came along and replaced a dll that you were dependent on, and caused problems for your application, or vice versa.

In a ClickOnce deployment, it is possible to include most of the dll’s locally with the deployment, rather than installing them in the GAC or the windows system directory. (This is excluding, of course, the .NET Framework and other prerequisite applications such as SQLServer Express.) You can even deploy the SQL Compact Edition dll’s or DirectX dll’s. This allows you to maintain strict version control on the dll’s that you include in your deployment. Microsoft would have to figure out a way to handle this if the application were deployed for all users; if they weren’t careful, you could easily end up in dll hell again.

On the other hand, if they just chose to put the files under the All Users profile, once again you have the permissions problem that Microsoft sought to handle with ClickOnce deployment, because the user can’t write to those files without elevated privileges. Also, If Microsoft stored the deployed files in the “All Users” folder, they would have to figure out what to do if UserA was logged on using the application, and then UserB logged on and there was an update available. Do you kick off UserA? Do you forego the update because UserA is already running the application? What is UserA always leaves his account logged on? How will you ever do an update?

This request has been passed on to Microsoft, but I haven’t heard of any plans to include a change to this in .NET 4.0, so I wouldn’t expect any quick results. Doing an all-users install is counter to the design goals of ClickOnce deployment, so I think it’s going to be something everyone has to live with, at least for now. Using XCopy or a setup & deployment package and rolling your own incremental update methodology would be the way to go if you absolutely have to have an All Users installation.

Local Deployment of a ClickOnce application

You can deploy a ClickOnce application to localhost, i.e. your local web server on your own machine. After deploying your application to your local web server, you can install the application on your machine, on another machine in your local network, or in a VM. This is a great way to make sure all of the files required to run your application are included and/or the prerequisites work correctly.

It can take me several minutes to deploy the GoldMail Composer application to our development web server that provides access from the internet, but deploying it locally only takes a few seconds, so this method saves me a lot of time when I’m repeatedly testing a deployment.

You need to have IIS installed and you need to know the name of your Computer. This GoldMail gives a general idea on how to accomplish those two tasks, and then shows how to set your options to deploy your ClickOnce application locally and test it.

View in browser

ClickOnce Desktop Shortcut using VB

This is a follow-up post to the article How to Create a Desktop Shortcut for a ClickOnce Application, providing the VB version of the code, as requested by one of the readers of this blog.

The implementation is slightly different in VB than it is in C#. In C#, you just add the code to the Program.cs and run it prior to the first form being displayed.

In VB, the best place to call this is in the Application Startup event. This GoldMail will show you exactly how to do that.

View in browser

This download contains the sample code in VB (VS2008) as well as a Word document with the same information as the GoldMail.
ClickOnce_DesktopShortcut_VB.zip

[Edit 7/7/2011 Move zip file to Azure blob storage]

ClickOnce: Concurrent versions

One of the questions that comes up a lot in the MSDN ClickOnce forum is how to deploy an application so the user can install multiple versions of it, like a QA version and a production version. Basically , you have to change the assembly name and the product name. This GoldMail illustrates how to do this, and mentions a couple of other considerations as well.

View in browser