You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using repeatable package restores in our .NET build pipeline. However as Azure DevOps windows-2022 version 20241113.3.0 started rolling out to agents, our build has been failing:
error NU1004: The project's runtime identifiers have changed from. Project's runtime identifiers: win-x86, lock file's runtime identifiers win7-x86.The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file.
We're still targeting .NET 8, not .NET 9, so I don't understand why this is now failing. This is seemingly related to NuGet yet again changing identifiers between versions and the lockfiles not being compatible between SDKs?
We've since tried updating the lockfiles, which makes the build succeed when .NET 9 SDK is installed. However as some agents are still running 20241021.1.0, the updated lockfiles will fail on those. This is not a great situation to be in. Also updating the lockfiles requires all our developers to install .NET 9 SDK, which is something we would like to avoid.
This is related to a RID Graph change that we did in .NET 8. There was a related change that applies to projects targeting .NET Framework that went into the .NET 9 SDK: dotnet/sdk#36848
If you want to try to avoid updating your lock files you should be able to set the RuntimeIdentifier property to win7-x86 in projects when targeting .NET Framework. You could probably instead set the UseRidGraph property to true, but that would revert to the .NET 7 behavior and would require a lock file update.
Closing this as external. There is a workaround and everything is working as designed, please open an issue at https://github.com/dotnet/sdk/issues/new/choose to suggest an improvement for this experience when the runtime identifier graph changes in the .NET SDK.
NuGet Product Used
dotnet.exe
Product Version
9.0.100
Worked before?
8.0.301
Impact
It's more difficult to complete my work
Repro Steps & Context
We're using repeatable package restores in our .NET build pipeline. However as Azure DevOps windows-2022 version 20241113.3.0 started rolling out to agents, our build has been failing:
We're still targeting .NET 8, not .NET 9, so I don't understand why this is now failing. This is seemingly related to NuGet yet again changing identifiers between versions and the lockfiles not being compatible between SDKs?
We've since tried updating the lockfiles, which makes the build succeed when .NET 9 SDK is installed. However as some agents are still running 20241021.1.0, the updated lockfiles will fail on those. This is not a great situation to be in. Also updating the lockfiles requires all our developers to install .NET 9 SDK, which is something we would like to avoid.
Verbose Logs
Also reported to Azure DevOps.
The text was updated successfully, but these errors were encountered: