When migrating to a 64-bit Windows Server, one of the things a developer has to consider is how to continue to use any 32-bit COM components that they might have referenced in their applications. A common example would be any file uploaders or data encryption tools generally used by legacy ASP applications prior to a migration to .NET. Handling this in IIS for your .NET application is easy enough: you can set up your IIS process to run in 32-bit compatibility mode and it will load up your 32-bit COM components quite nicely. Configuring this is relatively straightforward:
- Open a command prompt and navigate to the %systemdrive%\Inetpub\AdminScripts directory.
- Type the following command: cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 true
- Press ENTER.
However, the developer will run into a similar problem when trying to get a windows service or an executable to load the same 32-bit COM component. It is not immediately apparent looking through the Services list or at the properties of the exe how to configure it to run as a 32-bit process. Even the "Run As..." feature of Windows will not accomplish this.
There is a conversion exe that ships with Visual Studio as part of the Microsoft SDK that allows the developer to configure an exe to run in 32-bit compatibiity mode just like IIS does. Configuring this is also fairly easy:
- Open a command prompt.
- Type the following command: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags.exe full path to your exe /32BIT+
- Press enter.
There is one catch. If you don't set this flag as part of your build or deployment processes prior to deploying your code, you will have to manually set it each time your executable is deployed to a server. But once done, your .NET applications will be able to work with your 32-bit COM components as expected.