January 7th, 2007 - Got bit by the expired temporary certificate issue when trying to deploy a ClickOnce application. Never got a "real" certificate since it wasn't necessary for the needs of this particular application. You can't just replace the certificate because that would require that every basically uninstall the old version and visit your deployment location to reinstall. So the only solution at the moment was to change the date on your deployment computer and publish accordingly (it seems the expired certificate only relates to using it to deploy; not the actual installation). After talking with several people at Microsoft, a "fix" was on the way in the form of the RenewCert.exe sample project. This small console application can be run against and existing temporary certificate and extend the date of it by five years from the date that you run it. Problem solved.
January 6th, 2008 - Visual Studio 2008 was available and the project(s) that were built by someone else were being combined into a single executable. Since this was the case and it was also a case of a new .NET Framework being used, requiring a new install wasn't an issue (even though the certificate in question was already taken care of). I decided to go ahead and give this "issue" another chance since there was also a revamped ClickOnce with the new framework.
January 6th, 2009 - @#%@#$$@#%%@ Same issue. Oh well, time to find that RenewCert.exe and run it. Doh... some Side-By-Side issue. Had to rebuild the C++ console application to get it to work. Renewed the certificate and now things are moving forward again.
I'm sure there is some lesson to be learned here; however, the point was that I was able to get back on track.
Now, apparently Microsoft has come to their senses with .NET 3.5 SP1 and modified the ClickOnce deployment to allow people to not have to sign their deployment manifests. I just tested a project deployed with signing, then extended it using RenewCert.exe with .NET 3.5 SP1. Works great. Then I took the next step of unchecking the sign ClickOnce manifests to see if the project would still install without any issues (meaning not wanting to cause issues with end users) and other than the warning you get when deploying regarding that you are changing the certificate (not changing, removing... hmmmm), the upgrade worked without any issue.
I also ran this using the .NET 3.5 as a prereq in the deployment; however, the test machine now had .NET 3.5 SP1 installed, so not sure if it was a valid test.
Either way, having the option to not have to sign is a nice feature; especially if you are in an intranet environment. However, I'm not sure that I want to open this completely up on a server that is out in the wild; though it's probably not a huge deal considering the many factors that could go into the deployment, target audience, server security, etc. involved. Since I have a solution that can extend the certificate, I suppose I can ponder this on another day...
For a slightly modified version of the Microsoft solution, go here. NOTE: I strongly recommend downloading and reviewing the source; build from that. Don't trust exe's from an unknown source... not saying anything negative specifically about this source, just as a habit... don't do it. If you know the person, then at least you know who you can track down accordingly. Although I don't know him, I want to thank Cliff Stanford for providing this as a project solution.
NOTE: This post is more for me as a reminder for when I use ClickOnce for the next project. If it gives you some food for thought, excellent! ;-)
UPDATE: Of course all this worked with a test project/deployment. When I had to do this on a REAL project, things didn't go so smoothly. Final result was to reverse everything I had done and set my date back to December 1, 2008 to get it to publish. Still investigating what is going on here; one major difference is that I also have all of the related assemblies strongly signed. I have no idea if that is an issue or not; however, the error I was getting was found on a couple of websites as something similar (but no mention of expired certificates) and, wouldn't you know, no one had replied with any sort of suggestions or possible solutions. When I get a moment, I'll dig into this deeper and provide another update.
UPDATE/SOLUTION: I had to get the original Microsoft solution working in VS2008 (the source shown on the site didn't want to compile in the latest version, was originally for VS2005). I so love how C++ seems to CHANGE every single version and not work with prior versions. I suppose if I was a C++ expert, this would be old hat; however, I only use it out when necessary so count me as a newb. ;-) Anyway, once I got it to build (and this time I built it in RELEASE mode so that the .exe would work side-by-side in newer versions of .NET) it modified the certificate and everything worked smoothly after that. If you need the updated source, let me know and I'll be glad to make it available.