Add support for reference assemblies to ProjInfo

[baronfel]

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]

need to grab the property in the first place

[baronfel]

once we have the potential property, we can flow it through

[baronfel]

and we can make it easier for callers to get the correct field.

[baronfel]

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]

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]

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]

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.