Support for Generative Type Providers when targeting .NET Core 2.0

[dbettin]

From #2400:

This also takes a dependency on RefEmit. We’ll need to investigate this further, since it’s currently not on the .NET Core 2.0 roadmap

[dbettin]

Also would like to add this comment here from @KevinRansom on #2400:

The problem with generative TypeProviders is that ref emit on coreclr doesn't implement Save(). Ref emit is not actually a part of .Net Standard 2.0 the System.Reflection.Emit package will work with fine with .Net Standard 2.0, it's just those Apis are not part of the .Net Standard set of Apis and so ... there is no urgency to improve it's desktop compatibility. The problem for F# is that generative type providers need to produce a P.E file and since the the Save() API doesn't exist, we need a clever solution to that problem. There are in fact plenty of approaches we could take ... we just haven't settled on one that is the obvious winner.

I cornered Jan Kotas in the corridor the other day and tried to push him to commit to getting us Save, he urged us to seek other solutions ...

So ... we need an alternate solution, regardless until .Net Standard 2.0 we can't do much with type providers given that Type has a private constructor on the coreclr, at least in the reference assemblies it is, the implementation still has a protected constructor. So I suppose we could do type reference magic to get something working.

[dbettin]

and from @cartermp

Erasing Type Providers (which are more common) should not require System.Reflection.Emit, but Generative Type Providers will. We'll first need to ensure that with the .NET Standard 2.0 APIs coming along, that we can at least support Erasing Type Providers. If that's the case, then many of the type providers in the wild could conceivably be used, assuming there are no other issues we run into.

For Quotations, it's a somewhat similar story. They don't require System.Reflection.Emit, but they are needed for fully-fledged quotation evaluators/compilers, and are needed if they are used as input to a Generative Type Provider.

What I think may be likely is that we'll have support for the "95% case" in these areas, but we could still be blocking key libraries and library authors if they are building full-on quotation compilers and Generative Type Providers.

All of the above is assuming that we don't do any work in those areas ourselves. @KevinRansom can speak more towards the feasibility of that, but given the amount of work we're doing right now, I don't find it likely that rewrites of those areas of TPs and Quotations will come from someone in Redmond between now and .NET Standard/.NET Core 2.0.

[sergey-tihon]

Do we know why Save() from System.Reflection.Emit is not part of .NET Standard 2.0? Explanation page or some discussion that may be linked? // cc @terrajobst

What alternatives we have if Save() will not be part of .NET Standard 2.0?

I think that I have a TP that should be generative - SwaggerProvider.
In we could keep this TP generative and port it to .NET Standard 2.0, it will allow mobile developers to consume generated types in C# / Xamarin.Forms projects. If generative TP is not supported, I will have to convert this TP to erasing and discontinue C# support. 😢

[matthid]

The issue is tracked here
https://github.com/dotnet/corefx/issues/4491
and there is a linked issue created by Kevin explaining in-depth what this means for F#...

[sergey-tihon]

Ok, found issue created by Kevin - https://github.com/dotnet/coreclr/issues/1709

[7sharp9]

Duplicating my comments from the other issue this is linked from:

One of the big things is that generative type providers service the wider ecosystem not just F#, they are the most important aspect in that respect.

Unchecked quotations for generative providers is also something that sorely needed to avoid having to reflectively call quotation builders to build the type provider.

[zpodlovics]

How about the successor(?) of IKVM.Reflection.Emit from Jeroen Frijters as his name already mentioned in the System.Reflection.Emit.AssemblyBuilder.Save corefx issue [1]? A preview release are available from NuGet.

"Managed.Reflection is a fully managed replacement of System.Reflection and System.Reflection.Emit. Unlike System.Reflection, it is not tied to the runtime it is running on.

It targets .NET Standard 1.3, which means it runs on .NET Core 1.0 and .NET Framework 4.6 and up."

Repository:
https://github.com/jfrijters/Managed.Reflection

[1] https://github.com/dotnet/corefx/issues/4491#issuecomment-189756092

[matthid]

@zpodlovics considering the comments I think (after discussing with the maintainers of course) such a PR making it work would be welcome... Its just nothing they have time for right now

[7sharp9]

Ive partially patched reflection stuff with IKVM.Reflection when I was working on an iOS feature for xamarin so it could be worth investigating.

[7sharp9]

@dsyme / etc Would a PR that used a dotnetcore version of ilvm reflection be accepted here?