I am mainly asking this, as I do have some code in C++ DLLs and I wonder if I should supply a 32 together with a 64bit version (of that DLL) and reference accordingly.
or shall we just stick to x64 output all the way nowdays? I target Windows only
From my understanding, since C# compiles to IL and not machine code, AnyCPU is usually preferred. The IL will then be compiled at runtime to either x86 or x64 depending on the architecture of the platform it’s being run on, which helps ensure compatibility.
I am not an expert here, so actually I’m also a bit curious if there are scenarios here which might make one preferable over the other.
AnyCPU is a concept that doesn’t exist anymore in C#/.NET and it is not possible to make .NET applications that targets AnyCPU (since Core 3.1/NET 5).
This is misleading because Visual Studio (upon creating a new C# project) will still define an AnyCPU configuration (which is not quite an AnyCPU configuration, but instead telling the .NET runtime to use the machine defaults x86 or x64 RID). But when you publish with dotnet publish, you are forced to specify the RID (which can’t be AnyCPU).
TL;DR; AnyCPU is not a target anymore and can’t be one. It is only a debugging commodity meaning “use whatever’s on my computer, I accept the consequences”.
I would suggest targeting x64 from the get go and not caring about anything else.
x86 will be removed from the next release of MonoGame anyway (because it has gone mostly extinct with 0.1% of all Steam users being on x86 systems).
4 Likes
That’s good info, thank you. I’ll went x64 and have not encountered any difference yet (but most likely, that’s what was built anyway)
one issue is that when you don’t use AnyCPU on net6 core libs, and then start adding those targets , in the UI, you get a ton of permutations in your solution… on net6 libraries shared between targets, i keep AnyCpu. but thanks, mrhelmut i think i learned to remove Anycpu from all the exe targets and remove some repeat configurations… if you put arm64, emulators on win64 seems to work still. i dont think any arm32 phones are even still working or newer than 5 years old and its hard to buy one now, anywhere. im not sure if deply to anycPu would result in a bloated package… even if you dont use AOT…
if anyone wants to help make a nice sample that targets consoleDX, windows x64 and xArm, using all shared assets and game core, I don’t see one besides the one I made and its not as clean, formatted perfecly, or simple as possible , but it works for me… if i touch shader. fx it builds, updates and runs w a new result, but i get a warning… that its rebuilding stuff unnecessarily subsequently when i dont touch the core, but i don’t think it is… maybe there is a better way altogether like using a shared project instead of the dll… but i don’t wan any unnecessary repeat code or building…
I just erased all the duplicate configurations, permutations, and target stuff… its just debug and release… i didn’t finish all the deployment and packaging stuff …
i dont have a mac , Linux just a x64 pc and arm64 phone and the emulators… so feel free to add to test it… or make a simpler one… does have render target , some untested shaders, a clipping / masking shader that works, and would maybe save lots of people…like the 4 weeks i spend trying to update to net6 lib and make a simple clip mask shader for GL and DX render targets, lol…