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

[Anipik]

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

similar issue OmniSharp/omnisharp-roslyn#1738

[davkean]

This is an MSBuild issue, please open it against http://github.com/microsoft/msbuild. I'd move the issue but I can't across orgs.

[ViktorHofer]

@Anipik did you open an issue in msbuild as David suggested? Can't find one.

[Anipik]

no i missed his comment, i am just doing it right now.

[Anipik]

dotnet/msbuild#5319

[ericstj]

@davkean are you sure this is an MSBuild issue? I believe MSBuild is behaving correctly. The problem is that the project system ends up setting a local property rather than a global property:

project-system/src/Microsoft.VisualStudio.ProjectSystem.Managed.VS/ProjectSystem/VS/Properties/InterceptedProjectProperties/TargetFrameworkMonikerValueProvider.cs

Lines 41 to 59 in 600486b

	else if (!string.IsNullOrEmpty(currentTargetFramework))
	{
	var frameworkName = new FrameworkName(unevaluatedPropertyValue);
	await defaultProperties.SetPropertyValueAsync(ConfigurationGeneral.TargetFrameworkProperty, _frameworkParser.GetShortFrameworkName(frameworkName));
	}
	else
	{
	// CPS implements IVsHierarchy.SetProperty for the TFM property to call through the multi-targeting service and change the TFM.
	// This causes the project to be reloaded after changing the values.
	// Since the property providers are called under a write-lock, trying to reload the project on the same context fails saying it can't load the project
	// if a lock is held. We are not going to write to the file under this lock (we return null from this method) and so we fork execution here to schedule
	// a lambda on the UI thread and we don't pass the lock information from this context to the new one.
	_unconfiguredProjectVsServices.ThreadingService.RunAndForget(() =>
	{
	_unconfiguredProjectVsServices.VsHierarchy.SetProperty(HierarchyId.Root, (int)VsHierarchyPropID.TargetFrameworkMoniker, unevaluatedPropertyValue);
	return System.Threading.Tasks.Task.CompletedTask;
	}, options: ForkOptions.HideLocks | ForkOptions.StartOnMainThread,
	unconfiguredProject: _unconfiguredProjectVsServices.Project);
	}

This results in an inconsistency between what the SDK does in an actual build (global property) vs what the project system does in the design time build (local property).