paket dependency manager doesn't work out of the box in VS, but it does if compiles with VS

[smoothdeveloper]

When I pull the release of FSharp.DependencyManager.Paket.dll from https://github.com/fsprojects/Paket/releases and drop it next to the location it is required under dotnet fsi (under the dotnet sdk folder, next to the nuget extension), it just works.

However, when I attempt to do so, in order for VS to pick it up, dropping under the commonextensions/microsoft/fsharp folder, VS doesn't pick it up.

Repro steps

• download FSharp.DependencyManager.Paket.dll from https://github.com/fsprojects/Paket/releases
• (§) drop it in your VS installation (C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\FSharp for example)
• open a script with #r "paket: nuget Foo" in it

Expected behavior

Typechecks or complains about the file being locked by the OS, and guide the user to fix it.

Actual behavior

Complains about the extension "paket" not being present.

Actual manual fix

check that the extension assembly file is not blocked by the OS (due to being downloaded from browser or other reasons).

Initial workaround

• https://github.com/fsprojects/Paket/
• open https://github.com/fsprojects/Paket/blob/master/src/FSharp.DependencyManager.Paket/FSharp.DependencyManager.Paket.fsproj in VS
• compile to your taste
• !!!!???? (§) (deploy in VS following the above steps, which are a bit voodoo for end users until we do something around DependencyProvider: Add a stable path which is tooling independent  #8880)
• profit

FSharp.DependencyManager.Paket.release.zip

Related information

It always behaved this way, it is not something which broke due to a change, but it should be fixed if possible.

I suspect it impacts any other extensions than the one which Microsoft ships, I don't know why it works out of the box in the dotnet sdk but not in VS.

[KevinRansom]

This is supposed to work. Assuming that the packet package manager is implemented correctly. Which I am sure it is.

[KevinRansom]

I will take a look when I get a chance.

[smoothdeveloper]

Thanks @KevinRansom and hit me up if anything.

It would be good to have @KathleenDollard & all think about end user experience (I know the prospect of extensions as powerful as type providers, being like a pandora box, is not the best for restful nights) and some technicals, like some old ideas in #8880.

I was thinking having a "open folder to fsharp VS extension" under the F# Interactive settings, with "use at your own risk" (as it requires admin rights for writing in the folder) and note about putting the same extensions under the dotnet sdk.

Most VS users will need to drop the extensions manually in two folders, or more, so in long run, it makes it tedious for developers and end users (those that write scripts) to manage the extensions from their IDE, and I'd like to asses what Microsoft wants to happen on that end.

Thanks all.

[dsyme]

We should have a design document (e.g. tooling RFC) that specifies how the DependencyManager things work. It's hard to tell what the intended design is.

[smoothdeveloper]

@dsyme, it does work the same as the Nuget extension (the .dll of an extension should be next to it), this is the spec for now, and --compilertool: is used if you need to store the extension in adhoc location.

Microsoft shipped "#r "nuget:"" but not what was underlying getting it, or the spec of the RFC, yet, it is clear, extensions work like the one that ships and is supported by Microsoft.

I have clarified the RFC: fsharp/fslang-design#659

I am eager the whole thing evolve, to something as great as installing vscode extensions in major IDEs, and ideally, that there is a stable location, and documented behaviour about how the loading of extension takes place, but it will be hard for me to nudge it, and I am preoccupied about my own ability to use the extensions and to engage with community to write more of them.

If this issue is not fixed, no one has much incentive to work on extensions (in F# community, it can take place without need of official documentation being perfect, it works for the compiler for example) IMO.

If there are no extensions (beside paket, justifying it is technically true, it is extensible), I doubt Microsoft is going to pour effort in the user experience to install extensions.