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
Now we can demonstrate the issue by running dotnet publish:
dotnet publish --runtime linux-x64 --no-self-contained
Microsoft (R) Build Engine version 17.0.0-preview-21501-01+bbcce1dff for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
Restored /src/src.csproj (in 338 ms).
You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
src -> /src/bin/Debug/net6.0/linux-x64/src.dll
src -> /src/bin/Debug/net6.0/linux-x64/publish/
Generating Entity Framework SQL Scripts...
Executing command: dotnet ef migrations script --no-build --idempotent --configuration Debug --output "/src/obj/Debug/net6.0/linux-x64/PubTmp/EFSQLScripts/EFGetStarted.BloggingContext.sql" --context EFGetStarted.BloggingContext
/usr/share/dotnet/sdk/6.0.100-rc.2.21505.57/Sdks/Microsoft.NET.Sdk.Publish/targets/TransformTargets/Microsoft.NET.Sdk.Publish.TransformFiles.targets(221,5): error : Entity Framework SQL Script generation failed [/src/src.csproj]
The RID we choose doesn't matter.
It fails, because the command run internally, dotnet ef migrations script --no-build ... tries to execute the binaries of no runtime identifier and they don't exist, and it also cannot build them on its own due to --no-build.
Sadly and ironically, this bug exists due to my own suggestion in #12465. I'm not sure, but I think it has existed since SDK 5.0. I haven't spotted it earlier, because I have not used SDK 5 in this scenario.
When you try to fix this, you may consider flowing the runtime identifier into dotnet ef migrations script. This is not going to work in "cross platform" builds. By this I mean a situation where we are on e.g. Linux, but we publish for win-x64. dotnet ef must run on the current platform (Linux in this example), executing it with Windows binaries obviously won't work.
The best fix may be to remove --no-build from the command.
Exceptions (if any)
Further technical details
dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.100-rc.2.21505.57
Commit: ab39070116
Runtime Environment:
OS Name: debian
OS Version: 11
OS Platform: Linux
RID: debian.11-x64
Base Path: /usr/share/dotnet/sdk/6.0.100-rc.2.21505.57/
Host (useful for support):
Version: 6.0.0-rc.2.21480.5
Commit: 6b11d64e7e
.NET SDKs installed:
6.0.100-rc.2.21505.57 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.0-rc.2.21480.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0-rc.2.21480.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
The text was updated successfully, but these errors were encountered:
Describe the bug
If a project has
EFMigrations
items,dotnet publish --runtime [rid]
fails:To Reproduce
Prepare the project first:
Create
Model.cs
with:Then create a migration:
And finally change the project file (csproj) to include:
Now we can demonstrate the issue by running dotnet publish:
The RID we choose doesn't matter.
It fails, because the command run internally,
dotnet ef migrations script --no-build ...
tries to execute the binaries of no runtime identifier and they don't exist, and it also cannot build them on its own due to--no-build
.Sadly and ironically, this bug exists due to my own suggestion in #12465. I'm not sure, but I think it has existed since SDK 5.0. I haven't spotted it earlier, because I have not used SDK 5 in this scenario.
When you try to fix this, you may consider flowing the runtime identifier into
dotnet ef migrations script
. This is not going to work in "cross platform" builds. By this I mean a situation where we are on e.g. Linux, but we publish for win-x64.dotnet ef
must run on the current platform (Linux in this example), executing it with Windows binaries obviously won't work.The best fix may be to remove
--no-build
from the command.Exceptions (if any)
Further technical details
The text was updated successfully, but these errors were encountered: