Adding crosstargeting in order to be able to call WinRT APIs in net5.0

[joperezr]

Fixes #1091
Fixes #1103
Fixes #1193

cc: @richlander @pgrawehr @Ellerbach @krwq @ericstj @terrajobst @jkoritzinsky @dsplaisted

This PR will add cross-targeting to System.Device.Gpio package so that it will now have 3 different assets in the package:

• One netstandard2.0 asset: This will be used by consuming apps that are targeting netstandard2.0 compatible frameworks that are not net5.0. Nothing has changed from this asset from what we shipped before.
• One net5.0 asset: This asset will be for people targeting net5.0 that don't intend to target Windows. This implementation is very similar to the netstandard2.0 one, except that it will now throw platform not supported exceptions when running on Windows and trying to use types that depend on WinRT APIs.
• One net5.0-windows10.0.17763.0 asset: This asset will be for people targeting net5.0 that want to run in Windows. It will be using the new CSWinRT project to call into WinRT APIs and don't depend on System.Runtime.* package any longer. In order for folks to get this asset, they will need to change the target frameworks section in their projects and add net5.0-windows10.0.17763.0 so that the package will work at runtime. This is a breaking change

As explained above, when running on net5.0 and targeting Windows it will be required to edit the target frameworks section of the project. This is the only way to get this working for now, and we are looking into some embedding scenarios (once CSWinRT supports them) so that we can change the way we distribute our package so that consuming projects won't require to cross-target. As part of this change, we are also adding a targets file with the package that will try to detect cases where cross-targeting is required, in order to catch those cases early and give helpful messages to consumers so that they can change their project accordingly. Here is how the package will look now:

And here are the package dependencies after this change:

Any feedback is appreciated 😄

[joperezr]

@dsplaisted looking at the CI failures seemed like the problem is that the net5.0-windows build was failing on Linux and OSX as apparently, you can only build for that TFM with a Windows SDK. Is that by design or will support for targeting windows from a non-windows machine will be added eventually? I just added a change that disables Windows-specific build on non-Windows but this scenario seems kind of busted as in theory you would only need the Windows targeting pack and we have supported in the past targeting TFMs that might not necessarily run on the machine you are in, this also means for us that our Linux and OSX contributors won't be able to make changes and build windows specific files.

[dsplaisted]

@dsplaisted looking at the CI failures seemed like the problem is that the net5.0-windows build was failing on Linux and OSX as apparently, you can only build for that TFM with a Windows SDK. Is that by design or will support for targeting windows from a non-windows machine will be added eventually? I just added a change that disables Windows-specific build on non-Windows but this scenario seems kind of busted as in theory you would only need the Windows targeting pack and we have supported in the past targeting TFMs that might not necessarily run on the machine you are in, this also means for us that our Linux and OSX contributors won't be able to make changes and build windows specific files.

It's by design for now. Hopefully when we have optional workload support we'll eventually make the Windows optional workload work on other operating systems.

If you just want to use the types, you may be able to add an Update statement to set the IsWindowsOnly metadata to false for the KnownFrameworkReference items for Windows.

[joperezr]

If you just want to use the types, you may be able to add an Update statement to set the IsWindowsOnly metadata to false for the KnownFrameworkReference items for Windows.

I actually expect very few people to actually want to change things on the Windows-specific build for now, so I'm fine with just not building it on Linux and OSX at the moment, but my 2 cents here are just that it would be great to either document the isWindowsOnly metadata workaround for other folks or to allow people to target different platform than the one they run in.

[pgrawehr]

I do want to fully understand what's going on here (so far I honestly don't get it yet). Please do not merge before I can take an adequate review.

[joperezr]

@pgrawehr see the description where I added info on the three assets distributed by the package and when would each apply. In there I provide a high level description of what is changing with this PR, but if you have any follow up questions, I’m happy to answer.

[pgrawehr]

I think the PR lacks files. This directory is empty for me (except for "Interop.WaitForCompletion.cs", which only contains a helper method).

Besides, I don't understand why "net5.0" or not would have anything to do with Windows or not.

[joperezr]

I think the PR lacks files. This directory is empty for me (except for "Interop.WaitForCompletion.cs", which only contains a helper method).

I know this is the only WinRT file today, but I used wildcards as any file that goes in it in the future would have to be removed, and because everything is added to all configurations by default, I wanted to make sure that we guarded against new files or renames.

Besides, I don't understand why "net5.0" or not would have anything to do with Windows or not.

Our net5.0 configuration is effectively a non-Windows build since we want everyone targeting net5.0 and Windows to use the net5.0-windows version instead. That is why net5.0 version now throws anytime you are trying to use anything that relies on WinRT code.

[joperezr]

I'll merge this now to unblock progress on getting the repo ready for shipping our 1.1 release but feel free to let me know if there are any additional comments/questions around this change and I'm happy to address/answer them.