DotNetFrameworkDependencies throws ArgumentNullException in static constructor

[albahari]

The static constructor of DotNetFrameworkDependencies throws an ArgumentNullException when FSharp.Compiler.Service doesn't have a disk presence. This occurs when FSharp.Compiler.Service.dll is loaded directly into memory with Assembly.Load(byte[]); for instance, as is the case if you're using Microsoft's new single-file executable deployment feature in .NET Core.

The problem is in this line of code:

let fSharpCompilerLocation =
        let location = Path.GetDirectoryName(typeof<TypeInThisAssembly>.Assembly.Location)

This evaluates to null when FSharp.Compiler.Service.dll doesn't have a disk presence, which then
causes an ArgumentNullException to be thrown when later calling Path.Combine:

let getDefaultFSharpCoreLocation = Path.Combine(fSharpCompilerLocation, getFSharpCoreLibraryName + ".dll")

The call to Path.Combine fails when fSharpCompilerLocation is null.

Note that this problem has just appeared in version 34 of FSharp.Compiler.Service. It did not occur in version 33.

[cartermp]

@KevinRansom @jonsequitur looks like we have a regression

[albahari]

Note that LINQPad's F# support is locked at version 33 until this bug is fixed :)

[KevinRansom]

Hmmm .... I'm actually not sure what to do about this. We use the heuristic, alongside the FSharp.Compiler dll to load assemblies quite frequently in the compiler. We use it specifically as the fall back to load FSharp.Core.dll, as well as loading the package manager in .fsi. I guess we will need a more complete heuristic ....

[ZhouJie-BBM]

I'm also waiting this bug to be fixed
link to: https://forum.linqpad.net/discussion/2289/linqpad-support-for-f-5

[seankearon]

Angetha and Anna-Frid are saying: gimme, gimme, gimme LinqPad after F#5. Won't somebody help me chase this bug away?

[sblom]

Also here because I'm missing F#5 support in LINQPad. LINQPad is how I gain fluency in new language features before I try "speaking them in production", and I'm not currently, well, fluent.

[dsyme]

This occurs when FSharp.Compiler.Service.dll is loaded directly into memory with Assembly.Load(byte[]); for instance, as is the case if you're using Microsoft's new single-file executable deployment feature in .NET Core.

@albahari Where would we expect FSharp.Core.dll to be resolved from in this case? Are you also expecting an in-memory load of that assembly, or will you have the nuget pckage available, or will you be providing the -r:...FSharp.Core.dll arguments explicitly, or will you be relying on .NET SDK resolution (which uses a nuget package)?

[albahari]

In version 33, it resolved using typeof<Microsoft.FSharp.Core.Unit>.Assembly.Location. This worked OK because FSharp.Core.dll must have a disk presence so that you can compile against it - I wouldn't expect this to be able to load in memory. The actual location of FSharp.Core.dll is then determined by the ALC.

[dsyme]

So I guess the request is to never use

let fSharpCompilerLocation =
        let location = Path.GetDirectoryName(typeof<TypeInThisAssembly>.Assembly.Location)

but rather use typeof<Microsoft.FSharp.Core.Unit>.Assembly.Location as the backup for FSHarp.COre.

Hmmmm I don't see anythying wrong with this. I'll look to see if we can make the change