I've got a VS2013 solution with several projects (a C# WPF application plus class libraries). Each project's "Platform Target" is set to "Any CPU". I was under the impression that the resulting EXE would run as a 64-bit application on a 64-bit PC, and a 32-bit application on a 32-bit PC. Is this correct? My dev PC is 64-bit, but when I run the application (either standalone or via VS debugging), it appears in task manager as "foo.exe *32". What's going on here?
We have a junior developer with a 32-bit machine. Will he still be able to open the solution and run it in VS?
Also, some of the projects reference a 3rd-party DLL. The vendor provides both a 32- and 64-bit version - which one should the projects be referencing? If I reference the 32-bit DLL will this prevent the application from running as a 64-bit application? And if I reference the 64-bit version, will this cause problems for the 32-bit developer? And what about end-users - will my installer need to check the OS version and copy across the appropriate DLL?
Finally, what about DLLs referenced via NuGet? Does NuGet install 32- or 64-bit versions of DLLs? How do I deal with 32- or 64-bit end-user installation?
I'm going to try to answer some of your questions since you've bundled so many into a single one..
We have a junior developer with a 32-bit machine. Will he still be able to open the solution and run it in VS?
Yes, as long as all projects are set to build for Any CPU
and there are no external dependencies on 64bit assemblies or native DLLs.
If I reference the 32-bit DLL will this prevent the application from running as a 64-bit application?
Yes, if any of the assemblies, or COM components linked was specifically built against the 32bit CLR then it will require the whole project to run as a 32bit process. You always have to be careful about native code that your project may be dependant on.
And if I reference the 64-bit version, will this cause problems for the 32-bit developer?
Yes, the 32bit developer will not be able to run the project on his machine, if there are any 64bit assemblies.
As a final thought I'd like to add that it is very important whether the final executable project is built as Any CPU
, or for a specific 32bit or 64bit target platform.
Usually I found that having the final executable built as Any CPU
can cause all sorts of problems at runtime (of the Bad Image runtime exception variety) unless all assemblies linked are also targeted for Any CPU
and there are no external, native, dependencies. This latter requirement is the hardest to ensure.
On the other hand, a final executable built for an explicitly specified 32bit or 64bit platform can happily incorporate other assemblies built for Any CPU
We have a junior developer with a 32-bit machine. Will he still be able to open the solution and run it in VS?
Yes, He can run.
If I reference the 32-bit DLL/ 64-bit will this prevent the application from running as a 64-bit/32-bit application?
The manual edition of the .csproj file(s). You also need separate directories for the different binaries, ideally siblings of each other, and with the same name as the platform you are targeting.
Refer Conditionally use 32/64 bit reference when building in Visual Studio
what about end-users - will my installer need to check the OS version and copy across the appropriate DLL?
Yes, you need to manage build process scripts to create specific version for different architecture..
References:
What does the Visual Studio "Any CPU" target mean?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With