Fsharp: Type providers not working in netcore because of (now private) Reflection Type constructors

[alfonsogarciacaro]

From https://github.com/fsprojects/FSharp.TypeProviders.StarterPack/issues/80#issuecomment-241479154

I tried to compile an erasure Type Provider with the Type Provider Starter Pack (not sure if there's another way) for .NET Core. Most of the now missing Reflection methods can be polyfilled with the System.Reflection.TypeExtensions package but the showstopper is the helper types in ProvidedTypes.fs (like ProvidedSymbolType) inherit from classes like System.Type which don't have a public constructor in NETStandard.

I don't know if this is the only thing preventing TPs from working with .NET Core but, would there be any hack to overcome this obstacle for the time being?

[dsyme]

@KevinRansom @cartermp @OmarTawfik What's the status here? Do we have a working example of an (erasing) type provider on .NET Core? Thanks

[cartermp]

I don't have one, no.

@terrajobst, is adding back a public constructor for System.Type something on the ticket for .NET Standard 2.0?

[terrajobst]

Yes, this API will be brought back as part of .NET Standard 2.0. /cc @weshaggard

[KevinRansom]

@KevinRansomhttps://github.com/KevinRansom @cartermphttps://github.com/cartermp @OmarTawfikhttps://github.com/OmarTawfik What's the status here? Do we have a working example of an (erasing) type provider on .NET Core? Thanks

No

[ReedCopsey]

@terrajobst and @weshaggard :

FYI - This is more than just the constructor on System.Type - it's the same issue on all of the reflection types (PropertyInfo, MethodInfo, MemberInfo, etc).

Really, most of everything required to implement IReflectableType is required to implement type providers. While IReflectableType and the Reflection types are visible in .NET Standard, they're all there with private constructors in current versions (as they were in the PCL versions of these APIs). It'd be nice if all of this could be exposed in .NET Standard (for type providers, but also other library support that relies on IReflectableType)

[terrajobst]

@ReedCopsey

Sorry, I should have been clearer. Yes, we will bring all the ctors on the *Info classes as we bring full reflection extensibility to .NET Standard 2.0 and, by extension, to .NET Core.

[dsyme]

OK .

We have two options:

• wait for .NET Standard 2.0
• re-architect the fundamental F# compiler API used by type providers to no longer use any F# quotations or any extensible reflection (inheriting from Type/MethodInfo/FieldInfo/... types). While this would be architecturally cleaner and more independent in many ways, it is also a big undertaking, and would require significant corresponding changes to the ProvidedTypes programming model for authoring type providers. This model uses extensible reflection in many places, e.g. here and here

It is too late for the latter work to make it into F# 4.1. So I assume we go for the former option.

@cartermp - if you agree, could you please update this blog post to add a note that neither generative nor erasing F# type providers will not by supported when using running the F# compiler with .NET Core 1.x (regardless of the kind of code generated). They will continue to be supported when running the compiler using Mono or .NET Framework.

Thanks
Don

[cartermp]

@dsyme I agree, I think it's best to wait for .NET Standard 2.0 for this. I'll update the blog post and add it to my list of things to talk about in a planned post for F# 4.1 and Visual F# Tooling RC.

[rmunn]

@cartermp - Has the blog post been updated yet? When I checked today, I couldn't find the words "type provider" (or even "provide", "provider", "provided", etc.) anywhere in the blog post.

[cartermp]

Updated now.

[lambdakris]

@dsyme @cartermp Will other F# meta-programming features like code quotations work in .NET Standard 1.x and .NET Core 1.x or will that have to wait until .NET Standard 2.0 as well?

[cartermp]

@lambdakris Quotations _shouldn't_ be an issue - they're defined within the netstandard1.6-based FSharp.Core library, and the reflection features it uses (to my knowledge) are all available on .NET Standard 1.6 and .NET Core 1.0.

If you run into an issue we'd love to know, though.

[dsyme]

@lambdakris As I understand code quotations will work. But we should review testing

[cloudRoutine]

Should avoid using netstandard 1.5 and 1.6 since they're being deprecated?
Or are the api changes small enough that it doesn't merit going back to netstandard 1.4 to avoid breaking changes with netstandard 2.0?

[nojaf]

Will this be fixed with dotnet core 2.0 now?

[cartermp]

@nojaf Currently Erasing TPs are on the roadmap, yes.

[cloudRoutine]

The NETStandard.Library 2.0.0 beta is available on myget along with these other reflection libs that aren't part of the standard lib -

• System.Reflection.Emit.Lightweight 4.4.0-*
• System.Reflection.Emit.ILGeneration 4.4.0-*
• System.Reflection.Emit 4.4.0-*
• System.Reflection.Metadata 1.5.0-*
• System.Reflection.TypeExtensions 4.4.0-beta-*
• System.Reflection.Context 4.4.0-*
  ( packages targeting netstandard 2.0 are generally >= 4.4.0 unlike the current 4.3 version on nuget)

So anyone interested in tackling this should be able to get started at this point.

[dsyme]

@cloudRoutine Thanks, that's very useful

I think these are the necessary first steps - is anyone able to take the first of these in the next few days?

• [ ] PR to produce a .NET Standard 2.0 library (beta)
• [ ] Test that it is possible to compile the ProvidedTypes API from the F# Type Provider Starter Pack against this library and produce a first proof-of-concept .NET Standard 2.0 erasing TP
• [ ] Smoke test that it is possible to reference this from the F# .NET Core compiler
• [ ] Smoke test that it is also possible to reference this from the F# .NET Framework compiler. (Questions of TP API binary compatibility may come into play here)

[cartermp]

Tagging this for VS 2017 Updates, since we're stating as such in the blog post

[7sharp9]

Is it a possibility that if IKVM reflection could be used for all the compilers refection emit capabilities that that PR would be accepted here?

[dsyme]

Is it a possibility that if IKVM reflection could be used for all the compilers refection emit capabilities that that PR would be accepted here?

I don't know. First, the use of SRE in generative type providers is entirely separate from the use of SRE in ilreflect.fs to implement FSI.EXE. Only the latter is in this repo, so I assume you'd be removing that. But that is working OK today on both .NET Core and .NET Framework, so there's no need to replace it?

If you want to replace the use of SRE in generative type providers, then the type provider starter pack is the place to do that. I think that would be generally welcome, though it would increase the dependency base of typical type providers, and I'm not sure if that would bring extra problems.

[dsyme]

Duplicate of #2406