CAPICOM ... UGH!

tag:blogger.com,1999:blog-9537945.post-50396683060014205532008-01-22T22:56:00.000-06:002008-01-22T23:30:22.978-06:00CAPICOM ... UGH!I'm working on an install that requires me to write some custom actions to interact with the certificate stores. I seems there are four different ways to do it out there: <a href="http://msdn2.microsoft.com/en-us/library/e78byta0(VS.80).aspx">certmgr.exe</a> : The way the developer suggests doing it. Of course it's a .NET SDK utility with redist rights. <a href="http://msdn2.microsoft.com/en-us/library/aa380256(VS.85).aspx">cryptoAPI</a> : Win32 API <a href="http://msdn2.microsoft.com/en-us/library/aa375732(VS.85).aspx">CAPICOM</a> : Scriptable COM <a href="http://msdn2.microsoft.com/en-us/library/system.security.cryptography.x509certificates.aspx">System.Security.Cryptography.X509Certificates</a> : .NET Framework After a whole lot of digging I decided ( for now ) to settle on CAPICOM. I found the <a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=860EE43A-A843-462F-ABB5-FF88EA5896F6&displaylang=en">CAPICOM SDK</a> and example VBScript file that shows how to load a certificate into the store. I quickly ported that over to InstallScript and bingo, it all worked. Of course there is a catch. This has added a dependency to CAPICOM.dll to my install. This wouldn't be so horrible except the Microsoft team that created CAPICOM obviously doesn't have the first frigging clue about how Windows Installer works. They seem to think that <a href="http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/cdb11c8f-36cb-41f6-9ae3-7ba084030877.mspx?mfr=true">xcopy to system32 regsvr32</a> is the appropriate way to deploy this ActiveX control. There are tons of references that say CAPICOM is redistributable but the only MSI available is for the entire SDK. There is no merge module or prereq package containing just the ActiveX runtime control. So I do some googling and I find an <a href="http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg02835.html">old thread</a> from WiX-Users with a good discussion on the component rules and why this is a problem. Finally I stumbled across a <a href="http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=924350&SiteID=1">Windows Installer log</a> file that indicates Visual Studio C# Express deploys the file to C:\ProgramFiles\CommonFiles\Microsoft Shared\CAPICOM as ComponetID {9504EA7B-206D-4178-8E37-EF70AE544903},. Ugh, Can we say DLL HELL?!?!? Well I suppose since the application I'm deploying targets .NET 3.5 that I could just go ahead and use the x509Store class that's in the .NET BCL but 1) I haven't tested that yet and 2) Microsoft employees keep trying to convince me that <a href="http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx">managed code custom actions are evil</a> while at the same time they <a href="http://weblogs.asp.net/sweinstein/archive/2004/10/06/238891.aspx">compain that other infrastructure API's don't target the CLR</a>. ( Yes, notice even Rob Mensching joining in wishing that Windows Error Reporting supported .NET! ) Finally I found a <a href="http://www.codeguru.com/Cpp/I-N/internet/security/article.php/c6211">Code Guru project</a> using CryptoAPI writtten in C++. I tried running the sample exe but wouldn't you know it.... it was a debug EXE with a dependency on MFC42D.dll. The cryptoAPI example is probably the purist way to go in terms of eliminating the dependency but jeesh, it shouldn't have to be this hard. What's 3 lines of script becomes pages of C++. I once mentioned capicom in a previous post and now I know why I get so many hits for it on my statcounter. Someone please slap me and remind me that I actually LIKE setup!Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.com