Up to date check needs to work with multi-TFM projects

[panopticoncentral]

Right now, we are called with the active configured project, but multi-TFM projects will build multiple configurations.

[panopticoncentral]

Since this is potentially somewhat complex, and since the issue hasn't been raised frequently, I'm moving this to 15.7. @davkean I'm curious what your thoughts on this are since you've thought so much about multi-TFM. The up-to-date checker is tied to a configured project. It doesn't seem correct that an up to date checker would be looking at other configurations. That might suggest that it would be more correct to do it at the CPS level? Or somewhere else?

[Pilchie]

See #3060. I think the idea would be to operate on all the "Implicitly active" projects. I agree that it's fine to move to 15.7, as this would only be an issue when you have different inputs between targets, which is rare.

[Pilchie]

🔗 also reported in https://developercommunity.visualstudio.com/content/problem/231529/fast-up-to-date-check-only-checks-one-targetframew.html.

[davkean]

We only ever build the first TFM's configured project (clearing the TargetFramework property so all TFMs build) - so only the first up-to-date check should run. However, as @Pilchie mentioned it should be grabbing data from all the "implicitly active" configured projects. I'd recommend a service that individually in each implicitly active configuration (similar to what I'm doing in #3423), that the core up-to-date queries to determine the real up-to-dateness.

[jaredpar]

I've been hitting this a lot this week as I've been moving the compiler test suite to run on CoreClr. Our setup is to have all of our test projects multi-target netcoreapp2.0 and net46. End up spending a bit of time debugging netcoreapp2.0 failures which locks the files in the output directory. Now if I build then net46 succeeds but netcoreapp2.0 fails due to lock files. Once I stop the debugger and build again nothing happens because the up to date check succeeds.

[drewnoakes]

Be sure to check the case in duplicate issue #4338.

[drewnoakes]

@jjmew I would like to take this for 16.8 as a precursor to working on proper multi-target support for the dependencies node. This would be a simpler implementation, would add customer value (I actually hit this myself today) and would help flesh out the design for #6183.

[drewnoakes]

We discussed this today with CPS and concluded the design is subtly different than it would be for the dependencies node.

The distinction is between aggregation across implicitly active configurations of services versus data sources.

• Making the fast up-to-date check support multi-targets correctly involves aggregating services. The extension point (IBuildUpToDateCheckProvider) may be exported per-implicitly-active configuration, and therefore may be exported in a non-active configuration, yet would still need to be considered. An example would be a multi-target project (e.g. iOS, Android) where iOS is active, yet a custom IBuildUpToDateCheckProvider is exported for Android only.

• In contrast, the dependencies node will aggregate data sources, for which UnwrapChainedProjectValueDataSource<,> is a good fit.

Notes about the resulting design:

• Need an IBuildUpToDateCheckProvider that lives in unconfigured project scope within CPS, and which aggregates all IBuildUpToDateCheckProvider instances across implicitly active configurations.
• As soon as one 'child' IBuildUpToDateCheckProvider returns false, the CancellationToken should be cancelled so that pending work in other configurations can be aborted.
• To reduce duplicate file system timestamp access, IBuildUpToDateCheckProvider2 could be introduced that overloads IsUpToDateAsync with an additional argument that obtains and caches these timestamps. That cache's lifespan would begin and end with that single top-level check.

This work will require changes in both CPS and the .NET Project System.

[jnyrup]

Here's a workaround when conditionally compiling *netcore30*.cs files only for netcoreapp3.0

<ItemGroup Condition=" '$(TargetFramework)' != 'netcoreapp3.0' ">
  <!-- Do not compile files -->
  <Compile  Remove="**/*netcore30*.cs" />

  <!-- Still show files in Solution Explorer -->
  <None Include="**/*netcore30*.cs" />

  <!-- Trigger rebuilds on changing the files -->
  <UpToDateCheckInput Include="**/*netcore30*.cs" />
</ItemGroup>