Update DependencyManager.FsProj to work with .NET SDK 7

[ThisFunctionalTom]

Yesterday, in the Amplifying F# session about DependencyManager.FsProj we tried to solve a problem which occurs with Ionide.ProjInfo when used in a fsi script which is probably the same thing that happens when DependencyManager.FsProj is using it in ResolveDependencies call.

We found one problem in initializing the ToolsPath for the WorkspaceLoader and succeeded loading projects in a console app.

As I tried to fix this also in DependencyManager.FsProj I failed and the same function called in console app does not work in context of an fsi.

Here is a repro of the problem:

1. Clone the DependencyManager.FsProj fork
2. dotnet fsi .\playground.fsx (This is not working)
3. change to TestIonideProjInfo directory
4. dotnet run ..\test-projects\SimpleLib\SimpleLib.fsproj (Everything works fine)

So the same function is executed once with dotnet run and once with dotnet fsi and the one in fsi fails.

The error in the notifications is following:

Loading
  "C:\Users\leko.tomas\private-source\DependencyManager.FsProj\test-projects\SimpleLib\SimpleLib.fsproj"
Failed
  ("C:\Users\leko.tomas\private-source\DependencyManager.FsProj\test-projects\SimpleLib\SimpleLib.fsproj",
   GenericError
     ("C:\Users\leko.tomas\private-source\DependencyManager.FsProj\test-projects\SimpleLib\SimpleLib.fsproj",
      "Field not found: 'Microsoft.Build.Framework.ChangeWaves.Wave17_6'."))

I am not sure if this could be a problem but in case of fsi following Microsoft.Build.* dlls are loaded in the AppDomain:

Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\FSharp\Microsoft.Build.Utilities.Core.dll
Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\FSharp\Microsoft.Build.Framework.dll
Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\Microsoft.Build.dll

and in the case of dotnet run it is somewhat more

Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\Microsoft.Build.dll
Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\Microsoft.Build.Framework.dll
Microsoft.Build.NuGetSdkResolver, Version=6.6.0.66, Culture=neutral, PublicKeyToken=31bf3856ad364e35
C:\Program Files\dotnet\sdk\7.0.304\Microsoft.Build.NuGetSdkResolver.dll
Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\Microsoft.Build.Utilities.Core.dll
Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
C:\Program Files\dotnet\sdk\7.0.304\Microsoft.Build.Tasks.Core.dll

I guess I could make a workaround and call Process.Start with TestIonideProjInfo but I am not sure if this is the best solution or if we could do something so that it works in-process.

@baronfel, @TheAngryByrd Maybe you have some insights into this? Do you have an idea how to solve this problem?

[TheAngryByrd]

Yeah I think the issue comes down to those Microsoft.Build.* dlls already being loaded and since FSI doesn't seem to "reload" DLLs we're stuck on an older version. I don't think I know of any work arounds with this (cc @vzarytovskii).

I think at this point it's probably worth going out-of-process. Buildalyzer can do this really well. The downside from what I remember is its performance is slower than Ionide.ProjInfo. Fable recently did this. You may have to use the same global properties and Targets from ProjInfo to do a Design Time build to the data you're looking for. Blog post on buildalyzer doing design time builds which explains a lot of what Ionide.ProjInfo or Buildalyzer does for you.