Design-time builds in CPS are doing too much work because BuildingProject is set to true

[davkean]

To reduce build times, CPS groups build targets for a project together. This has the unintended side-effect of turning $(BuildingProject) on during lots of CPS design-time builds.

Lots of behavior in common targets is driven by $(BuildingProject), it's basically the legacy equivalent of $(DesignTimeBuild) != 'true'":

186>------ Build started: Project: Microsoft.VisualStudio.ProjectSystem.Managed, Targets: CollectResolvedSDKReferencesDesignTime, DebugSymbolsProjectOutputGroup, CollectPackageReferences, ResolveComReferencesDesignTime, ContentFilesProjectOutputGroup, DocumentationProjectOutputGroupDependencies, SGenFilesOutputGroup, ResolveProjectReferencesDesignTime, SourceFilesProjectOutputGroup, DebugSymbolsProjectOutputGroupDependencies, SatelliteDllsProjectOutputGroup, BuiltProjectOutputGroup, SGenFilesOutputGroupDependencies, ResolveAssemblyReferencesDesignTime, CollectAnalyzersDesignTime, CollectSDKReferencesDesignTime, DocumentationProjectOutputGroup, PriFilesOutputGroup, BuiltProjectOutputGroupDependencies, ResolvePackageDependenciesDesignTime, SatelliteDllsProjectOutputGroupDependencies, SDKRedistOutputGroup, CompileDesignTime, CollectResolvedCompilationReferencesDesignTime ------

...

186>Target "BuildOnlySettings" in file "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets":
186>  Set Property: BuildingProject=true

BuildOnlySettings is basically a dependency of most of the output groups targets.

Things that I'm seeing we're doing:

• ResolveAssemblyReferences; FindDependencies, FindSatellites, FindSerializationAssemblies, FindRelatedFiles is all true.
• ResolveAssemblyReferences; Silent is false - undecided if this is good or bad.

This would explain why ResolveAssemblyReferences is showing up on traces, FindDependencies is very slow.

[davkean]

This is also blocking XAML: dotnet/project-system#2488.

[rainersigwald]

The output groups have been like this for a looooooooong time. It went in with this commit:

Change 1159138 by ███████ on 2005/05/30 22:19:17

	   MSBuild RTM bugs
	
	   Fixes for the following bugs:
	   493328	"unable to copy file ... because it is being used by
	   another process" after building twice in a row, old resx format
	   494837	.RESTEXT files are not given the right manifest resource
	   name.
	   494963	Default value for metadata <InProject> should be "false"
	   when item is coming from a .TARGETS file.
	   494967	There's no way for the author of a custom build process
	   to add entries into the BuildAction dropdown in the IDE.
	   494968	Tasks that have ContinueOnError=true should not log
	   errors.
	   495734	Visual Studio holds/leaks reference to build target
	   DLLs, preventing builds.
	   495747	MSBUILD: Usage of "Target" metadata in AL.exe /link
	   option does not work
	   496301	We should kill the "AssignTargetPaths" target if
	   possible.
	   498702	ToolTask needs a way to allow the task author to parse
	   stdout/stderror themselves.
	   456966	Saving a vb code file to a different location causes
	   information to be lost over VB->C# project reference.

None of those bugs looks particularly related to me.

I'd be willing to try dropping the dependency and seeing what happens.

[nguerrera]

Something that came up in a meeting just now, talking to @davkean who was looking at this. It is in fact deliberate that output groups trigger finding of dependencies. Some of the items inside the groups rely on it. CPS needs to handle this somehow.

@davkean should this be moved to project-system given that?

[davidwengier]

I may be missing a lot of context here, so take this with a grain of salt, but design time builds of Roslyn.sln at least don't have BuildingProject set to true, presumably because they don't specify PriFilesOutputGroup as a target (which in turn depends on BuildOnlySettings).

[davkean]

@davidwengier Output groups are merged with design-time build if features request them, which happens a lot depending on what VS features you are using, such as XAML designer, Unit Tests, etc. ie This problem still exists.