Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NU1004 after installing .NET 9 SDK #13941

Closed
Bouke opened this issue Nov 19, 2024 · 2 comments
Closed

NU1004 after installing .NET 9 SDK #13941

Bouke opened this issue Nov 19, 2024 · 2 comments
Labels
Resolution:External This issue appears to be External to nuget Type:Bug

Comments

@Bouke
Copy link

Bouke commented Nov 19, 2024

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:

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.

Verbose Logs

Also reported to Azure DevOps.

@dsplaisted
Copy link

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.

@jeffkl
Copy link
Contributor

jeffkl commented Nov 25, 2024

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.

@jeffkl jeffkl closed this as not planned Won't fix, can't repro, duplicate, stale Nov 25, 2024
@jeffkl jeffkl added Resolution:External This issue appears to be External to nuget and removed Triage:Untriaged labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution:External This issue appears to be External to nuget Type:Bug
Projects
None yet
Development

No branches or pull requests

3 participants