Intellisense Gets Broken in vscode if we have some derived properties from TFM

[Anipik]

In case of multple TargetFrameworks, omnisharp chooses the first target framework and do a reevaluation.

Before Re-evaluation, omnisharp uses setproperty function to set the TargetFramework property.

omnisharp-roslyn/src/OmniSharp.MSBuild/ProjectLoader.cs

Line 151 in b442e6b

evaluatedProject.SetProperty(PropertyNames.TargetFramework, targetFramework);

So this updates a property if it exists, otherwise it searches for the first unconditioned PropertyGroup in the project file to add the property to. This is always going to be after any implicit imports as well as explicitly leading imports. This appears to be the long-standing behavior of SetProperty. Contrast that to SetGlobalProperty, which will treat the property as global.

Hence any property derived from targetFramework in implicit imports and leading imports will not be evaluated correctly.

There is a detail repro here dotnet/runtime#33427 (comment)

[ericstj]

This makes design-time build inconsistent with the actual build, which sets TargetFramework as a global property. The result is that Omnisharp's design time build is broken when actual build works fine. Omnisharp should use SetGlobalProperty instead to avoid this problem. /cc @DustinCampbell

[filipw]

@ericstj thanks a lot. are there any side effects of this change that you are aware of?

[ericstj]

Not that I am aware of. Global properties have two different behaviors than the current code. 1: they apply to the entire project evaluation (the fix we want) 2: the flow to any child invocations of MSBuild from the project. 2 could potentially change things but given MSBuild already behaves this way on the command line I don’t expect it to be an issue. To test you can make sure to try a case where a project references another project and that project has different but compatible TargetFrameworks. Cc @rainersigwald

[filipw]

thanks!