Skip to content

FSI assembly resolution logic doesn't work for self-contained FCS scenarios. #7701

@baronfel

Description

@baronfel

The logic in DotNetFrameworkDependencies is written assuming that the getFSharpCompilerLocation is inside the dotnet SDK root directory tree. This is fine for the compiler, but for FCS deployed as a component in some other application (ie. FSAC):

  • the path reported by getFSharpCompilerLocation is not inside this tree
  • which makes the overall logic for probing the getFrameworkRefsPackDirectoryPath no longer valid
  • resulting in the ref assemblies from the pack directory not being used.

Instead, the full assemblies from the shared directory are used. As a side effect of the getImplementationReferences() code path being used, it becomes necessary to insert a manual reference to mscorlib.dll, without which no fsx script will typecheck. This wouldn't be necessary if the packs codepath was used, because that codepath yields every DLL in the packs folder.

Repro steps

  1. In a project targeting/running on netcoreapp3.0,
  2. call backgroundCompiler.GetProjectOptionsFromScript() with a valid file, setting useSdkRefs to true and assumeDotNetFramework to false.
  3. get the references in the OtherOptions by filtering all options that start with -r:.

Expected behavior

The refs are supplied from the pack references, in my case /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/ref/netcoreapp3.0

Actual behavior

The refs are supplied from the full references, in my case /usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/

Known workarounds

Reimplement reference location :(

Related information

In addition, these APIs are very hard to use in a cross-TFM manner. They are tightly bound to the execution TFM of the currently-running process so you can't for example ask for the references set of a .netcoreapp3.0 script while running FCS in a .netcoreapp2.1 application. This problem doesn't exist when asking for net4x references because those are an immutable set and are just magically resolved by the system by name.

Provide any related information (optional):

  • Operating system: Max OSX Mojave
  • .NET Runtime kind: .Net core 3.0
  • Editing Tools: FSAC work-in-progress branches

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions