Conditionally use 32/64 bit reference when building in Visual Studio

One .Net build with x86/x64 Dependencies

While all other answers give you a solution to make different Builds according to the platform, I give you an option to only have the "AnyCPU" configuration and make a build that works with your x86 and x64 dlls.

Resolution of correct x86/x64-dlls at runtime

Steps:

1. Use AnyCPU in csproj
2. Decide if you only reference the x86 or the x64 dlls in your csprojs. Adapt the UnitTests settings to the architecture settings you have chosen. It's important for debugging/running the tests inside VisualStudio.
3. On Reference-Properties set Copy Local & Specific Version to false
4. Get rid of the architecture warnings by adding this line to the first PropertyGroup in all of your csproj files where you reference x86/x64: <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>

5. Add this postbuild script to your startup project, use and modify the paths of this script so that it copies all your x86/x64 dlls in corresponding subfolders of your build bin\x86\ bin\x64\

   xcopy /E /H /R /Y /I /D $(SolutionDir)\YourPathToX86Dlls $(TargetDir)\x86 xcopy /E /H /R /Y /I /D $(SolutionDir)\YourPathToX64Dlls $(TargetDir)\x64

   --> When you would start application now, you get an exception that the assembly could not be found.

6. Register the AssemblyResolve event right at the beginning of your application entry point

   AppDomain.CurrentDomain.AssemblyResolve += TryResolveArchitectureDependency;
   

   withthis method:

   /// <summary>
   /// Event Handler for AppDomain.CurrentDomain.AssemblyResolve
   /// </summary>
   /// <param name="sender">The app domain</param>
   /// <param name="resolveEventArgs">The resolve event args</param>
   /// <returns>The architecture dependent assembly</returns>
   public static Assembly TryResolveArchitectureDependency(object sender, ResolveEventArgs resolveEventArgs)
   {
       var dllName = resolveEventArgs.Name.Substring(0, resolveEventArgs.Name.IndexOf(","));
   
       var anyCpuAssemblyPath = $".\\{dllName}.dll";
   
       var architectureName = System.Environment.Is64BitProcess ? "x64" : "x86";
   
       var assemblyPath = $".\\{architectureName}\\{dllName}.dll";
   
       if (File.Exists(assemblyPath))
       {
           return Assembly.LoadFrom(assemblyPath);
       }
   
       return null;
   }
   

7. If you have unit tests make a TestClass with a Method that has an AssemblyInitializeAttribute and also register the above TryResolveArchitectureDependency-Handler there. (This won't be executed sometimes if you run single tests inside visual studio, the references will be resolved not from the UnitTest bin. Therefore the decision in step 2 is important.)

Benefits:

• One Installation/Build for both platforms

Drawbacks: - No errors at compile time when x86/x64 dlls do not match. - You should still run test in both modes!

Optionally create a second executable that is exclusive for x64 architecture with Corflags.exe in postbuild script

Other Variants to try out: - You would not need the AssemblyResolve event handler if you assure otherwise that the dlls get copied in your binary folder at start (Evaluate Process architecture -> move corresponding dlls from x64/x86 to bin folder and back.) - In Installer evaluate architecture and delete binaries for wrong architecture and move the right ones to the bin folder.

I ended up using what I consider an easier solution that is sort of an inversion of Micke's. The project is a C# forms app, Visual Studio 2015, with x86 and x64 targets. I referenced one of the .NET assemblies, I used the 32 bit one. In the reference properties, I set "Copy Local" to false. Then I just manually put the appropriate (32 or 64 bit) .Net assembly in each target directory. The actual reference bitness is irrelevant, assuming they have the same capabilities, since it's just defining the external interface. You could also put a post build copy step if you wanted to get fancy. Note this project also had a COM reference, same thing works. The reference defines the objects/interfaces so the bitness of the reference DLL is irrelevant. If both 32 bit and 64 bit COM DLLs are registered, the app will look in the appropriate place in the registry and create the correct 32 or 64 bit COM object. Works for me!