Project System: Up-to-date check

[davkean]

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]

tag @KirillOsenkov

[davkean]

Please also factor in concerns raised here: https://connect.microsoft.com/VisualStudio/feedback/details/2468519/visual-studio-incremental-build-issue-fastuptodatecheck-doesnt-monitor-xml-documentation-files

[davkean]

From @KirillOsenkov on April 30, 2016 4:14

tag @ljcollins25

[davkean]

It looks like <UseCommonOutputDirectory>true</UseCommonOutputDirectory> also breaks csproj's update to-date-check:

1>Project 'Microsoft.VisualStudio.ProjectSystem.Managed' is not up to date. CopyLocal reference 'C:\Roslyn With Spaces\Binaries\Debug\Microsoft.Build.dll' is missing from output location.

[srivatsn]

This tracks the feature to do an up-to-date check. Not fixed by #351.

[davkean]

csproj also respects <UpToDateCheckInput> and <UpToDateCheckOutput>, we should also respect these.

[davkean]

Also respects DisableFastUpToDateCheck.

[davkean]

I think we should create two new items to drive this that:

1. Respect the existing C#/VB properties for backwards compat
2. Actually use to drive the real inputs and outputs - that way they can be changed/removed without needing to change the project system (think a VSIX project that doesn't produce an assembly/pdb).

[atanasa]

Is there some way to enable Visual Studio to log why the project is not up to date? I have configured the verbosity of MSBuild but I guess this is a separate configuration.

[panopticoncentral]

There are still some issues remaining.

[panopticoncentral]

@davkean It looks like ExcludedFromBuild is only used in C++ projects, as far as I can tell. Are you aware of scenarios where it's used for VB/C#/F#?

[panopticoncentral]

@davkean Similarly, UpToDateCheckInput and UpToDateCheckOutput seem to be C++ specific as well?

[davkean]

Not sure about ExcludedFromBuild. Why do you say that UpToDateCheckInput/UpToDateCheckOutput is C++ specific? We read it in legacy project in CLangUpToDateCheck::AreInputsUpToDate.

[panopticoncentral]

Ah, yeah, missed that last one behind the #define name...

[panopticoncentral]

All outstanding issues logged to new issues.

[ebonato]

Hi @davkean. We are waiting to get PR #2346 on our hands, to fix a build error... as https://developercommunity.visualstudio.com/content/problem/46717/disablefastuptodatecheck-in-project-file-no-longer.html isn't referenced on any preview release notes, can we get this PR on a new preview 3 realease?

[srivatsn]

@ebonato - this issue and the PR you mention are tracking up-to-date check for the new project system (i.e for .NET Core.NET Standard projects in VS 2017). The developercommunity issue talks of a regression in the old project system (regression from vs2015 - the new project system is only in vs2017). That bug is on @panopticoncentral as well but hasn't been investigated yet.

[ebonato]

@srivatsn, look again in community issue from Mr. DoubleYou... The bug is reported for VS 2017 (15.1)... It only states that DisableFastUpToDateCheck csproj property works expected in VS2015.
This is why @davkean says on Nov/28/2016 that team should respect DisableFastUpToDateCheck.
And I cannot agree with @panopticoncentral on PR #2346 about this fix been a performance issue only... lot of people uses code generators in pre-build/before build events.
At least, this is a bug which impacts only developers using VS... build servers doesn't relies DisableFastUpToDateCheck as it delegates all up-to-date checks to msbuild.

[srivatsn]

Sorry, I'm not following you. Here's the current status:

• In the new project system, the DisableFastUpToDateCheck property is now respected and next previews of 15.3 will have the feature (the preview that was released yesterday 15.3 Preview 2 has the feature but it's off by default and needs to be enabled from Tools->Options) In the next preview of 15.3 it will be on by default.
• In the old project system, nothing should have changed since VS2015 I think. I've Mr.DobuleYou about the project type they were using. If it is a project that worked in VS2015 then there could be a regression in the old project system too that needs to be investigated.

[Jamaxack]

@srivatsn, @davkean I'm using VS 15.5.5 by default "Don't call MSBuild if a project appears to be up to date" is true, but still my NetStandard2.0 projects are rebuilding on running unit test, even after rebuilding all projects in solution. Here is the output:
1>FastUpToDate: Project information is older than current project version, skipping check. (X)
1>------ Build started: Project: X, Configuration: Debug Any CPU ------
2>FastUpToDate: Project information is older than current project version, skipping check. (Y)
2>------ Build started: Project: Y, Configuration: Debug Any CPU ------
3>FastUpToDate: Project information is older than current project version, skipping check. (Z)
3>------ Build started: Project: Z, Configuration: Debug Any CPU ------
========== Build: 3 succeeded, 0 failed, 20 up-to-date, 0 skipped ==========

Any ways to make sure that after rebuilding and running test will not build core projects again?

Thanks,

[Pilchie]

Also tagging @panopticoncentral who as been looking at Fast up to date check stuff. Also - is this a dupe of #2763?

[Jamaxack]

@Pilchie You are right. It seems like this issue and #2763 is the same, so #2763 issue is closed and this(62) bug is also marked as completed so what is the next steps? should I make small project and provide to here or it is already known issue and you can reproduce it yourself?

Thanks,

[Pilchie]

#2763 is NOT marked as closed.