Project-system: 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

• [x] Respect <DisableFastUpToDateCheck> property to disable the build
• [x] Always write to output window why we ended up calling MSBuild (under which verbosity?)
• [x] Respect <ExcludedFromBuild> on items
• [x] 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.
• [x] Respect IItemType.UpToDateCheckInput on other items (basically all known items) - see IProjectItemSchemaService
• [x] 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.
• [x] Send telemetry to track why we ended up calling MSBuild
• [x] Handle situations, such as WinMDs, where the binary copied to the output directory is the same binary as csc produced.
• [x] Handle situations, such as <UseCommonOutputDirectory> where dependencies aren't copied to the output directory.
• [x] Handle <CopyToOutputDirectory> items especially when set to <Always> where the legacy project system always shells out to MSBuild.
• [x] Rationalize <FileWrites> vs <UpToDateCheckOutput> (should we respect the former to avoid having update all of msbuild to tell us about all the outputs?)
• [x] 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?
• [x] 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).

[davkean]

Factor in this case as well: https://connect.microsoft.com/VisualStudio/feedback/details/1955615/visual-studio-incorrectly-assumes-the-value-of-the-targetframeworkmonikerassemblyattributespath-property-defined-in-c-windows-microsoft-net-framework64-v4-0-30319-microsoft-common-targets-for-example

[davkean]

Look at ItemType.UpToDateCheckInput it seems we've already got data in the items schema that should be able to tell us if the item type is included in the up-to-date check,.

[davkean]

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

[dmitriyse]

For Visual Studio build:
You can greatly speedup build by hacking up file "C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0BinMicrosoft.Common.CurrentVersion.targets"

<!-- Modify this -->
      <CreateSymbolicLinksForCopyLocalIfPossible Condition="'$(BuildingInsideVisualStudio)' == 'true' or '$(CreateSymbolicLinksForCopyLocalIfPossible)' == ''">false</CreateSymbolicLinksForCopyLocalIfPossible>
<!-- To this -->
      <CreateSymbolicLinksForCopyLocalIfPossible Condition="'$(BuildingInsideVisualStudio)' == 'true' or '$(CreateSymbolicLinksForCopyLocalIfPossible)' == ''">true</CreateSymbolicLinksForCopyLocalIfPossible>

---

For command line build you can use:

msbuild ...    /p:CreateSymbolicLinksForAdditionalFilesIfPossible=true /p:CreateSymbolicLinksForCopyAdditionalFilesIfPossible=true /p:CreateSymbolicLinksForCopyFilesToOutputDirectoryIfPossible=true /p:CreateSymbolicLinksForCopyLocalIfPossible=true /p:CreateSymbolicLinksForPublishFilesIfPossible=true

I got near 200% speedup.

Unfortunately this hack do nothing for package restore.

[dmitriyse]

Is there any hack to disable auto package restore in VS 2017?
Maybe weird. Kill some dll or target.
It takes more than 3 minutes in our project. And raised by VS too often.

[srivatsn]

I don't think there's any way to disable auto restore. @alpaix would know.

[dmitriyse]

Msbuild team helped me.
To disable nuget auto restore in VS, both points should be unchecked:

But when those settings are applied, manual restoring from UI also will not work. (does not makes sense, because manual restore can be performed from the command line for example in the Package Management Console)

[alpaix]

Auto-restore configuration improvement is tracked in NuGet/Home#3963.

[alpaix]

@dmitriyse This is reasonable workaround. I'd wanted to clarify there's no restore PS cmdlet in PMC. Did you imply running nuget.exe from the console?

[gulbanana]

any thoughts on how the uptodate check is going to interact with GeneratePackageOnBuild? my preference would be for the nupkg to be treated like a dll, and rebuilt (or not-rebuilt) at the same times.

[dmitriyse]

Simplest way is to run dotnet restore
But I use slightly faster and strict way. With those files:
restore.proj (located at the solution root)j:

<Project>
    <ItemGroup>
        <Solution Include="*.sln" />
    </ItemGroup>

    <Target Name="Build">
        <MSBuild Projects="@(Solution)" Targets="Restore" ContinueOnError="ErrorAndStop" UnloadProjectsOnCompletion="true" />
    </Target>
</Project>

and restore.ps1

if ($DTE) {
    $configuration = $DTE.Solution.Projects.Item(1).ConfigurationManager.ActiveConfiguration.ConfigurationName
}
else {
    $configuration = "Debug"
}

msbuild restore.proj /p:Configuration=$configuration

Also to resolve appropriate msbuild you need one-time execute:
buildenv.ps:

if ($DTE -eq $null){
    throw "This command should be executed only inside visual studio"
}

$vsDevCmd = [System.IO.Path]::GetFullPath([System.IO.Path]::Combine($DTE.FullName, "../../tools/VsDevCmd.bat"))
CMD /c "`"$vsDevCmd`" && set" | .{process{
    if ($_ -match '^([^=]+)=(.*)') {
        Set-Item -path "env:$($matches[1])" -value $matches[2]
    }
}}

This way is 30% faster than dotnet restore

[gulbanana]

could we keep this about the design of up-to-date as an actual feature rather than various perf workarounds for not having it?

[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.

[gulbanana]

nice. pack-on-build is cool, but it about doubles the time for an otherwise-incremental build, so it would be considerably more useful in an up-to-date-checking future

[jcouv]

When you get to this, please make sure that the fast up-to-date check works with deterministic projects with ref assemblies.
We will likely have fixed the legacy project system to work by that time (I'll talk to Jason and Tom Meschter about that today).

[davkean]

@jcouv We should try and use the public extension points UpToDateCheckOutput/UpToDateCheckInput for the ref assemblies if possible, that avoids both us and the legacy project system needing to understand this concept.

[danwalmsley]

can I ask, will this issue fix also for command line dotnet build or just for visual studio?

[srivatsn]

Dotnet buildmsbuild already has an uptodate check and should be no-oping quickly on a rebuild. If there are cases where that's not happening please report on https://github.com/dotnet/sdk. This issue is to avoid the need to even launch msbuild and go through it's up-to-date check since that's somewhat expensive as well.

[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 https://github.com/dotnet/project-system/issues/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.