Publishing a ReadyToRun project with --no-restore requires changes to the restore
If you publish a project with
-p:PublishReadyToRun=true in addition to
--no-restore, the project will only build with packages that were restored in a prior
dotnet restore operation. In .NET 5, this process worked and resulted in a crossgen'd binary. In .NET 6, this same process will fail with the NETSDK1095 error.
In previous versions, the crossgen application was packaged with the runtime. As a result, the crossgen process was able to run on your application regardless of if the project had been restored or not. It was a common practice to separate
dotnet restore from
dotnet publish, adding
--no-restore to the publish command to ensure that no additional network accesses occurred.
In .NET 6,
dotnet restore followed by
dotnet publish -p:PublishReadyToRun=true --no-restore will fail with the NETSDK1095 error. This is because the crossgen binary is now shipped as a separate NuGet package, and so needs to be part of the restore operation for publishing to succeed.
Reason for change
The crossgen binary is not required for many workloads, so it was split out from the main SDK. It is typically acquired on-demand, and the publishing MSBuild targets now handle this acquisition by adding the package to the list of packages to be restored.
- If you want to maintain an isolated publish experience, tell the restore step that you'll be publishing ReadyToRun. Add
-p:PublishReadyToRun=trueto your restore command line as well.
- Or, remove
--no-restorefrom your publish command line to allow the publish command to restore crossgen as well.
Submit and view feedback for