CPM causes redundant recompilation about home

[jeffkl]

Since Directory.Packages.props is imported by MSBuild, it gets added to the MSBuildAllProjects property. If any MSBuild import is newer than the output of a project then it will rebuilt due to this declaration. Unfortunately, this is by design at the moment. A user could place any MSBuild logic in Directory.Packages.props that actually affects the compilation such as adding a new target that needs to run.
For example, I add this to my Directory.Packages.props:

<Target Name="MyCustomTarget" BeforeTargets="CoreCompile">
  <Message Text="Example" />
</Target>

If the CoreCompile target didn't consider $(MSBuildAllProjects) as an input, my projects won't re-run compilation and I would be scratching my head. Obviously, sometimes its desirable to trigger a rebuild and sometimes it isn't. But editing an MSBuild import currently always triggers a rebuild.

[martinrrm]

@jeffkl Can you help me triage this issue? I'm not sure if this is something we already have planned

[MarkKharitonov]

The rationale and the mechanism of it is totally clear to me. However, it may not be clear to all who read the CPM documentation and do not realize this regression in the behavior of a common scenario - a NuGet version is changed for a package. Before CPM only the touched project and its dependents are recompiled. When using CPM it is the entire solution. For big solutions containing unit test projects (which usually do not carry a lot of dependents) this is a big deal, as any change in the versions of the packages consumed by the unit tests, will now recompile all the business logic.

The CPM documentation should indicate that and provide workarounds, e.g. structuring the solution in a way that consolidates all the unit tests under a single folder and allows for a hierarchy of Directory.Packages.props files.

But not everything can be resolved with restructuring, so the side effect of recompiling it all is there all the time.

At least this should be emphasized.