NuGet global-packages cache behavior with floating version ranges
28K reputation · 04 Jun 2023, 05:24 UTC
NuGet utilizes a local global-packages folder to cache artifacts and reduce network overhead during restoration. When a project specifies a floating version range (e.g., 1.0.*), the restoration process is designed to resolve the latest compatible version available from the configured sources.
There is uncertainty regarding the priority of the local cache over remote source metadata when a newer version of a floating package is published to the feed. Specifically, it is unclear if the restore process consistently triggers a remote check to validate the floating range or if it defaults to the highest version already present in the local cache.
- Does the
dotnet restoreprocess automatically detect newer floating versions if a compatible version already exists in the global cache? - What is the expected behavior when a
packages.lock.jsonfile is absent during the resolution of floating versions?