A fairly messy little detail of ClickOnce has surfaced that I wanted to get some word out about regarding publisher certificate renewals and how they affect ClickOnce.

ClickOnce only allows you to perform an update to an application if the updated version manifests are signed by the same publisher certificate as was used to originally sign the application.

When ClickOnce was designed, the product team understanding was that certificate issuers such as Verisign and thawte would renew certificates without re-issuing a new certificate (with a new private/public key pair). Unfortunately, that understanding was incorrect. Certificate issuers do in fact issue a whole new cert, just one that has the same CN (Common Name) when they do a renewal.

The result of this is that if you have a ClickOnce application in production and your publisher cert expires, you will no longer be able to issue updates to your application with your new cert. You will have to have users uninstall the previous version and install the new version as a fresh install.

To combat this for the near term, you may want to consider buying a cert that lasts longer than a year.

Microsoft is looking into a fix for this in the Orcas release, but the details of what that fix will look like and how it will affect the update process is yet to be determined.

Congratulations to Dan Kahler for coming up with the correct answer and winning a free seat in the class!

If you want to win a free seat for our Advanced .NET 2.0 Master Class, being held 4-8 Dec 2006 in Reston, VA, be the first one to email me at brian.noyesATidesign.net with the answer to the following question:

What is the name of the class that you use to sign a ClickOnce manifest after making modifications to it and writing it out with the manifest utility APIs?

Race is on! 

Thanks to some great feedback from my fellow Microsoft Regional Directors, Dax turned around a great update to the new blog design that looks even better and is a lot better on the screen real estate.

Check it out: http://www.softinsight.com/bnoyes/

Check out the new blog site look and feel. Thanks to the design genius of Dax Pandhi and Nukeation studios, my blog has a great new face.

For those that don't know my background, I used to fly the now-retired F-14 Tomcat, and this cockpit is a geek-ified version of the F-14 cockpit.

Another great conference complete. Around 5000 showed up and we had great feedback from the crowd that it was a good show. If you haven't been to connections before, you really should check it out.

I gave three talks this week. You can get the slides and demos for each below.

Real World ClickOnce:  Slides   Demos
Workflow Driven Windows Applications:  Slides   Demos
Implement a Data Layer with the VS 2005 DataSet Designer:  Slides   Demos

If you haven't experienced Windows Vista yet, it is a very cool operating system, but there are a lot of lessons to learn in getting up to speed in working in the new environment.

The biggest thing to get used to if you haven't been running a non-admin account on your XP machine is that there are probably a hundred things or more that you get away with that you don't even know that the reason you get away with it is that you are an admin.

In Vista, even when logged in with an administrator account, you are still not allowed to do administrator things without a privilege elevation through a mechanism called User Access Control (UAC). UAC will seem like a living hell at first because all kinds of things will stop working for you. For example, if you are only getting to some files because you are an admin, and an app such as Quicken tries to run and access those files, you will just get whatever kind of error the app vendor decided to surface for a file I/O error. However, the best way to approach it is to treat it as a learning experience to figure out how to avoid running things as admin unless you really need to (i.e. give your user account permissions to the directories you really need, don't rely on Admin privilege to give you access).

Another example is when publishing with ClickOnce. When you publish from Visual Studio to an http address, VS uses Frontpage Server Extensions (FPE) to create the virtual directory and copy the files to it. First step on Windows Vista is that you need to have IIS 6 Compatibility enabled (it is not on by default, nor is IIS installed by default like XP). Once you do that, IIS 7 knows how to look like a Frontpage Server Extension endpoint. The other thing is that you can only access the web server through FPE if you are accessing as an admin from VS.

Even when logged in as an admin, VS will not be running with admin privilege by default. As a result, when you try to publish a ClickOnce app you will get an obscure error that says that FPE is not installed on the server. Specifically:

"Failed to connect to 'http://localhost/WindowsApplication3/' with the following error: Unable to create the Web 'http://localhost/WindowsApplication3/'.  The Web server does not appear to have the FrontPage server extensions installed."

The solution is quite simple: you need to run VS as an admin. To do this, you can right click on the shortcut to VS from the start menu and select Run as Administrator.

If you want to always run VS as admin, do the following:

• Go to devenv.exe in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE directory.
• Right click and go to properties.
• Select the Compatibility tab.
• Check the box at the bottom that says Run this program as an administrator (see below).

The new security protections of UAC are there for a reason. You could just turn it off and you wouldn't have problems like this in the first place. I'd encourage you not to do that. Use it as a tool to teach you how to get your work done without admin privilege to the extent possible. So in this case I prefer to only run VS as an admin when I need to by doing the right click - Run as Administrator option instead of always enabling it, but you will have to make these productivity vs security decisions for yourself.

One scenario people want to support is to have multiple versions of the same application installed to a single machine/user's account. The guidance I put together for patterns and practices has a walkthrough of setting this up. For example, say you have a version 2.0.0.0 of an application that is your production version, and you publish a new beta version (3.0.0.0) that you want a limited set of users to access, but those same users need to be able to run both production and beta side by side through ClickOnce on their machines (perhaps for feature comparison testing).

The first step is that you will need to have different deployment manifests for the multiple versions you want a single user to run. You direct the user to launch from each URL to the different deployment manifests and they will get a separate installation on their machine... or will they? The answer depends on a hidden aspect of the ClickOnce runtime regarding what the runtime considers a unique identity for an installed application.

If you are not familiar with the things that ClickOnce does under the covers to install an application on a client machine, it downloads and caches the deployment manifest, the application manifest, and all of the application files. Those manifests have to be signed by a publisher certificate that is cryptographically unique. Additionally, the installed application has a product name that gets embedded in the deployment manifest.

You might be tempted, as I was, to think that a unique product name, combined with a separate deployment manifest would be sufficient to make the client machine treat those installs as separate and distinct (such as setting the product names to "MyApp" and "MyApp - Beta"). Unfortunately you would be wrong, as I was.

There is actually a separate piece of information that the ClickOnce runtime uses to distinguish one application from another - the application identity is set by an identity set for the deployment manifest itself. This identity is normally created by Visual Studio when publishing and is set to the deployment manifest name (i.e. WindowsApplication1.application). You do not have control from Visual Studio to set this to anything else. Through the mageui.exe SDK tool, or better yet my Manifest Manager Utility included with the patterns and practices guidance, you can set this application identity to any string that you like to uniquely identify multiple published versions of a single application.

So to address the scenario presented earlier, you can simply set the application identity to MyApp for one version and MyApp-Beta for the other version, and you will be able to side-by-side install those two copies of the app on the same machine.

I recently put together a bunch of guidance topics for Microsoft Patterns and Practices for doing ClickOnce deployments of CAB-based applications. This guidance and the sample code is now available as a Community Resource Kit and will eventually be incorporated into a future release of SCSF.

The resource kit also includes something a lot of people have been asking for - an example of programming against the manifest APIs in the Microsoft.Build.Tasks.Deployment.ManifestUtilities namespace. I wrote a Manifest Manager Utility as part of that effort and included in the download code that makes common tasks such as updating application files a lot easier. It takes care of signing both manifests at one to make sure they are in sync, updates the deployment manifest reference to the app manifest and other things like that. If you need to go beyond what it does, then you now have sample code available to show you how to work with the APIs.

Another thing included in the kit is an example server side deployment repository provider that allows you to take over the process of serving up manifests and application files on the deployment server so that you could retrieve them from anywhere or even generate some of the files on the fly.

Enjoy!
Get it here!