search

ionide / proj-info

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

Add support for reference assemblies to ProjInfo #200

Closed baronfel closed 7 months ago

baronfel commented 7 months ago

Adds support for reading and deferring to TargetRefPath when it exists. This property points to the reference assembly that matches the implementation assembly that exists in TargetPath. There's a new member to help navigate the proper usage. When ref assemblies are present, the FSharpReferencedProject items returned as part of a generated FSharpProjectOptions object will use the ref assembly as the source of truth, not the implementation assembly.

baronfel commented 7 months ago

One question I had @TheAngryByrd - does the Adaptive LSP server use this library? or does it have a parallel mechanism? if so, I can replicate this in the FSAC codebase if you can point me in the right direction.

safesparrow commented 7 months ago

Thanks for looking into this @baronfel .

I wonder if we there is an existing MSBuild target that could be reused here to perform the standard logic - after all, MSBuild has to do the same logic to come up with compiler args.

Unless TargetPath/TargetRefPath is as high level as we can get.

TheAngryByrd commented 7 months ago

One question I had @TheAngryByrd - does the Adaptive LSP server use this library? or does it have a parallel mechanism? if so, I can replicate this in the FSAC codebase if you can point me in the right direction.

Yeah it uses ProjInfo, ProjInfo.FCS, and ProjInfo.Sln. So this should flow through. I did turn off RefAssembly stuff that we'll probably need to turn on.

It doesn't use ProjectSystem because it needed to use Adaptive's Filewatcher mechanisms.

baronfel commented 7 months ago

Thanks for looking into this @baronfel .

I wonder if we there is an existing MSBuild target that could be reused here to perform the standard logic - after all, MSBuild has to do the same logic to come up with compiler args.

Unless TargetPath/TargetRefPath is as high level as we can get.

Technically we could call the GetTargetPath target and read the Return items from that target, but as you can see from this image a reference assembly doesn't change the TargetPath, it just adds a metadata with the ReferenceAssembly if there is one. This is functionally equivalent to what we're doing here, so I think it's ok for us to stick with what I've got.

image