VS build - 32 bit vs 64

ASP.NET 4.0:

My laptop is running 64-bit Win7 Ultimate, using VS 2010 and IIS7.

My dev, staging and production servers are all 32-bit 2003 Server with IIS6 (obviously).

Questions:

I know this is really unsupported, but is there any way I can get IIS6 to run on my laptop under Win7? It'd be nice to keep the configuration consistent between my local environment and the deployment pipeline, but I refuse to go back to XP.
If I compile under VS2010 on Win7 with the "Any CPU" flag set in the target configuration, are the generated assemblies target-independent? That is, are they 64- or 32-bit specific, or will they really work on either one? (My usual method of "try it and see" is not working at the moment for a variety of unrelated reasons).
On my laptop, I have both Framework and Framework64 folders. If the assemblies are target-agnostic, what's the difference between them and the assemblies that VS generates from my code? If they're not target-agnostic, why do I have two separate folders? Is there a performance difference between these two versions?

Thanks in advance.

There's no way, that I know, to run a different version of IIS than what's based on the OS. Since IIS is tied in to the installation of whatever OS you have (6.0 in XP and Server 2003, 7.0 in Vista and Server 2008, and 7.5 in Win7 and Server 2008 R2), you can't install a different version - you'll need an XP or 2003 location to test if you want to use IIS6.
They're target-independent. VS doesn't actually compile machine code - it compiles to IL (an "intermediate language") that the .NET framework on the destination machine (either x64 or x86, depending on what version of the OS is installed) compiles into machine code that works natively. As such, compiling for "AnyCPU" will allow you to run on either. If you prefer, you can target x86 when you compile, and they'll run natively on your x86 servers and using WoW on your x64 machine, so you'll actually be running the exact same code on both.
That just means you have both versions of the framework installed - x64 and x86. The assemblies are target-agnostic, but the relevant version of the framework converts the .NET IL assemblies into machine code that executes natively on the PC. To do that, there needs to be an x86 framework to compile to x86 machine code (if you have an x86 processor), and the same for x64.

Side note: Aren't Win7 and Server 2008 R2 both IIS 7.5?

R. Bemrose 2010-06-17 15:16:03

@ R. Bemrose: HA! I skipped Vista (not on purpose, thought amusingly nonetheless) - I'll update my answer.

rwmnau 2010-06-17 15:17:34

Thanks for the very-complete answer. However, if all assemblies were JIT'd on demand (including, say, System.Web.Services, which I can't imagine is involved in the build process), why include anything other than the Micrsoft.CSharp.*, Microsoft.Build.*, etc assemblies? Are any of these possibly wrappers around unmanaged code, thus requiring them to be pre-built? Maybe I need to point Reflector at a couple of these and see what happens.

David Lively 2010-06-17 15:19:56

I'm not sure exactly what you're asking - does the deployment include specific versions of those assemblies in the package? They should already be installed on the destination client as part of the .NET framework version that's installed. That's the point of the framework - just like any other runtime, such as Java VM or VB600.DLL - it takes input from a "compiled" IL, translates what it's doing into calls that work on the underlying OS, and then executes them natively. This is why Mono works, as well - it takes .NET IL, translates it into native Linux kernel calls, and then runs it for you.

rwmnau 2010-06-17 16:20:15

I understand IL, I understand the compiler. The point is: if everything is JIT'd, why include different versions of the assemblies? If they just contain platform-agnostic IL, the 32- and 64-bit assemblies should be identical.

David Lively 2010-06-18 17:26:24

@David Lively: While the code that .NET generates is platform-agnostic IL, the .NET framework itself is not - since it's responsible for translating the IL into machine-specific code, it's making COM interop OS-level calls, so you'd have to have a different version of .NET for every target environment (x86, x64, IA-64, and Mono, if you want to go there). Are you saying there are different assemblies packaged with your compiled EXE, or are you asking why the framework includes additional assemblies?

rwmnau 2010-06-18 21:37:30

ansaurus

tags:

views:

answers:

VS build - 32 bit vs 64

related questions