dotnet-ef on Linux results in MSB3552: Resource file "**/*.resx" cannot be found

[Soeren-WBS]

Error

dotnet-ef --version 10.0.2 - Throws Exception

`/opt/hostedtoolcache/dotnet/sdk/10.0.102/Microsoft.Common.CurrentVersion.targets(3442,5): error MSB3552: Resource file "**/*.resx" cannot be found. [/home/vsts/work/1/s/src/xxx/xxx/xxx.csproj]
0 Warning(s)
1 Error(s)

Time Elapsed 00:00:02.45

Microsoft.EntityFrameworkCore.Tools.CommandException: Build failed. Use dotnet build to see the errors.
at Microsoft.EntityFrameworkCore.Tools.Project.Build(IEnumerable1 additionalArgs) at Microsoft.EntityFrameworkCore.Tools.RootCommand.Execute(String[] _) at Microsoft.EntityFrameworkCore.Tools.Commands.CommandBase.<>c__DisplayClass0_0.<Configure>b__0(String[] args) at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args) at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)

-> In version 10.0.1 this error did not occured. Error was thrown in a pipeline using efcore-migration-script-generator-task@1

Links

No response

Root Cause

unknown

Blocking

• This issue is blocking

Affected Releases

• .NET 10
• .NET 10 (SDK band build)
• .NET 11

[akoeplinger]

I assume this also happens with just dotnet build right? looks similar to dotnet/sdk#10172

[konradmalik]

It is similar, but it's only related to dotnet-ef tool 10.0.2.

I can reproduce this on my linux machine.

With dotnet-ef tool version 10.0.1:

 dotnet ef migrations bundle --project "myproject" --configuration Release --verbose

produces efbundle binary in the current dir and proper files in my bin directory not tracked in git.

But dotnet-ef tool version 10.0.2 it additionally generates a Windows-like path in my repo:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	"myproject/bin\\Release/"

I guess this is the reason that later in CI when building my container I get the same error as @Soeren-WBS

[ffried]

We've run into the same issue.

As a workaround for building the migrations bundle, you can first build the startup project using dotnet build and then use --no-build option when generating the bundle.
Note that if you're cross-compiling, the startup project needs to be built for the current host RID, not the target RID!

[AndriySvyryd]

There were only 2 relevant PRs between 10.0.1 and 10.0.2:

• [release/10.0] Switch back to net8.0 for tools #37207
• [release/10.0] Allow tools to run on projects targeting multiple frameworks #37301

Try adding --framework net10.0 to the command line and making sure that only v10+ SDKs are installed on the machine. If that doesn't work please share a small project that shows the issue.

[rdrooij]

We have the same issue in a github action running on ubuntu-latest runner. Executing the command locally on windows in powershell does not have this issue.

[ffried]

Repro project: EFCoreMigrationBundleRepro.zip

Extract it, change into the EFCoreMIgraitonBundleRepro directory and run docker build -t ef-core-migration-bundle-repro .
The Dockerfile uses mcr.microsoft.com/dotnet/sdk:10.0.102, so it should only have the v10 SDK.

I can also reproduce it locally on macOS (also only having the v10 SDK installed):

• Make sure no obj and bin folders are present from a previous build (since building the project first will work):
  • rm -rf bin* obj*
• Run dotnet restore
• Run dotnet ef migrations bundle --verbose --project EFCoreMigrationBundleRepro.csproj --configuration release

This will generate the error as well, and you can also see that a bin\release directory is created (vs. bin/release which would be correct on macOS / Linux).

Adding --framework net10.0 does not help (neither in Docker nor locally).

[popiazaza]

Spent a whole day debugging why ef core migration in ubuntu Azure Pipeline doesn't work. Downgraded to 10.0.1 and it work just fine.

[fteotini]

can confirm this happens with migration add aswell