Respect property to disable targeting pack caching for runtime build

[rainersigwald]

#19570 introduced caching in ResolveTargetingPackAssets. I'm not aware of complaints from "normal" users, but for the dotnet/runtime repo, which produces those targeting packs during its build, the caching can preserve stale data.

I think this is becoming an issue in between using dotnet build on source projects where the caching feature is not disabled as the env var is only set on the build scripts and then using dotnet build or dotnet test on a test project where the platform manifest is needed.

@rainersigwald is it possible that we can also support an MSBuild property to disable the targeting pack caching?

Originally posted by @safern in dotnet/runtime#61451 (comment)

[rainersigwald]

Yeah, we can add an input to the task and pass a property through to it. It would require an SDK update. @marcpopMSFT would you have any objection to adding such a feature to an SDK task when the only expected consumer is the runtime build? I personally don't . . .

Originally posted by @rainersigwald in dotnet/runtime#61451 (comment)

[ericstj]

Is it possible that other scenarios like dependency flow or servicing (both install new side-by-side targeting packs) would hit this? I didn't look at the cache keys to see if they would or not.

IMO it'd be better if we didn't have to disable this, but something in the cache-key captured the "change" that happens in dotnet/runtime that causes it to break. cc @safern @eerhardt

[rainersigwald]

captured the "change" that happens in dotnet/runtime that causes it to break

Yeah, is this just "files magically appear in those directories" or is it more complicated?

[ericstj]

I'm not 100% certain as I haven't looked at a repro personally. I can imagine things like file existence and modified time might be interesting inputs to capture in the cache key, similar to target inputs/outputs.

[rainersigwald]

We opted not to have existence/timestamp checks for cache invalidation for this particular cache because it doesn't generally change for users during a process lifetime since everything in it is part of the .NET SDK. Timestamp checks can be surprisingly expensive.

We can add them, but I'd prefer not to if we can get away with opting into "unstable targeting pack mode" in limited circumstances like "the runtime build".

[ericstj]

One final thought here. Runtime might want to benefit from caching too. Perhaps if you provided some way for us to control the cache key or change something about it so that we could differentiate this scenario. Could be a way to have cake and eat it too.