Project System: Up-to-date check

CPS does not provide a project system up-to-date check out of the box - to get a similar experience to csproj/msvbproj where they only call MSBuild after they’ve determined that they are out of date, we should implement one.

Design

To do a fast up-to-date check, we should implement IBuildUpToDateCheckProvider, a configured level service, that is called back to determine if build should call into MSBuild.

Requirements

• Respect <DisableFastUpToDateCheck> property to disable the build
• Always write to output window why we ended up calling MSBuild (under which verbosity?)
• Respect <ExcludedFromBuild> on items
• We should drive almost all inputs/output for the up-to-date check via the items above, such as (but not limited to) XML doc files, pdb, exe.config, deps.json, runtimeconfig.json, etc) to avoid hardcoding these in the project system. We should make changes in the SDK/MSBuild to add these.
• Respect IItemType.UpToDateCheckInput on other items (basically all known items) - see IProjectItemSchemaService
• Respect <UpToDateCheckOutput Include=""/> and <UpToDateCheckInput Include=""/> to supplement the build. We’ll need to create ProjectItemDefinitions for these (so that we see them in data flow) and set UpToDateCheckInput for the later.
• Send telemetry to track why we ended up calling MSBuild
• Handle situations, such as WinMDs, where the binary copied to the output directory is the same binary as csc produced.
• Handle situations, such as <UseCommonOutputDirectory> where dependencies aren’t copied to the output directory.
• Handle <CopyToOutputDirectory> items especially when set to <Always> where the legacy project system always shells out to MSBuild.
• Rationalize <FileWrites> vs <UpToDateCheckOutput> (should we respect the former to avoid having update all of msbuild to tell us about all the outputs?)
• Rationalize whether we need to be run before or after draining critical tasks (BeforeDrainCriticalTasks metadata) - what if we haven’t restored yet and NuGet brings down a bunch of packages, should we build or not?
• Work with NuGet folks to make sure GeneratePackageOnBuild sets the right inputs and outputs above to play nicely with up-to-date.

Things to watch out for

• While IBuildUpToDateCheckProvider is at each configured project level - in multi-targeting projects we only ever build the VS “active” config. We end up building all TFMs by clearing out the TargetFramework property. This is really important, and it means we need to factor in all other active configurations as to the determination of whether we need to shell out to MSBuild.
• See VCBuildUpToDateCheck for an example of a functioning up-to-date check,

[davkean]

@gulbanana We’ll factor in the packaging case, I’ve added a point above. We’ll be looking at implementing this in the next couple of weeks.

[davkean]

@srivatsn I’ve wrote a little requirements spec on the approach we should take.