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

[alfonsogarciacaro]

From fsprojects/FSharp.TypeProviders.SDK#80 (comment)

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.