System.NullReferenceException when user targets to .NET Standard 2.0 #177
Labels
Comments
|
The base is null: let baseObj = tcImports.GetProperty("Base") |
|
Just skipping the base object ...is not a working solution, the compiler will hang. |
|
This might be ok, if ProvidedTypesContext Create is actually expired and not called anymore, I wasn't using the latest SDK version. |
|
I tried to update to latest SDK but this still fails. Branch is here https://github.com/fsprojects/SQLProvider/tree/sdk-update
Now, the call to Create comes from constructor, which I tried to imitate from this projects examples\ComboProvider like this: [<TypeProvider>]
type SqlTypeProvider(config: TypeProviderConfig) as this =
inherit TypeProviderForNamespaces(config, [("FSharp.Data.Sql", "FSharp.Data.Sql")]) |
|
Fixed by #179 |
|
I'm not sure this is enough. |
|
Yes, not fixed. Any ideas how could I go further? I think -v maybe fail to some other place than without it. |
|
I was hoping VS 15.5 would fix things, but no luck. Actually dotnet.exe build -v failure is "as designed", I had missing argument d. But after that: |
|
I was thinking that the problem is this ( let handler = ResolveEventHandler(fun _ args -> this.ResolveAssembly(args))
do AppDomain.CurrentDomain.add_AssemblyResolve handler
//.... cut cut cut ...///
default __.ResolveAssembly(args) =
let expectedName = (AssemblyName(args.Name)).Name + ".dll"
let expectedLocationOpt =
probingFolders
|> Seq.map (fun f -> Path.Combine(f, expectedName))
|> Seq.tryFind File.Exists
match expectedLocationOpt with
| Some f -> Assembly.LoadFrom f
| None -> null...as clearly calling Assembly.LoadFrom inside ResolveEventHandler should lead to stack overflow exception as described here. However, it seems that F# compiler manages to call the constructor, and also manages to call |
|
Hey @Thorium, any update on the state of this issue? I believe this is the same problem I've ran into when trying to use SQL provider |
|
Yes, the latest version doesn't crash to a null-reference-exception but throws a stack-overflow-exception after a GetType-TryBindType-GetType-loop with "System.Object". I made a fix in PR #183 but I expect we still have a problem here: In Linux environment with Core App the TypeProvider library is compiled with Mono and used with .NET Core on runtime. But there is a difference that "System.Object" is referenced from mscorlib.dll in Mono and netstandard.dll in Core. After this PR what happens is that we get further in the compilation, but as the type-provider uses e.g. FSharp.Core, during the compilation it's loaded with reflection. Reflection tries to load all the dependency libraries, which are clear in .NET Framwork and .NET Core, but not with .NET Standard. In F# core there is e.g. alias bigint which is a dependency to Int64 loaded from which library: mscorlib.dll or netstandard.dll? Currently the build fails there. Ping @dsyme, any architecture description help, or ideas for a workaround? |
|
Added a PR that contains .NET Standard tests to demonstrate the problem. |
|
Gotcha, so this is a .net standard issue then. Thanks for the info! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a .NET Standard 2.0 erasing type provider is used in a library project that targets .NET Standard 2.0, the ProvidedTypes.fs type ProvidedTypesContext method Create throws an exception in line:
...and it's a System.NullReferenceException:
.NET CoreApp 2.0 target seems to work ok.
The text was updated successfully, but these errors were encountered: