Create Multi-targeting projects for .NET 4.5, .NET Standard, .NET Core, and Portable-win8-wpa81

[jkoritzinsky]

I'd love to be able to use SharpDX from .NET Core as well as .NET Standard without needing to add in platform fallbacks. Additionally, multitargeting .NET Standard as well as Portable-win8-wpa81 would allow "portable" store app support (for Windows 8+ and Windows Phone App 8.1+ apps), while having a truly portable reference library for across desktop and store platforms with .NET Standard.

This is blocked by #863 and would fix #844 as well as #699.

[xoofx]

Now that the new csproj for .NET Core is released with VS2017, it is a much more reachable goal.

I don't have spare time to work on this. This will require quite some work, but I don't see anything blocking but it might be a little bit more complicated if we want to build everything - Win10 API and non Win10 API in the same build, as currently it is two separated process (generated files are currently overwriting the same files, and are run twice, so we might want to generate two sets of files with proper #ifdef instead)

The nice thing is that we can get everything build into a same solution, so we would get netstandard support but we could also even re-introduce support for .NET 3.5 and specific assemblies for .NET 4.0 desktop...

A PR is welcome.

[jkoritzinsky]

The only blocking part is that SharpDX requires VS2015 update 3 to be installed on a machine, so SharpDX cannot be built with VS2017 only. That's being tracked in #863.

[xoofx]

well, It is not really blocking, it is just part of this same job (migration to VS2017) 😅

That being said, you are right that compiling to VS2017 and getting gccxml working, could be a pain (did that a couple of time for every VS upgrades for the past 6 years and it was always laborious as you have to patch C++ headers files that are not correctly understood by gccxml...). I can explain the process of reporting the patch from VS2015 to VS2017 include files, if you are willing to dig into this PR.

[jkoritzinsky]

I don't know how much time I have for porting the gccxml stuff over but definitely explain the process on case I or someone else has time!

[jkoritzinsky]

Another thing to look at that might be easier is GCCXMLs successor CastXML. Might be easier to port over for future versions.

[xoofx]

Another thing to look at that might be easier is GCCXMLs successor CastXML. Might be easier to port over for future versions.

There was already a port done to CastXML in the past https://github.com/sharpdx/SharpDX/tree/sharpgen_castxml I can't recall the status of this branch, afair, I guess it was somewhat working... I just didn't have time to fully check it and integrate it...

[jkoritzinsky]

@xoofx I'm almost finished moving everything to CastXML with only dependencies on VS 2017. There's only one problem: VS 2017 drops support for Win8.1/WPA8.1 projects and the AppVeyor image for VS 2017 does not have them installed. So, we are kind of stuck on .NetStandard vs Windows Apps pre UWP support. What do you think?

[xoofx]

I'm almost finished moving everything to CastXML with only dependencies on VS 2017

Cool!

VS 2017 drops support for Win8.1/WPA8.1 projects and the AppVeyor image for VS 2017 does not have them installed. So, we are kind of stuck on .NetStandard vs Windows Apps pre UWP support. What do you think?

That's fine drop support for W8.1/WPA8.1. We will follow what VS is doing. People looking for this support will have to download an older version of SharpDX

[bdachev]

I am not sure if that is what you are looking for but Win8.1 SDK and support can be added to VS2017 via installer. It is just an optional component.

[jkoritzinsky]

Its not on AppVeyor (our CI system) so we wouldn't be able to use it anyway.

[xoofx]

Its not on AppVeyor (our CI system) so we wouldn't be able to use it anyway.

Are you sure actually? Afair, for VS2015, they were including stuffs that are not installed by default (like Win8 dev tools, C++, even Xamarin...etc.)

[jkoritzinsky]

Yep. Take a look at the preinstalled software on AppVeyor here. The third column is the VS2017 instance. Only has Windows 10 SDKs.

[xoofx]

But one thing I don't understand (It has been a long time I touched this part and I forgot a bit all the details), but the mapping.xml is using only the Windows10 SDK headers (though just above we are still using the VS 2015 C++ headers.... that's the part that would have required some work with gccxml)...