Installing a Code Signing Certificate

WARNING: if you are getting your code signing certificate from VeriSign or Thawte, DO NOT use a Windows Vista or Win7 computer to get your certificate. If you do, you will not be able to export the private key and so you won't be able to sign code on any other computer and you won't be able to back up your certificate. If this happens to you, Thawte will give you a free reissue (Thanks Thawte!) See https://www.thawte.com/ssl-digital-certificates/technical-support/ Make sure you do not use a Vista or Win7 computer for the reissue! [Added 7/13/2008]. View my earlier post to see why.

Every time I try and install a code signing certificate, I forget how I did it last time. You'd think that there would be a guide somewhere on how to do it, but if there is, I haven't found it. Both VeriSign and Thawte give tantalizing hints scattered among dozens of knowledgebase articles, but overall, it's rather poorly documented.

So here's how to do it: (Note: If you are using Comodo and saving to the CSP, you should skip to Step 3, then skip to Step 7. In this case, you don't use the PVK or SPC file.)

1. Prerequisites: You must have a PVK file and an SPC file. From VeriSign and Thawte, these are normally named mycert.spc and mykey.pvk. If you don't have both of these files, this article won't help you. You'll also need the password for the PVK file.
2. Install PVKIMPRT from Microsoft. You can download it here.
   
3. Remove your old certificate. If you are renewing an existing certificate, then keeping the old certificates installed isn't usually useful, and having multiple certificates will break SIGNTOOL if signtool is searching the certificate store. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click Remove. The old certificate will probably be on the Personal page if you allowed PVKIMPRT to decide where to put it.
4. Import the certificate. Run PVKIMPRT to load the certificate into your cert store, like this (should all be entered on one line):
   
   C:\Windows\PVKIMPRT.EXE -import c:\mycert.spc c:\mykey.pvk
   
   You'll be prompted for your password, which you should already know. You'll also be asked which certificate store. You can let PVKIMPRT decide.
5. Verify the installation. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click View in the bottom right. The certificate will probably be on the Personal page if you allowed PVKIMPRT to decide where to put it.
6. Install the intermediate certificate. When you view the certificate information, you'll probably get a message that says something like "Windows does not have enough information to verify this certificate."
Don't panic! This is easily solved by installing the intermediate certificate. For Thawte, download the Root Certificates. This package also contains the intermediate certificates. Extract the ZIP file. Double click the file named "Thawte Code Signing CA.cer". You should see the Certificate Information. Click Install Certificate. Now go back to the Certificates Page on Internet Options and view your certificate. You should see the complete Certificate Information.

Make sure you have the private key. Go back to the Certificates Page on Internet Options and view your certificate. At the end of the information, right under the "Valid from" dates, you should see something that says "You have a private key that corresponds to this certificate." If this isn't there, delete the certificate, and repeat this procedure starting from Step 3. This happened to me when the intermediate certificate wasn't installed.

Export the PFX file. The PFX file can be used by SIGNTOOL. One advantage is that PFX files can be created without a password, which is handy in automated builds if you are using SIGNTOOL. You can see the complete process with pretty pictures at PentaWare. Here's the abridged version:

1. Go back to the Certificates Page on Internet Options
2. Select your certificate
3. Click Export.
4. Click Next.
5. Select "Yes, export the private key."
6. Click Next.
7. Select "Personal Information Exchange - PKCS #12 (.PFX)." (If this option is grayed out, then your private key was not imported).
8. Check the box labeled "Include all certificates in the certification path if possible. THIS IS VERY IMPORTANT.
9. Click Next.
10. On Windows XP, you can leave the password information blank if you plan to use this PFX file for automated builds. On Windows Vista, you must provide a password.
11. Click Next.
12. Enter a filename.
13. Click Next.
14. Click Finish.

Sign your code! If you need some hints on this, see my earlier post.

Visual Studio 2008 C++ Redistributable Components

I've wasted two hours hunting down files that should be obvious, so I'm hoping this post helps someone else.

If you need to redistribute components from Visual Studio 2008, such as the C runtime or the MFC DLLs, there are four ways to do it:

1. Put the DLLs in your installer and install them into Windows\System32 directory yourself.

DON'T EVEN THINK OF DOING THIS. It's almost impossible to do it right because of WinSxS. If you want complete control over your installation, use option #2.

2. Use the redistributable directories Microsoft provides.

