Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

A colleague and I have been playing around with the new Provisioning API in Microsoft’s Certificate Lifecycle Manager (CLM) Beta 2 product.  So far, aside from a lack of documentation which I’m told will be forthcoming, the Provisioning API kicks major butt.  It’s going to allow customers and integrators to marry CLM’s powerful PKI deployment capabilities with other scenarios, such as OTP, that Microsoft doesn’t otherwise support.  Kudos to the dev team for pulling off this significant feature addition while under pressure to get CLM v1.0 out the door!

Anyway, what we learned is that Microsoft.Clm.Provision.dll is what’s known as a "2.0 assembly," meaning it was built against the version 2.0 CLR.  To find this information, we ran:

ildasm.exe Microsoft.Clm.Provision.dll

and clicked on the Manifest list item in the resulting window.  Listed dependencies include the following:

.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}
…
.assembly extern System
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}

I believe this also implies that the assembly was built with the 2.0 (presumably C#) compiler.  The net result is that projects dependent on this assembly are not compatible with Visual Studio 2003 (aka Everett), into which the 1.1 CLR and C# compiler are integrated.  Hence, gotta upgrade to 2005 (aka Whidbey)!

I suppose it may be possible to point VS 2003 at the 2.0 compiler and CLR, but I have no idea how to do that, and it sounds very painful.  However, there’s a better option, which also happens to be free:  download the latest Visual C# Express Edition from MSDN and use that instead.  It works - we checked.

Permalink |

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment