Skip to main content

Visual Studio build configuration with x64 "Any CPU"

In Visual Studio you may have noticed, and ignored, the pulldowns in your toolbar which usually contain "Release" "Any Cpu".
The "Any CPU" part in particular is of interest especially if you plan on running your apps on Windows 64.
These configurations are contained in each project and solution i.e. if you open the projects in a text editor you'll see sections in the XML which contain the settings. These settings are also accessible through the Visual Studio UI via the pulldowns mentioned earlier.

The significance of the "Any CPU" is it's telling the compiler to compile the code into assemblies into code which can run on either 32 or 64 bit machines. If your assemblies are used by an application written in 64bit (and of course the app runs on a 64bit machine) then your assemblies will be used in the 64bit context, the same stands for 32bit (of course 32bit apps can also run on 32 or 43 bit machines).
64bit machines have an additional registry section "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node", this section contains registry entries for applications build with "Any CPU" or x86 (32bit). The normal registry section "HKEY_LOCAL_MACHINE\SOFTWARE" is used for pure 64bit apps but if the 64bit OS comes across 32bit apps then it uses the "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node" to get registry settings.
Note to that your installer may target this "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node" section if your assemblies and installer are configured to "Any CPU" or "x86". It may not be what you expect.




Registry.
There are some cavaets around the Registry entries used on 64bit machines. If your application uses registry entries in any way then you'll need to be aware.
When you compile your assemblies with "Any CPU" and your assembly is used by an application written for 64bit then the registry entries used will be slightly different.
(thanks to Miral on the msdn forums)
  • .NET app compiled for "x86":
    • Always 32-bit
    • On 32-bit platforms, accesses 32-bit registry
    • On 64-bit platforms, accesses 32-bit registry (inside Wow6432Node)
      • 64-bit registry inaccessible (without doing something weird)
  • .NET app compiled for "x64":
    • Always 64 bit
    • On 32-bit platforms, won't run
    • On 64-bit platforms, accesses 64-bit registry (not inside Wow6432Node)
      • If you want to get to the 32-bit registry, you need to do something weird
  • .NET app compiled for "AnyCpu"
    • Either 32 or 64 bit depending on platform
    • On 32-bit platforms, accesses 32-bit registry
    • On 64-bit platforms, accesses 64-bit registry (not inside Wow6432Node)
      • If you want to get to the 32-bit registry, you need to do something weird
Labels:

Comments

Unknown said…
so nice article and useful to Dot Net learners. we are also providing Dot NEt online training our Cubtraining global leader in providing in Dot Net course.
3:54 PM
Post a Comment

Popular posts from this blog

dotNET - Debugging

Debugging with .NET MSIL assemblies Visual Studio and debugging the CLR are different, I'll talk about both. MSIL Assemblies Assemblies compiled with .NET tools such as the CLR compiler are compiled into a file which contains MSIL (Microsoft Intermediate Language). At runtime the contents of the assembly are loaded into the CLR and ran as machine code. When you compile an assembly in debug a PDB file is generated alongside the DLL or EXE you've just created. The link between these 2 files is that the PDB contains the line numbers of the methods and classes as well as the file names of the original source code that created the assembly. When you launch the debugger in Visual Studio the assembly is loaded into the Debugger (similar to the CLR) along with the PDB file. The debugger now uses your PDB file contents to match the running code found in the assembly to locations in source files (hopefully in your present project). CLR CLR Inside Out (msdn magazine) .NET Framework Tools:...
7 comments
Read more

Installer CustomAction, Debugging the CustomAction, InstallState

Custom Action The Custom Action is added to the Setup Project, select the Project node and hit the Custom Action button. This allows you add an Action to a particular phase in the Installation. But first you must create the Custom Action. To Add a Custom Action you must first have a Custom Action created, this is usually in the form of a Installer Class, this should be created in a seperate project, the Installer Class is actually one of the File Templates in the C# Projects. So it's File->New Project and select Visual C# Projects. Then add a Class Library, this will prompt you for the Class Library Types , select "Installer Class". Walkthrough - Creating Custom Action (msdn). Also here's a more comprehensive document on Setup/Installer implementations, it delves into the Registry etc Getting Started with Setup Projects (SimpleTalk). Visual Studio Setup Projects and Custom Actions (Simple Talk). Create your Installer Class and then add it as a Custom Action to the ...
3 comments
Read more

Real-time Web Applications

Your application wants to show live data i.e. data sent from Server back up to the Client instead of the usual which is the Client sending data to the Server via a form submit. There are multiple options, currently the best option is WebSockets. Polling Periodically check the Server for updated data, uses SetInterval in Javascript. The Client sends some information to the Server and wants the Server to send back a response, the response is not immediate so the Client wants to wait for the Server but instead of waiting the Client keeps sending requests to the Server and when something is updated on the Server then the Client updates the UI. ( function poll (){ setTimeout ( function (){ $ . ajax ({ url : "server" , success : function ( data ){ //Update your dashboard gauge salesGauge . setValue ( data . value ); //Setup the next poll recursively poll (); }, dataType : "json" }); }, 30000 ); })(); https://...
Post a Comment
Read more