search

ionide / proj-info

Parse and evaluate MsBuild project files
MIT License
64 stars 35 forks source link

When some projects target `net7.0`, and their dependencies dual-target `net6.0, net7.0`, cracking doesn't work #202

Open safesparrow opened 5 months ago

safesparrow commented 5 months ago

Describe the bug Given a two-project setup:

  1. A.fsproj targets net6.0, net7.0,
  2. B.fsproj targets net7.0 and references A.fsproj

ProjInfo defaults to net6.0 for A, and net7.0 for B. B's -r arg points to a net7.0 ref assembly, but FSharpOptions for A use net6.0, so there is no match and reference isn't loaded by FCS.

To Reproduce Steps to reproduce the behaviour:

  1. Checkout https://github.com/giraffe-fsharp/Giraffe
  2. Crack Giraffe.sln using the following code 
    
open System
open System.IO
open Ionide.ProjInfo

let slnPath = @"c:\projekty\fsharp\samples\Giraffe\Giraffe.sln" let slnDir = Path.GetDirectoryName(slnPath) let toolsPath = Init.init (DirectoryInfo(slnDir)) None let globalProps = [ "Configuration", "Debug" ] let workspaceLoader = WorkspaceLoaderViaProjectGraph.Create(toolsPath, globalProps) let projects = workspaceLoader.LoadSln(slnPath) let fcsProjects = FCS.mapManyOptions projects |> Seq.toArray


5. See in a debugger that the `ReferencedProjects` shows `A.fsproj` using `net6.0`:
![image](https://github.com/ionide/proj-info/assets/2478401/161642dd-ce33-4f81-947a-4a055a9747c2)
while `OtherOptions` section shows a reference to a `net7.0` ref dll.
![image](https://github.com/ionide/proj-info/assets/2478401/ac48d1c5-fc5d-4597-8fb3-613c95d5178b)

This causes a mismatch and results in not loading the referenced project.

**Expected behaviour**

Project options should be internally consistent and allow for project references to be recognised by FCS.

**Environment (please complete the following information):**
 - OS: Win11
 - Ionide version: `Ionide.ProjInfo.FCS` 0.63.0
 - dotnet SDK version: 8.0.101
baronfel commented 5 months ago

I'm pretty sure this is a consequence of our 'first TFM wins' approach to ordering here. The minimal workaround would be to swap the order of TFMs in A.fsproj, but of course that won't work as a general solution.

A proper treatment would likely have to include us redoing our handling of multi-targeted projects - they don't really have a sensible default for OutputPath and other related properties - instead those properties should only ever be valid at a single-TFM level.