These directories provide copies of the DLLs that are only available to your application. The directories should go in the same install directory as your EXE. This means that they are subdirectories of wherever your EXE is installed. [Updated 11/19/2008] I no longer recommend copying the directory itself. Instead, copy the contents of the redistributable directory into the same directory as your app. Make sure you include the manifest file. I made this change because msvcm90.dll will not bind to msvcr90.dll if they are a subdirectory. As a bonus, this change makes this option work with Windows 2000.

Assuming you've installed Visual Studio 2008, you can find the directories at:

C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86

Important: If you do this with Visual Studio 2008 SP1, make sure you put the following in your precompiled header:

#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

Advantage: Doesn't require admin privileges. Works with XCOPY. Your app won't break if the system global version is updated by Microsoft (but you won't benefit from security fixes either.)
Disadvantage: Not viable if your EXEs and DLLs are installed across multiple directories.

3. Microsoft Visual C++ 2008 Redistributable Package:

Original distribution.

SP1 distribution. See caveats.

[Update 6/22/2009] Both of these distributions cause the the Windows 7 Logo Toolkit Beta to generate FAIL errors.

Advantage: All you have to do is run it. Permamently installs the components in the proper locations.
Disadvantage: Includes everything, so it's larger than the individual merge modules. If you are building your own installer, not as clean of a user experience as the merge modules.

4. Use the Merge Modules.

Assuming you've installed Visual Studio 2008, you can find the files at:

C:\Program Files\Common Files\Merge Modules

Advantage: Best user experience. Smallest download.
Disadvantage: Installation isn't permanent - the DLLs may be uninstalled when your application is uninstalled. Requires you to use Windows Installer. (This is only a disadvantage for a minority of developers. Windows Installer is a logo requirement for Vista.)

Google API Documentation

One of my annoyances of dealing with many Open Source projects is the lack of documentation. nHibernate is a prime example - it's a fantastic technology with minimal documentation. The only book on the subject is a year late (and counting.)

I no longer find it entertaining to beat my head against a wall for days (or weeks) trying to figure something out that should have been documented in the first place. I don't mind paying for answers anymore. $200 is a small price to pay to get an answer that saves me a day of work.

I was therefore terribly disappointed by the tremendously poor quality of the documentation for the .Net library for the Google API. In the best tradition of F/OSS, the documentation for it is desperately lacking. Most functions have little more than a terse one-liner description, with no additional remarks. If it weren't for the fact that source code was included, trying to determine how to use the API might well be impossible.

A typical example is Captcha handling. The Google API will sometimes request the user to solve a Captcha to make sure that a human is really present. The problem is that there is no C# source code to demonstrate the correct response. Captcha is not handled by the sample code or the unit tests. It's mentioned in the newsgroups, but none of the responses actually contain code that works.

A more pathological example is documenation on the Contacts namespace. Try clicking on GroupMembershipCollection. No dice - broken link. Try looking at the code in the Samples directory. No help there, there's no sample code for contacts. Try looking at the Java library. Nope, it works differently from the .Net library (That's not a dig in this case. Both libraries are crafted appropriately for the style of each language.)

There's also no one you can call if you have a problem, even if you are willing to pay for the answer. Say what you will about Microsoft, but when they support something, they mean it. Monitored newsgroups, books, tech support, consultants, 3rd party training - you name it, the resources go on and on.

Google has a lot to learn about providing services to the enterprise market.

Fixing "ambiguous symbol" in a C++/CLR project

I was trying to use a CString in a managed project today. This is supposed to be easy but it wasn't working. [Note: Microsoft factored CString from MFC several years ago, so CString can now be used standalone. Super handy class.]

I started with what I thought was a reasonable statement:

#include "cstringt.h"

This gave me numerous errors, starting with:

C:\Program Files\Microsoft SDKs\Windows\v6.0\Include\ocidl.h(6238) : error C2872: 'IServiceProvider' : ambiguous symbol
C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\atlcomcli.h(370) : error C2872: 'DISPPARAMS' : ambiguous symbol

With a little research, I determined I was using the wrong include file. So I switched to:

#include "atlstr.h"

When I tried to do that, I received similar errors:

C:\Program Files\Microsoft SDKs\Windows\v6.0\Include\ocidl.h(6238) : error C2872: 'IServiceProvider' : ambiguous symbol
C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\atlcomcli.h(370) : error C2872: 'DISPPARAMS' : ambiguous symbol

Several other posts inquiring about the same errors received no answers.

The problem is caused because the Microsoft SDK (aka Platform SDK) and mscorlib both have definitions for these classes.

The solution is to take the #include file that caused the problem and make sure it is placed before any "using namespace" statement. In my case, that meant moving #include near the top of stdafx.h.