Add FSharp.DependencyManager.Nuget to FCS

[KevinRansom]

We haven't had a good story for how tools that depend on FCS acquire the nuget package management library.

This PR adds it into the FCS nuget package. Developers who deploy fcs should ensure they deploy both dll's if they need package management.

[smoothdeveloper]

@KevinRansom about deployment story, and since the problem applies to all extensions:

Can we get the team to mull over
#8880

Right now, if user wants to deploy an extension system wide, there is no clear approach.

[KevinRansom]

@smoothdeveloper , of course.

I'm struggling with how to go fetch the dll if it's not alongside fsharp.compiler.private/service.dll. Shoving it in a separate nuget package is fine, but it still has to be deployed alongside fsharp.compiler.service. I suppose we could figure out how to probe the dotnet tool location at runtime, then it would be a case of developers creating their package manager as a dotnet tool and installing that. I doubt if we would do that for FSharp.DependencyManager.Nuget since we don't really want scripts that do #r "nuget: to fail" So even if we solved other tools, we would want FSharp.DependencyManager.Nuget to be always available.

[smoothdeveloper]

I'm struggling with how to go fetch the dll if it's not alongside fsharp.compiler.private/service.dll

@KevinRansom IIRC the assembly has to be next to the binary of the process (the .exe), not necessarily where FCS assembly is located.

we don't really want scripts that do #r "nuget: to fail"

Agreed, the nuget extensions should ship along fsi.exe, similarly we don't want FCS to fail out of box with the same and there is no provision for that yet.

Maybe adding an explicit load of the nuget extension assembly if it can be found next to FCS assembly would be a solution for that.

[KevinRansom]

@smoothdeveloper

Maybe adding an explicit load of the nuget extension assembly if it can be found next to FCS assembly would be a solution for that.

We load any assembly named DependencyManager with the appropriate attribute that is found alongside fcs.dll or fcp.dll so that scenario is fine. The issue is how to get the dll there.

If we ship it in a nuget package then when executed on the coreclr it will stay in the nuget cache and not be copied to the deployment directory. the coreclr relies on the deps.json to probe for dependencies. But we are doing a reflection load

So an fcs developer is going to have to do some work to ensure that the durned dll is deployed alongside fcs.dll. The approach in this pr is the most convenient, because the build tooling will always drag it along. A developer actually would have to do work to make it not work.

However, there is still the situation for external package managers that are not deployed with tools. We have singularly failed to make that easily usable. I suppose that dotnet global tools might be an approach for that, but I haven't really given it a large amount of thought at this time.

[baronfel]

Fleshing out a thought here: another way to support third-party #r handlers would be to 'just' (I hate that word) invoke fsi/fcs with the --compilertool flag, correct?

From an ionide perspective, if a user sets some additionalFsiArguments in the vscode config pointing to the directory of a nuget package containing a dependency manager (something like "fsiAdditionalArguments": [ "--compilertool", "/Users/chethusk/.nuget/fsharp.dependencymanager.paket/1.2.3/lib" ]) then we'd add those to both:

• the project options used to typecheck in the editor, and
• any dotnet fsi instances spawned from within VS code.

This is an example of external orchestration. It might also be possible to have some sort of persistent user configuration for fsi, perhaps an environment variable, perhaps a config file in the user's home directory, that could also contain these flags. Then FCS/FSI could learn to check for and read that file while generating the project options for a script. This would centralize the logic at the cost of requiring back-compat considerations when evolving the mechanism.

[KevinRansom]

Yes that is why it was originally put in, although it is a bit clunky for someone to type when executing scripts. When the tooling supports it, that is an acceptable approach I think. However, I would hate for that to be necessary for the basic nuget package manager.