search

dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.93k stars 786 forks source link

Dependency resolution for scripts in VS editor incorrectly affects execution behaviour of other "dotnet fsi" #12708

Open dsyme opened 2 years ago

dsyme commented 2 years ago
  1. Create a script containing this
#r "nuget: TorchSharp-cpu, 0.93.6"

open TorchSharp

torch.randn(10)

#r "nuget: TorchSharp-cpu, 0.93.5"

  1. Start Visual Studio 2022 and execute the first three lines of the script. A crash occurs. Version 0.93.5 of the native DLLs are being used in the dotnet fsi session even though we've never sent them across to that process as input text.

  2. Comment out the last line, reset the F# Interactive session and re-run the first three lines of the script. The crash still occurs. Version 0.93.5 of the native DLLs are still being used! So editing in the editor hasn't corrected or removed the editor state.

  3. Leave the last line commented out, restart Visual Studio and run the first three lines of the script. No crash. Version 0.93.6 of the native DLLs are now being used in the dotnet fsi session.

Here, in steps 1, 2 and 3, the fact that we even edit a file with the extra #r "nuget: TorchSharp-cpu, 0.93.5" at the end seems to create some state on disk (a temporary working directory, project file etc.) regarding the resolution for (native?) assemblies on disk. This state must also be being used by the dotnet fsi even though it's not even seen the full editor text!

Once we exit and restart VS at step 4., this state must have be cleaned up by the exit of VS (temporary working directories deleted). Now the editor analysis now never encounters the #r "nuget: TorchSharp-cpu, 0.93.5" and everything works and is consistent.

There is clearly some problem with native resolution using false information in some contexts, and resolutions from one (editing) session actually affecting resolution during execution.

dsyme commented 2 years ago

@KevinRansom We should review the code for caching/memoizing/keying the artifacts created for native and managed dependency resolution in interactive sessions.

KevinRansom commented 2 years ago

This is a super interesting issue. I will take a look.