Support MSBuild properties on the CLI

[dawedawe]

@baronfel Is that roughly what you had in mind in #84 ?

With it we can do things like:

-p Configuration=Release -p DefineConstants="MYDEF" ...

[baronfel]

Yep! This would do the base-level support - though MSBuild properties can be passed via -p in a number of different formats. You can see the tests we have in the SDK for our own parsing of the various formats here. I think simple key=value pairs are the most common, but automated tools especially love to use the more complex formats.

[dawedawe]

Thanks for the pointer. These should all work now with -p or -p: or --property.

[dawedawe]

If the following mapping to MSBuild properties is correct, I think this PR is ready for review (not sure about OS):
-r maps to RuntimeIdentifier
-a maps to Platform
--os maps to OS

[baronfel]

--os and --arch map to different components of a RuntimeIdentifier. Take linux-x64 for example - the linux portion is the OS, and the x64 portion is the arch. This isn't a hard-and-fast rule, however - the Runtime Identifier linux-musl-x64 has an os of linux-musl and an arch of x64.

The dotnet CLI errors if arch/os are provided at the same time as -r, and it 'fills in' any missing pieces of the final RuntimeIdentifier from arch/os with the arch/os of the current SDK. So a user specifying --arch arm64 on a linux device would end up passing -p RuntimeIdentifier=linux-arm64 to the build.

[dawedawe]

Ah okay sorry, I had some bigger misunderstanding then.
So I need to find a way how to query programatically the correct string values for os and arch then...

[baronfel]

The 'correct' way to get the RID for the currently running SDK is here - but it is very, very gross.

[dawedawe]

So System.Runtime.InteropServices.RuntimeInformation.RuntimeIdentifier can be wrong in some cases?

[baronfel]

oh, great idea - that should be fine for your needs. I think the SDK has some layering problem where it can't necessarily rely on that.

[dawedawe]

Ok, thanks a lot for all your help here!

[nojaf]

Can properties be combined with --fsc-args?

[dawedawe]

I expect they can be combined but I'll test next week.

[nojaf]

My initial thinking is that they cannot. Properties would influence the project cracking I assume and we skip that entirely when using --fsc-args.

[dawedawe]

As we discussed, while we could shoehorn some parts from the properties into the fsc-args, it would be against the idea of fsc-args, so let's disallow that.

[dawedawe]

With the RuntimeIdentifier being constructed with --arch and --os if given, I hope this is ready now.

[nojaf]

Looks good, ship it!