Is a 32-bit ASP.NET app running on 64-bit Windows LARGEADDRESSAWARE

I have an existing 32-bit ASP.NET application that used 32-bit unmanaged DL开发者_StackOverflow社区Ls.

If I run this on a 64-bit OS, will it automatically be LARGEADDRESSAWARE (i.e. have access to the full 4GB of virtual memory)?

If not, what can I do to make it LARGEADDRESSAWARE?

Googling turned up this question, but it lacks the answer to the above question.

EDIT

This blog suggests that the ASP.NET 1.1 worker process is LARGEADDRESSAWARE, but is silent about ASP.NET 2.0:

If a system is booted with the /3Gb switch in boot.ini (only supported on Enterprise and Data Center editions of Windows 2000, and all versions of Windows XP and Windows Server 2003) a process that is linked with the /LARGEADDRESSAWARE switch can "see" 3Gb. Aspnet_wp.exe is linked in that way in version 1.1 and can take advantage of that.

EDIT 2

This is another blog that suggests that 32-bit ASP.NET apps are LARGEADDRESSAWARE, but doesn't mention the ASP.NET version:

We found the components that were hosted by the ASP.NET framework were taking advantage of the > 2 gig memory space

I must say I'm amazed at the lack of authoritative published information on this subject.

I managed to get access to a server running Windows 2003 SP2, and the answer appears to be yes, 32-bit ASP.NET applications are LARGEADDRESSAWARE, and have access to the full 4GB of virtual memory.

I established this by:

• examining w3wp.exe (the 32-bit IIS worker process) using "dumpbin /headers". This shows that the LARGEADDRESSAWARE bit is set.

• running a 32-bit ASP.NET application that attempts to allocate over 2GB of virtual memory: this was successful.

I assume the result would be the same for Windows 2008 / IIS7, but haven't tested it.

No it will not. To make it large address aware, you have to run the IIS as a 64-bit application (not running using WOW). This means that your 32-bit unmanaged dlls will have to be replaced with the 64-bit versions of them.

Normally, asp.net will convert to a 64-bit application when selecting the compiler option to target any platform (which is the default). The problem with the 32-bit app you have is that there are unmanaged 32-bit dlls. These cannot run in a 64-bit application. This means that you have to run your ASP.NET application as a 32-bit application which means that you have to install the 32-bit version of IIS on your 64-bit server. The only way to avoid this is to replace the 32-bit unmanaged dlls with ones which are designed to run in a 64-bit environment. A 32-bit application can't use all of the memory on 64-bit server, so your application won't be able to "see" the additional memory.

ASP.NET apps will recompile themselves (providing the target any environment option is set at compile time) in a 64-bit environment, so they aren't 32-bit apps anymore.