Roslyn: Add compiler switches for /assemblyversion, /assemblyfileversion etc.

[KirillOsenkov]

Right now setting AssemblyVersion and AssemblyFileVersion is done via assembly-level attributes. For many real-world build systems the versions are passed from an external environment (like CI) and build tooling often has logic to generate files like GeneratedAssemblyVersion.cs etc.

The logic to generate these files is prone to issues, such as it often breaks incrementality (file is written to every time, so build rebuilds the entire project even if nothing else has changed). Additionally, every team that wants to stamp versions has to write this MSBuild logic every time from scratch.

Just like signing and keys were added as a compiler command line switch instead of attributes, I propose that two new compiler switches are added, like /assemblyversion:1.0.0.0 and /assemblyfileversion:1.2.0.34512.

In terms of backwards compatibility I think the following precedence rules could make sense:

1. If the version is specified in code via attribute only, use that
2. If the version is specified in command line only, use that
3. If the version is specified both in code and via command line, issue a warning and take the one from code

Do not change default project templates to include the versions. This should be opt-in and people should explicitly pass the version to an MSBuild property for it to take effect.

[eatdrinksleepcode]

+1

[akoeplinger]

+1. What about AssemblyInformationalVersion?

[RedwoodForest]

+1

[rojepp]

+1.
F# already has this. If C#/VB gets it too, there should be a standardized way of passing this information from MSBuild to the different compilers, so you can invoke MSBuild with a version and not have to care about what language each project is built with.

[RichiCoder1]

:+1:
All assembly info should be configurable easily at compile time.

[jenshenneberg]

+1