Design Time Builds failing if we have some derived properties in Implicit or leading imports

[rainersigwald]

From @Anipik on Monday, April 27, 2020 8:50:43 PM

In case of multple TargetFrameworks, DesignTimeBuild uses msbuild setproperty function to set the TargetFramework property.

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)

cc @ericstj @ViktorHofer

similar issue OmniSharp/omnisharp-roslyn#1738

Copied from original issue: dotnet/msbuild#5319

[rainersigwald]

Please let us know if you need a new API from MSBuild to fix this, we can work together if so.

[ericstj]

@davkean please have a look. This is the same as #5996 which was moved to msbuild and now came back. I believe the bug here is that project system (or some service it uses) is calling SetProperty instead of SetGlobalProperty.

[davkean]

This is a core CPS bug and not this repo. I suspect looking at the code, they've done this because they have an existing project instance and can't change global properties. @lifengl?

[ViktorHofer]

ping @lifengl

[jjmew]

@ericstj You will need to file a bug in Azure Dev Ops under DevDiv\VS Core\Project as this is a CPS issue

[ericstj]

@Anipik can you please open the issue as @jjmew suggests?

[ViktorHofer]

Please 'cc me in the issue as I'm interested in a near-term solution.

[Anipik]

sure i will do that