Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project System: Up-to-date check #62

Closed
13 tasks done
davkean opened this issue May 13, 2016 · 41 comments · Fixed by #2304
Closed
13 tasks done

Project System: Up-to-date check #62

davkean opened this issue May 13, 2016 · 41 comments · Fixed by #2304
Labels
Parity-Legacy-Feature Missing features from the legacy project system. Resolution-Fixed The bug has been fixed, refer to the milestone to see in which release it was fixed.
Milestone

Comments

@davkean
Copy link
Member

davkean commented May 13, 2016

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 davkean added Area-Project System Parity-Legacy-Feature Missing features from the legacy project system. labels May 13, 2016
@davkean
Copy link
Member Author

davkean commented May 13, 2016

tag @KirillOsenkov

@davkean
Copy link
Member Author

davkean commented May 13, 2016

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @KirillOsenkov on April 30, 2016 4:14

tag @ljcollins25

@davkean
Copy link
Member Author

davkean commented May 13, 2016

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
Copy link
Contributor

srivatsn commented Aug 9, 2016

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

@srivatsn srivatsn reopened this Aug 9, 2016
@srivatsn srivatsn modified the milestones: 1.0 RTM, 1.0 RC Aug 10, 2016
@davkean
Copy link
Member Author

davkean commented Sep 8, 2016

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

@srivatsn srivatsn modified the milestones: 1.0 RTM, 1.0 RC Sep 16, 2016
@davkean
Copy link
Member Author

davkean commented Nov 29, 2016

Also respects DisableFastUpToDateCheck.

@davkean
Copy link
Member Author

davkean commented Nov 29, 2016

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

@panopticoncentral
Copy link
Contributor

There are still some issues remaining.

@panopticoncentral
Copy link
Contributor

@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
Copy link
Contributor

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

@davkean
Copy link
Member Author

davkean commented Jun 5, 2017

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

@panopticoncentral
Copy link
Contributor

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

@panopticoncentral
Copy link
Contributor

All outstanding issues logged to new issues.

@panopticoncentral panopticoncentral removed their assignment Jun 6, 2017
@panopticoncentral panopticoncentral added the Resolution-Fixed The bug has been fixed, refer to the milestone to see in which release it was fixed. label Jun 6, 2017
@ebonato
Copy link

ebonato commented Jun 9, 2017

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
Copy link
Contributor

srivatsn commented Jun 9, 2017

@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
Copy link

ebonato commented Jun 9, 2017

@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
Copy link
Contributor

srivatsn commented Jun 9, 2017

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
Copy link

Jamaxack commented Feb 7, 2018

@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
Copy link
Member

Pilchie commented Feb 7, 2018

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

@Jamaxack
Copy link

Jamaxack commented Feb 7, 2018

@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
Copy link
Member

Pilchie commented Feb 7, 2018

#2763 is NOT marked as closed.

eric62369 pushed a commit to eric62369/project-system that referenced this issue Jul 10, 2020
Move to editor model for viewing binary logs (+ some cleanups)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Parity-Legacy-Feature Missing features from the legacy project system. Resolution-Fixed The bug has been fixed, refer to the milestone to see in which release it was fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.