.NET SDK: 'error NETSDK1047: Assets file doesn't have a target for net10.0/win-x64'

error NETSDK1047: Assets file '...\obj\project.assets.json' doesn't have a target for 'net10.0/win-x64'. The restore ran without a runtime identifier, and the publish that followed asked for one while skipping restore. Pass the same -r to dotnet restore that you pass to dotnet publish.

In a script that restores once and then publishes with --no-restore, change the restore line to dotnet restore -r win-x64 (or whichever runtime you publish for). Or drop --no-restore and let publish restore for itself.

The error

C:\Program Files\dotnet\sdk\10.0.403\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1047: Assets file '...\RidLab\obj\project.assets.json' doesn't have a target for 'net10.0/win-x64'. Ensure that restore has run and that you have included 'net10.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers. [...\RidLab\RidLab.csproj]

The project paths are shortened; nothing else in the output was changed.

Why it happens

Restore writes obj\project.assets.json with one section for each combination of target framework and runtime identifier it was asked for. A plain dotnet restore on a project with no RuntimeIdentifier writes only the framework section, net10.0. A publish with -r win-x64 looks for the net10.0/win-x64 section. With --no-restore nothing writes that section, and the build stops before compiling.

The message is the RID version of NETSDK1005: the same file, the same check, one more level of detail. Its last sentence points at the other way to fix it, listing the runtime in the project so every restore includes it. Nothing is wrong with your code or your packages; only the order and the arguments of two commands disagree.

The fix

dotnet restore -r win-x64
dotnet publish -c Release -r win-x64 --no-restore

With the runtime on the restore, the restore ran again (it had reported "All projects are up-to-date" before) and the publish wrote bin\Release\net10.0\win-x64\publish\. The simplest alternative is to leave out --no-restore: dotnet publish -c Release -r linux-x64 on the same project restored and published in one step. Keep the separate restore only when you have a reason, such as a cached restore layer in a Dockerfile, and then keep the runtime identifiers of both commands identical.

How it was reproduced

A dotnet new console project on .NET SDK 10.0.403 targeting net10.0, with no runtime identifier in the .csproj. dotnet restore followed by dotnet publish -c Release -r win-x64 --no-restore failed as shown; adding -r win-x64 to the restore fixed it.

Frequently asked

What does NETSDK1047 assets file doesn't have a target for net10.0/win-x64 mean?

The last restore did not include the runtime identifier you are now building or publishing for, and the command skipped restore, so project.assets.json has no section for that framework and runtime pair.

How do I fix NETSDK1047 with dotnet publish --no-restore?

Restore with the same runtime identifier first, for example dotnet restore -r win-x64, then run dotnet publish -r win-x64 --no-restore. Or drop --no-restore.

Why does dotnet publish -r work without --no-restore?

Without --no-restore, publish runs restore itself with the runtime identifier you passed, so the assets file gets the section it needs.

More decoded errors in the Fixes category. For the variant without a runtime, after a target framework change, see NETSDK1005.