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)...

[jkoritzinsky]

The issue is generating the .pri files for the Windows 8.1 and Windows Phone 8.1 packages. We can use the Windows 10 SDK headers but we can't build the full packages for Windows 8.1 and Windows Phone 8.1 on VS2017 without the Windows 8.1 SDK installed.

[xoofx]

ah ok, it makes sense... so no problem to drop support for them...

[jkoritzinsky]

Btw I've already got SharpGen updated to CastXML. I'm updating the projects now to use the new VS2017 project system. It's going pretty smoothly!

[xoofx]

Yeah, I expect the new project to simplify a lot the whole process, that's good! Have you tried to merge desktop and storeapp sln and make SharpGen run twice (for both) but keep the generated files for both? (either add a #ifdef and append to the generated files or generates another set of cs files with #ifdef...)

[jkoritzinsky]

Yep. Because there's the define in Mapping.xml for the different API partitions, I set up SharpGen to take in an app type (DESKTOP_APP or STORE_APP) as a command line argument. For each target framework SharpGen will generate the needed API subset. There's definitely some optimization opportunities there for the future.

[xoofx]

Excellent! 👍

[JimSEOW]

OpenTK is now moving towards .NET Standard 2.0 and starting today, .NETStandard 2.0 is now extended to UWP through UWP6.0

Perhaps SharpDX can follow too!

[xoofx]

It is already the case. SharpDX supports .NET Standard 1.1

[JimSEOW]

To bring SharpDX to support UWP in the presence of other .NETStandard 2.0 library, we need to compile under

• .NET Framework 4.61,
• .NETStandard2.0,
• .NETCoreApp2.0
• UWP6.0

[xoofx]

I don't understand what you are referring to.

SharpDX is compiled with .NET Standard 1.1 (and CoreApp1.0, UAP 10.0) so it should be defacto compatible with any upper version, so it is working fine with any .NET Standard 2.0. We shouldn't have to recompile anything.

[JimSEOW]

@xoofx, I just tested the latest nuget and it confirms the strange results I have. (a) The UWP XAML interop sample only works with "TODAY" released W10M emulator 15240, not even with W10M physical 950XL running 15240 and W10 running 16232. => We need to encourage more users to share their experience so that new users are not frustrated when something not working (especially with UWP(XAML) sample). => The typical view that the old Window Store sample based on 8.1 could easily be ported to W10 or W10M is not so trivial. => Most of the users are using SharpDX for non UWP(XAML) situation. I believe. We do not have enough feedback for UWP(XAML).

I don't understand what you are referring to.

(b) To support .NETStandard 2.0 environment. Here is the requirements

[xoofx]

No this is not the way this table is working. All versions before .NET Standard 2.0 are compatible with it. So 1.0, 1.1, 1.2, 1.3..etc. are compatible with 2.0. That's the way .NET Standard is working.

For UWP specifically, please keep this discussion on a single issue. It is becoming annoying to receive multiple message on different issues for the same problem.