[WIP] Ported core projects to project.json

[khellang]

I'm opening this up early to see if anyone has some feedback... 👀

Currently I have the 4 main projects building for net40, net45 and dotnet5.4 (netstandard1.3), without any code changes 😄
This should cover a minimum of net40, net45, net46, uap10, netcore50 and dnxcore50. I think this includes the Xamarin products as well ✨

I tried to aim for dotnet5.2 (netstandard1.1), which would include minimum win8 and wpa8 as well, but could only get Interfaces to compile. Will give it another go soon. ⌚
I currently don't have the tooling for sl5, wp7 and wp8, so I punted on those for now 👯

All the preprocessor directives are directly from Common.targets, so hopefully they should be good. Anyway, they're a horrible mess and should 🔥 ASAP, once the older targets are deprecated.

There are still a few features that are not supported for project.json yet, like .tt-files etc., so this'll probably have to stay side-by-side for a while 😞

For reference, see the standard platform document.

Should close #148

[khellang]

For some reason this file caused trouble because of a duplicate declaration in the Core project. This one was picked over the other, but it lacked the ImmutableList<T>.Empty property, so it wouldn't compile. The implementations looks pretty similar - is there a reason why this exists?

[shiftkey]

@khellang is there anything in particular I can help with here? (feedback, testing etc)

[khellang]

I don't know. There are still quite a few projects that needs porting, but it would be nice with some feedback on the target platforms. What do we want to support going forward?

[shiftkey]

What do we want to support going forward?

For simplicity's sake, I'd target whatever can be built OOTB in VS2015. But I'm feeling a bit radical this evening and really want to simplify contributing to the codebase.

[clairernovotny]

Is there any reason to support Net4? Microsoft has killed it support-wise too. Only .NET 4.5.2 and higher will be getting security updates.

I don't think there's any point in supporting WP7 or SL5. WP8 is still a stretch, but maybe leave that one for another version/year and kill it then.

[CADbloke]

Is there any reason to support Net4?

I know of weird edge-cases like older versions of AutoCAD that fall over when they see modern things. Most of this was fixed in their service packs but some things break obscurely. Honestly, if a client wanted me to support an older version I'd either drag them kicking and screaming into the present day or make them pay for the custom tweakage. Or walk away.

tldr; Don't listen to the laggards. Modern is good.

[shiftkey]

@onovotny @CADbloke excellent points

@onovotny

WP8 is still a stretch, but maybe leave that one for another version/year and kill it then.

We're talking about the wp Target Platform Name here and not wpa, right?

[clairernovotny]

Yes

[clairernovotny]

Otoh, rxui 6.5 still works for wp8. Maybe housecleaning is in order. 🔥 Wp8 now?

[shiftkey]

@khellang I sat down and tried to get the test project Tests.System.Reactive building - unfortunately that's all using MSTest so it's not really ideal. But here's some more hacking I got to today:

https://github.com/khellang/Rx.NET/compare/core-port...shiftkey:some-build-script-improvements?expand=1

There's a few other projects that are needed by the tests:

• System.Reactive.Providers
• System.Reactive.Observable.Aliases

So I'm just wrapping my head around those and any portability issues right now...

[M-Zuber]

I'd like to have a shot at converting the tests to xunit. I hope to start over the weekend and will update after mondayish if it looks like something I can pull through to the finish. Sounds okay?

[shiftkey]

@M-Zuber 👍 I'm curious what you find out about the migration!

[khellang]

@M-Zuber Before you start doing anything manually, you should know that the Roslyn team wrote a tool that can translate MSTest to xUnit automatically 😄 See https://github.com/dotnet/codeformatter/tree/master/src/XUnitConverter

[M-Zuber]

👍 that's what I was planning on using
😀

Let's hope that all we need to do is run that

[shiftkey]

Just a heads up - if we're going to opt-in for the new way of creating packages, the parent folders must be renamed to match the existing package, e.g System.Reactive.Interfaces becomes Rx-Interfaces

[clairernovotny]

Aren't Xamarin specific impls still needed for some of the light-up? If so, then those can't yet be built with xproj, afaik.

[shiftkey]

@onovotny I have no idea what the support looks like over on that side of the fence...

[shiftkey]

@onovotny it's been a while since I've been looked at WinRT (is it now what we call UWP?), and I'm kinda stumped as to how to resolve types under the Windows.* namespace now that all the dependencies are distributed via NuGet, e.g TypedEventHandler<TSender, TEventArgs>

