In moving servers and workstations to the 64 bit architecture, occasionally you run into ridiculous limitations with components you’ve been used to working with for years… namely, they don’t work. Even Microsoft offers 32-bit only components that fail to load when you try to leverage them through IIS on a 64 bit OS. I just wrapped up a project where I had to accept data posts into IIS that were 3DES encrypted using .NET System.Security.Cryptography objects and had to decrypt them in IIS 6 x64 using Classic ASP.
First, I looked into using Microsoft’s CAPICOM.EncryptedData object, but it turns out they only supply a 32 bit version… no x64 platforms supported. Also, from all the hits on Google, it looked like plenty of people were having issues doing the very same thing I was trying to do, even when they could run the 32 bit CAPICOM SDK.
Quickly I realized the easiest thing to do would be to wrap up the necessary .NET cryptography calls into a COM DLL I could deploy on the 64bit server. This proved WAY more difficult than it sounds. After much fuss I did get it working. I’m posting this so I don’t forget, but I also hope this can help save someone else some time;
– Create a new Class Library project for .NET Framework 4.0
– Remove the default Class1.vb file from the project
– Click the Project menu and select Add Class
– In the Add New Item window, the Class item will be selected by default. Scroll down to COM Class and click on it. This will do several things, including pre-populate the necessary GUIDs required for COM Interop.
– Click the View menu and select the project’s Properties option at the bottom.
– Don’t bother compiling for x86 or x64, just target AnyCPU. Trying to target the CPU type will introduce a number of errors at build time that are not worth working around… at least to me they weren’t.
– You will have to ensure your project is signed to be able to properly deploy the DLL, so sign the assembly and create a PFX key file.
– Build the DLL and deploy to the target server. In my case it was a Windows Server 2003 R2 x64 box. When you deploy the DLL to the target server, try putting it into a folder under “Program Files” and not in \Windows\System32 (or OS equivalent). The security requirements of both the Windows OS and the .NET Framework change from time to time and I was unable to properly run the necessary tools and processes against the DLL when it was located in \System32.
– On the target server, you will have to ensure the tools gacutil.exe and regasm.exe are loaded on the box. The fastest, easiest way to do this is to install the Microsoft Windows SDK for Windows 7 and .NET Framework 4. There are a lot of components you can install, but I just needed the Tools options from each section.
– C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools\gacutil.exe /i “C:\Program Files\MyFolder\File.dll”
– C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /tlb “C:\Program Files\MyFolder\File.dll”
Now your COM DLL should be able to be created in VB6, VBScript, WScript/CScript, and Classic ASP by reference or by the late binding Server.CreateObject method.
Tags: software
