Closed vedion closed 6 months ago
Both Microsoft.NET.ILLink.Tasks
and Microsoft.NET.Sdk.WebAssembly.Pack
are packages implicitly used by the SDK. It's an SDK implementation detail for WebAssembly and ILLink
@dotnet/nuget-team Is there a way to exclude such packages from lock file? The versions are defined by SDK, not by user, and their versions should be synced by the SDK logic
cc @lewing
For us this is an issue when the Microsoft-hosted agents are being updated. While updating the agents are running different .NET Core SDK versions and we will get this error:
"error NU1004: The package reference Microsoft.NET.ILLink.Tasks version has changed from [8.0.2, ) to [8.0.3, ).The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode."
@maraf lock files have 2 purposes:
Ignoring implicitly defined packages might be suitable for 1 (for some opinions of suitable). But ignoring those implicit packages would violate the protection provided by 2, the content hash.
It's an unfortunate design mismatch between lock files and implicit packages (both were implemented before I joined NuGet, I don't know which happened first). The .NET SDK and other teams that add implicit packages would need to work with NuGet to come up with a new design for lock files to enable the request, and that's assuming we can come to an agreement on the security implication of the changing package hash.
Customers who want to use lock files with the current limitation need to use a global.json to lock the .NET SDK to a specific version. On CI, they'll need to use the dotnet-install
script to install global.json's SDK version, and not use the .NET SDK that's pre-installed on the agent. This means that every month there's a chance that a security fix will be released and customers will need to increment the .NET SDK version, run a restore without locked mode to update the lock file, then commit it all into source control.
While the agents are being rolled out I can still run into an agent with the previous version of .NET SDK and then it will fail on that agent.
A solution for me could be to disable rollForward in global.json: { "sdk": { "version": "8.0.200", "rollForward": "disable" } }
And then install that version on the pipeline:
BUT then I run into another issue. When running "dotnet restore --force-evaluate" it respects global.json but when running "dotnet restore --locked-mode" it does not.
That is quite bad.
Closing as duplicate of https://github.com/dotnet/sdk/issues/39635
Is there an existing issue for this?
Describe the bug
Hi,
I have a project using:
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
and<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
I get two Auto-referenced packages added to the "packages.lock.json" file:
I do not have a direct reference to "Microsoft.NET.ILLink.Tasks" and "Microsoft.NET.Sdk.WebAssembly.Pack". They are also marked with "(A)" when doing a "dotnet list .\Client.csproj package":
It is correct that the auto-referenced packages gets added to the "packages.lock.json" file?
Best Regards, Anders Havn
Expected Behavior
Auto-referenced packages not added to the "packages.lock.json" file.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
8.0.203
Anything else?
No response