This question is about the proper use of references to AnyCPU/x64/x86 assemblies from within C# projects to reference objects that have been "exported" by other solutions/projects to a centralized sharing folder.
I have about 50+ C# NET 5 solutions that contain a variety of libraries, CLI executables, COM DLLs, and Windows Forms apps. There are probably 130+ csproj files inside the solution folders, of which probably 70+ produce DLLs and EXEs consumed by other projects (the rest are MSTest projects that do not export anything; they only reference other objects from the centralized folder).
The organization of the build and publish environment is that the build and publish products of all C# projects are "exported" to a centralized folder where they can be shared among all 50+ solutions. All solutions/projects (for now) target the net5.0-windows7.0 framework.
The issues addressed by this question are:
- Should "export from the project" mean (a) "copy unpublished files from the build output folder" (which is what I current do) or does it mean (b) "copy published files from the project publish output folder" (maybe the published assemblies are different somehow than the build output assemblies.)?
In most cases, the files I current "export" (copy from the build output folder) are from the set of six files xxx.dll, xxx.pdb, xxx.exe, xxx.deps.json, xxx.runtimeconfig.dev.json, and xxx.runtimeconfig.json.
I do not normally copy dependency files such as aaa.dll/.pdb from the build output folder of xxx to the centralized folder. Instead, the aaa project exports its own aaa.dll/.pdb/etc files to the centralized sharing folder.
What exactly (AnyCPU, x86, x64) should be "exported" from the build output folders during a build? For example, if I build the world (at different times) with active solution configuration = Debug|x64, do the projects in the build need to export/copy their different build output product permutations (Debug/Release x x86/x64) to separate centralized sharing folders (that each store one variation of Debug/Release x x86/x64 files)?
What exactly (AnyCPU, x86/x64) should be referenced in a centralized storage folder by projects during a build?
For example, if 1 of the 50 solutions is being built with the active solution configuration = Debug|x64, do the project references need to point specifically at Debug|x64 assemblies in a storage folder explicitly for Debug|x64 assemblies? In other words, can solution xxx in Debug|AnyCPU configuration reference a Release|x64 DLL in the centralized sharing folder?
And vice versa - can solution xxx being debugged in Debug|x64 configuration reference a Release|AnyCPU DLL in the centralized sharing folder?
Should I have configuration-specific centralized folders or can I get away with using only one such folder (and if so, what should be in it)? If I get it wrong, I am sure to encounter more of those MSIL architecture-mismatch warnings between an AnyCPU and a specific x86/x64 binary.
I'm trying to identify the "right" way to organize all these 50+ solutions and 70+ projects in alignment with intended MSBuild and VisualStudio methods and mechanisms because it's a big hassle to make even small changes in 70 csproj files or in the build scripts, build and test and publish and test them all, etc. BTW, everything is built and published in parallel too, if that makes any difference.
I'm hoping that other people have been through this many times before and can share their recommendations. Thank you.
This SO question has a nice table in it, but the information is somewhat old. What does the Visual Studio "Any CPU" target mean?