C:\Users\shiftkey\Documents\GitHub\Rx.NET\Rx.NET\SOurce\System.Reactive.WindowsRuntime\EventPatternSource.cs(15,15): .NETCore,Version=v5.0 error CS0246: The type or namespace name 'TypedEventHandler<TSender, TEventArgs>' could not be found (are you missing a using directive or an assembly reference?)

Some other errors talk about Windows, Version=255.255.255.255 but that's clearly not right:

The type 'IAsyncActionWithProgress<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.

Even referencing Microsoft.NETCore.UniversalWindowsPlatform didn't seem to resolve this, so I'm kinda puzzled what I'm missing here. Thoughts?

EDIT: maybe this just isn't achievable from a xproj due to the custom import for $(MSBuildExtensionsPath)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets?

[clairernovotny]

I believe those types come from Windows.winmd? That's not currently on NuGet; that's part of the SDK. It also may not be possible to build with xproj.

[shiftkey]

@onovotny basically

C:\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.FoundationContract\1.0.0.0\Windows.Foundation.FoundationContract.winmd

Oh well, back to the drawing board on that project...

[clairernovotny]

That's not quite the reference you'd want, it'd be

C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd

However, all is not lost, there might still be a way, but it might require "borrowing" some of the private targeting packages that the corefx team is using

https://github.com/dotnet/corefx/tree/8737f673b55ccd3eee7fbb8f914b5bcbb7c44d7b/src/System.Runtime.WindowsRuntime/src

Needs some spelunking, but I see Microsoft.TargetingPack.Private.WinRT": "1.0.1"

[clairernovotny]

And here it is:

https://dotnet.myget.org/F/dotnet-core/ or
https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Then look for Microsoft.TargetingPack.Private.WinRT 1.0.1

It has a lib\dotnet5.1\windows.winmd in it.

I know it'd be better to use the main nuget feeds, but perhaps later once stuff is baked?

[M-Zuber]

@khellang the MSFT too didn't seem to work for me.
In addition we have to use xUnit 1.9.2 until 4.0 is dropped.
Now converting by hand 💪 and will make a PR onto this when I am done

[clairernovotny]

Don't use xUnit 1.9.2. It's really old and won't work on devices. Just make sure your unit test project is .NET 4.5.

[clairernovotny]

Or better yet, put the unit tests into a shared code project so they can be compiled on different platforms for per-platform testing.

[M-Zuber]

Don't use xUnit 1.9.2. It's really old and won't work on devices. Just make sure your unit test project is .NET 4.5.

I get this, which I do not know where to find

Or better yet, put the unit tests into a shared code project so they can be compiled on different platforms for per-platform testing.

Currently I am working off master. Do I need to be switched to be based off this PR in order to use a shared code project? (either way a pointer or two in how to do would be appreciated as I am not that sure exactly what you mean)

[LeeCampbell]

+1 for dropping .NET 4.0 support. It seems at odds with itself to expect users who don't upgrade (or are on WinXP) to jump to the latest build of Rx :-)

[khellang]

I'll just close this. There's work, based on this, that will bring Rx to the new world of .NET core in the pipeline. Watch #148

[xperiandri]

How to target UWP APIs in .NET Core library project with uap10.0 profile?
@onovotny solution for RT and dotnet5.1 works, but what about uap10.0?

[clairernovotny]

you can use an "imports": ["dotnet5.4"] in the uap10.0 framework section.

[xperiandri]

And just use the Microsoft.TargetingPack.Private.WinRT?

[xperiandri]

Like this?

{
  "version": "1.0.0-*",

  "frameworks": {
    ".NETPortable,Version=v4.6,Profile=Profile32": {
      "imports": "dotnet5.1",
      "frameworkAssemblies": {
        "mscorlib": "",
        "System": "",
        "System.Core": "",
        "System.Collections": "",
        "System.Globalization": "",
        "System.Linq": "",
        "System.Linq.Expressions": "",
        "System.Reflection": "",
        "System.Reflection.Extensions": "",
        "System.Runtime": "",
        "System.Runtime.Extensions": "",
        "System.Runtime.InteropServices": "",
        "System.Windows": ""
      },
      "dependencies": {
        "Microsoft.TargetingPack.Private.WinRT": "1.0.1"
      }
    },
    "uap10.0": {
      "buildOptions": {
        "define": [ "WINDOWS_UWP" ]
      },
      "imports": "dotnet5.4",
      "dependencies": {
        "Microsoft.NETCore.UniversalWindowsPlatform": "5.2.0",
        "Microsoft.TargetingPack.Private.WinRT": "1.0.1"
      }
    }
  },
  "buildOptions": {
    "xmlDoc": true
  }
}