I recently needed to get an ASP.Net 1.1 application working on Windows Server 2008 R2. I naively assumed that this was just going to work but then the whole 32/64 bit problem emerged.
.Net 1.1 is 32 bit only and Server 2008 R2 is 64 bit only! Well – WOW64 has been around quite a while so surely this would be a piece of cake. I proceeded to download the .Net Framework Version 1.1 Redistributable Package and when you attempt to install – you get your first hint about the potential problems ahead.
At this stage – you have 2 choices:
- Attempt to upgrade your application to a 64 bit version of the framework
- Attempt to get .Net 1.1 working on Server 2008 R2
My preference was to get .Net 1.1 working as I didn’t want to go through a test cycle for an application I didn’t really understand on a new version of the framework. However – rather than just choosing “Run Program” from the Program Compatibility Assistant dialog – I did some research and used the following process to get my application to work.
1 - Install IIS Metabase Compatibility
To install on Windows 2008 Server – click Start and then “Server Manager”.
Under Web Server (IIS), click Add Role Services.
Ensure that IIS Metabase Compatibility is installed.
2 - Install .Net 1.1
I installed .Net 1.1 in the following order:
I still got a compatibility warning, but chose “Run Program” to continue.
Installing Service Pack 1 is likely to require a reboot.
3 – Enable ASP.Net 1.1 ISAPI Extension
Following the steps in option 2 made ASP.NET v1.1.4322 available on my ISAPI and CGI Restrictions dialog, but was disabled by default. Open Internet Explorer, click on your server name and choose ISAPI and CGI Restrictions from the IIS section. Enable ASP.Net v1.1.4322 as a valid ISAPI extension.
4 – Adjust machine.config
We need ASP.NET 1.1 to ignore IIS configuration sections, so open machine.config for Framework 1.1 (%windir%\Microsoft.NET\Framework\v1.1.4322\config\machine.config) and add the following towards the end of configSections.
1: <section name="system.webServer" type="System.Configuration.IgnoreSectionHandler,
2: System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
5 – Adjust the Application pool
I now needed to tell my application to use the application pool ASP.NET 1.1. Use IIS Manager, choose the site that you are working with and choose “Advanced Settings”. Adjust the application pool to use ASP.NET 1.1 which will use .Net Framework 1.1.
6 – Fix applicationHost.config bug
IIS runtime detected that I was running on a 64 bit operating system, so it attempted to load .net framework configuration from Microsoft.Net\Framework64, but this doesn’t exist for .Net Framework 1.1. The solution is to copy the 32 bit version into the appropriate 64 bit folder.
- Create \Windows\Microsoft.net\Framework64\v1.1.4322\config
- Copy machine.config from \Windows\Microsoft.net\Framework\v1.1.4322\Config\
7 - Check any application registry settings
My application relied upon a number of custom application registry settings. In the 32 era – this wasn’t a problem as registry settings were in the “same” expected place. e.g. most people put registry settings under HKEY_LOCAL_MACHINE \ SOFTWARE someplace. However – on a 64 bit machine – the 64 bit software settings are stored in this expected place, while 32 bit settings are stored under HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node.
This is probably easiest to explain by giving an example. My application needed to access HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ConfigurationManagement \ hashKey. In order to make this setting available to a 32 bit application running on a 64 bit server, you need to store the key as HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ ConfigurationManagement \ hashKey.
I initially exported the keys from an existing Server 2003 machine and imported them onto Server 2008 which put them into HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ConfigurationManagement \ hashKey. This is where Windows expects you to store your 64 bit settings, so you need to move them to the corresponding location under Wow6432Node.
This caused a lot of pain and confusion trying to understand why my application couldn’t read registry settings which were obviously there. The solution is to put your 32 bit registry settings where your 32 bit application will attempt to read them – under Wow6432Node.
Some useful references for understanding the 32/64 bit registry issues are:
Finally, after following all of the above – my 32 bit .net 1.1 application was working correctly on Server 2008 R2.