Support netstandard2.0


Microsoft now recommends explicitly adding a netstandard2.0 target for libraries that also target netstandard1.x:

Separate to this is Remotion depends on an old version of System.Linq.Expressions that's netstandard1.6, but unfortunately, this package depends on System.Reflection.Emit, which is now delisted:

To fix this, Remotion.Linq should add an explicit netstandard2.0 target. This would not break anyone, but other libraries that target netstandard2.0 will now get the 2.0 target instead of the netstandard1.0 target, and therefore get a much better dependency tree (and don't pull in the delisted package).

Since Remotion.Linq still seems to be a PCL (which should also go away), it might be a bit of work to move to an SDK-style project and away from the project.json stuff.



Michael Ketting
June 19, 2018, 6:38 AM

That an unfortunate situation. As you correctly discovered, we will have to first upgrade to Visual Studio 2017, the Package Reference format, and only then add support for .NET Standard 2.0. This is going to be a non-trivial task, given the prerequisites in the tooling setup and the cleanup required from the quick and dirty way project.json and .NET Standard 1.x has been incorporated. Long story short, I expect this to be several days worth of effort and my work-queue is already overflowing for the next couple of months. So...fall-ish?

User known
June 19, 2018, 1:17 PM

Would you be up for a PR? I've already had to do this for many of my OSS projects.

Michael Ketting
June 19, 2018, 2:00 PM

Thanks for the offer!

TL;DR: this is one task where I never expected to be able to do this via pull requests.

The problem is, there's a lot of moving parts (e.g. the VS2017 upgrade which in turn requires an upgrade of our build script which should be done according to the same way it was done in several other of our projects) and multiple feature branches that build on top of one another and the only documentation available would be to look at another project or two where I did the upgrade first. Then there's the nuspec-file, or rather the switch to the new way the nuspec properties are handled and the correct integration with our build scripts, in case we need to switch to PackageReference, too, in order to support .NET Standard 2.0. And that's before I'll tackle the question of how I want to build a multi-target nuget package going forward. So, basically, re-linq would be the trail blazer for supporting PackageReference and .NET Standard across the entire eco system for re-motion. It might even require updating the build script infrastructure first (which I'm still hoping to avoid for the time being). And most of the work involved there would be taking care of implicit requirements I have for my build infrastructure. Or, I might be able to shortcurcuit some of the problems, do a quick and dirty way similar to what exists now for project.json and avoid most of the adjacent cost. So, I really don't see a way forward without actually getting my own hands dirty.

If you're still reading, yes, I would love some help to get this started, but it would likely be painstaking, tedious, annoying, and I wasn't kidding when I mentioned several days worth of work. The examples of existing migrations would be

And as a final nail for the coffin, legal also requires a signed Contrib License Agreement ( before I can integrate them




User known




Fix versions