From time to time Microsoft enables strange things in Visual Studio project default settings (which is applied every time you create new project). They seem to be useful in some cases, but in most of them they are more hindering than useful.
So, here are things which should be checked and altered for every new project in VS:
Prefer32Bit
This flag is applied only to applications (.exe) and not to the libraries. Flag can be (which is surprising) changed in project settings (Build tab) or by changing
<Prefer32Bit>false</Prefer32Bit>
in main PropertyGroup of the .csproj file.
What is this? With this flag set, even if your application was built for Any CPU architecture and runs in 64-bit environment, it will run as 32-bit process! Setting
this flag will also set Large Address Aware flag for x86 application, so it, in theory, could operate more than 4GB of RAM but it still will not use
the benefits of 64-bit CPU.
So, ten years (or more) ago we all were happy with appearance of the 64-bit CPUs which allow our code to run faster (in some cases of course). And now the VS enables by default the flag, which disables the 64-bit even for architecture-independent applications.
The source says the following things for the app built with this flag:
- If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
- If the process runs on a 64-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
- If the process runs on an ARM Windows system, it runs as a 32-bit process. IL is compiled to ARM machine code.
If Prefer32bit flag is disabled, the following things will happen:
- If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
- If the process runs on a 64-bit Windows system, it runs as a 64-bit process. IL is compiled to x64 machine code.
- On ARM Windows system the process will not start.
The only difference is ARM Windows, on which the Any CPU C# application will run only with this flag enabled. And for this theoretical possibility we sacrifice the speed of 64-bit CPU.
If you are not planning to run your application on ARM Windows (are there any desktop ARM Windows systems?), it is better to disable this thing.
Deterministic Build
This flag forces the compiler to produce byte equal assemblies for same sourcecode. Usually, every build produces a bit different file as some
data (like the build time PE header field) will change. This flag disables this.
In some cases this will be very effective for automatic artifact merge and similar things. But if you don't care about this stuff and you want to use such fields (for example to show the build date in About window, which is very funny) you should disable this flag.
Microsoft's greater minds decided that this thing will make everyone happy and everyone need to sacrifice the build information for the identical assemblies if the sourcecode was not changed. So there is no legal way to disable this thing for new projects.
The only way to disable this flag is set
<Deterministic>false</Deterministic>
in main PropertyGroup of the .csproj file.
This post will be updated when new strange stuff is added.