Any CPU vs x64 vs x86

When we compile .net applications/libraries we get IL's, not Machine readable codes. So when we say 'Any CPU'(in a way architecture-neutral PE files) we create neutral IL's, and as part of JIT compilation, output will be either x64 or x86 PE's based on executing machine or calling process.

On a 32-bit machine:

• Any CPU: runs as a 32-bit process, can load Any CPU and x86 assemblies, will get BadImageFormatException if it tries to load an x64 assembly.
• x86: same as Any CPU.
• x64: BadImageFormatException always.

On a 64-bit machine:

• Any CPU: runs as a 64-bit process, can load Any CPU and x64 assemblies, will get BadImageFormatException if it tries to load an x86 assembly.
• x86: runs as a 32-bit process, can load Any CPU and x86 assemblies, will get BadImageFormatException if it tries to load an x64 assembly.
• x64: same as Any CPU.

It is the JIT compiler that generates an assembly code that's compatible with the requested target based on this flag.

Also CorFlags.exe assembly.dll|assembly.exe will tell us whether it is targeted x86 or Any CPU

Just for clarification, CorFlags.exe is part of the .NET Framework SDK. I have the development tools on my machine, and the simplest way for me determine whether a DLL is 32-bit only is to:

1. Open the Visual Studio Command Prompt (In Windows: menu Start/Programs/Microsoft Visual Studio/Visual Studio Tools/Visual Studio 2008 Command Prompt)
2. CD to the directory containing the DLL in question
3. Run corflags like this: corflags MyAssembly.dll

You will get output something like this:

    Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.
Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32CorFlags  : 3
ILONLY    : 1
32BIT     : 1
Signed    : 0

The key is the "32BIT" flag as documented above: 1 = x86; 0 = Any CPU.

·        Any CPU: PE = PE32    and  32BIT = 0

·         x86:         PE = PE32    and  32BIT = 1

      ·         x64:         PE = PE32+  and  32BIT = 0

Compilation and Deployment in ASP.NET 2.0

Just for my reference, good article from Rick Strahl

500.0 Internal Server Error - aspnet_isapi.dll failed in IIS 7.5

If you experience '500.0 Internal Server Error - aspnet_isapi.dll failed' even after trying all possibilities like 'aspnet_regiis -i' etc..., just uninstall IIS and Re-install again, it just works. It is Microsoft:)

I faced this when i installed Framework 4.0, so uninstalled IIS 7.5/Framework4.0 and re-installed both.

Error message when you visit a Web site that is hosted on IIS 7.5: "HTTP Error 404.17 - Not Found"

This article might help, but we need to look for three things particularly

configure the following settings to match the handler requirements:

• .NET Framework Version
• Enable 32-Bit Applications
• Managed Pipeline Mode

HTTP 500.0 - Internal Server Error in Windows 2008 R2 Server

After deploying a 32-Bit WCF service in IIS 7.5(Windows 2008 R2 server), browsing the service failed with
HTTP 500.0 - Internal Server Error, and from the error message i figured out something wrong with PageHandlerFactory. For 32-Bit web apps, it is mandatory to set 'Enable 32-Bit Applications' to 'True'. We can either set it @ 'Application Pool Defaults' or the specific Application Pool in question.

Sample powershell scripts

ProjectDir - Project Folder
OutDir - either bin\debug or bin\release or whatever set as output directory

1. To Copy files from 'some folder' into output directory  - below copies everything from 'libs' folder which is at same level as that of our Project directory into Project directory's output.

    copy /Y $(ProjectDir)\..\libs\* $(ProjectDir)\$(OutDir)\

to be contd....

BadImageFormatException in Windows 2008 R2 Server

I successfully imported PowerShell Script written using C#, but it throws System.BadImageFormatException when i tried to execute it. After spending few hours, figured out my Powershell Script was compiled for x86, so i should have used “c:\Windows\SysWOW64\WindowsPowerShell\v1.0”.