This is not news: .Net framework 2.0 will have 64 bit edition. As expected, Microsoft only support 64 bit chips from Intel And AMD. Namely, IA64 Architecture and AMD64 Architecture.


You can download .Net framework 2.0 beta1 for IA64 and x64 now from


.NET Framework Version 2.0 Redistributable Package Beta 1 (IA64)


.NET Framework Version 2.0 Redistributable Package Beta 1 (x64)



The size of the 64 bit redist is almost double of x86's redist. This is because 64 bit redist contains both the 64 bit runtime, as well as the 32 bit runtime.


64 bit Windows has a special feature called "Windows on Windows" (WOW), This is the way to run 32 bit applications unmodified (in most cases) in 64 bit Windows.


The 64 bit .Net framework 2.0 redist will install both the 64 bit runtime, as well as 32 bit runtime.  64 bit framework is installed to %windir%\Microsoft.Net\Framework64 directory, and 32 bit framework is installed to %windir%\Microsoft.Net\Framework directory.


In theory all .Net assemblies are compiled to Microsoft Intermediate Language (MSIL). So there should have no need for 32 bit runtime in 64 bit Windows.


Unfortunately there are Mananged C++ assemblies (so called IJW assemblies), which contain MSIL code, as well as assembly code. If the assembly contains x86 assembly code, it cannot run under 64 bit mode.


And there are 32 bit applications hosting CLR. Those applications can't use 64 bit CLR.


So we have to ship both 64 bit CLR, and 32 bit CLR, in 64 bit Windows.


Back to Managed C++ assemblies. If the assembly developer wants to let both 64 bit application and 32 bit application to use the assembly, the developer has to ship two copies of the assembly, one for 64 bit, one for 32 bit (In fact, the developer will have to provide one assembly for each processor architecture). What distinguish the two assemblies, is the new assembly attribute --- ProcessorArchitecture.


If you run "gacutil -L" on .Net framework 2.0 beta1, you will see outputs like this:


mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089,  ProcessorArchitecture=x86

System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL


Every assembly compiled with .Net framework 2.0 will have ProcessorArchitecture. There are four ProcessorArchitecture defined today: x86, MSIL, IA64, and AMD64. Assemblies with ProcessorArchitecture of x86, IA64 and AMD64 is called platform specific. They can only run under the specific platforms. Assemblies with ProcessorArchitecture of MSIL are portable and can run under any platform.


Assemblies compiled with .Net framework 1.0 and 1.1 will not have ProcessorArchitecture. In 64 bit Windows they can only run in 32 bit mode.


Managed C++ assemblies are automatically platform specific. By default C#/VB.NET/Jscript.Net assemblies are compiled as MSIL. But all the compilers (csc.exe/vbc.exe/jsc.exe) provide a command line option to allow you to force compile the assembly as platform specific (See documentation of each compiler, look for /platform). In Visual Studio, in build tab under Project properties, you can specify which platform this assembly wants to support.


When do you want to compile your assemblies as platform specific?


  1. Managed C++ assemblies. You don't get a choice here.
  1. Assemblies with Managed C++ modules. Systerm.EnterpriseServices.dll is an example. It has a module System.EnterpriseServics.Wrapper.dll written in Managed C++.
  1. Your assembly uses platform dependent system services, like P/Invoke. Not every assembly with P/Invoke has to be compiled as platform specific. It is only required if the behavior of the unmanaged API differs in different platform. Mscorlib is an example. It tights to the platform specific runtime.
  1. Your assemblies behave differently in 32 bit mode and 64 bit mode. Caspol.exe is an example. The 32 bit caspol.exe manages CAS policies of 32 bit runtime, and 64 bit caspol.exe manages that of 64 bit runtime. It is necessary to have two copies of caspol.exe in 64 bit Windows.