Respect property to disable targeting pack caching for runtime build
See original GitHub issue#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 usingdotnet build
ordotnet 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 https://github.com/dotnet/runtime/issues/61451#issuecomment-982812791_
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Parallel Docker build with dotnet restore thrashes each ...
I want my builds to be as fast as possible, so I involve as much caching as possible. This is achieved in two...
Read more ><disableCachingBindingFailures> Element
In this article Specifies whether to disable the caching of binding failures that occur because the assembly was not found by probing.
Read more >NuGet pack and restore as MSBuild targets
To suppress package dependencies from generated NuGet package, set SuppressDependenciesWhenPacking to true which will allow skipping all the ...
Read more >Disable Managed Package Runtime
Disable Managed Package Runtime for faster FlexCard and OmniScript activation and to view and modify ... Remove an Attribute from a Target Name...
Read more >Getting Started | Caching Data with Spring
Caching Data with Spring. This guide walks you through the process of enabling caching on a Spring managed bean. What You Will build....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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”.
_Originally posted by @rainersigwald in https://github.com/dotnet/runtime/issues/61451#issuecomment-982815610_