Upgraded VS2022 to latest supporting .Net 7 - Now dotnet publish fails.

Ask a question

I upgraded my Visual Studio 2022 instance to latest that supports .Net 7. As soon as I did that, my dotnet ef migrations bundle commands now throw exception saying the runtime pack for Microsoft.NETCore.App.Runtime.win-x64 was not downloaded.

Building bundle...
dotnet publish --runtime win10-x64 --output C:\Users\craig.garcia\AppData\Local\Temp\1\q2ywkzkn.oxh\publish --no-self-contained
MSBuild version 17.4.0+18d5aef85 for .NET
  Determining projects to restore...
  Restored C:\sc\ws1\YOV Services\Shared\YOV.Contracts\YOV.Contracts.csproj (in 240 ms).
  Restored C:\sc\ws1\YOV Services\Shared\Shared.ConsoleServices\Shared.ConsoleServices.csproj (in 442 ms).
  Restored C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj (in 536 ms).
  Restored C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\Account.EF.Migrations.csproj (in 536 ms).
  Restored C:\Users\craig.garcia\AppData\Local\Temp\1\q2ywkzkn.oxh\efbundle.csproj (in 601 ms).
C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(1136,5): warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used. [C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj]
C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(448,5): error NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.win-x64 was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'win-x64'. [C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj]
Microsoft.EntityFrameworkCore.Tools.CommandException: Build failed. Use --verbose to see errors.
   at Microsoft.EntityFrameworkCore.Tools.Commands.MigrationsBundleCommand.Execute(String[] args)
   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)

This project set up has the Entity Framework project, and a separate project for migrations. The Migrations project references the Entity Framework project.

After hitting this issue, I then proceeded to update all projects form .Net 6.0 to .Net 7.0. It didn’t help and now produces a different error. Cleaned solution, deleted bin and obj folders for all projects. No help.

Notice towards the bottom, it’s producing Account.EF.dll twice, but in two different paths, one in the *net7.0* folder, and now one in the *net7.0\win-x64* folder. This is new behavior and did not do this before upgrade to latest Visual Studio 2022.

C:\sc\ws1\YOV Services\Account\Account.EF>dotnet ef migrations bundle --project ..\Account.EF.Migrations --verbose --force
Using project 'C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\Account.EF.Migrations.csproj'.
Using startup project 'C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj'.
Writing 'C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\obj\Account.EF.Migrations.csproj.EntityFrameworkCore.targets'...
dotnet msbuild /target:GetEFProjectMetadata /property:EFProjectMetadataFile=C:\Users\....\AppData\Local\Temp\1\tmp3AD5.tmp /verbosity:quiet /nologo "C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\Account.EF.Migrations.csproj"
Writing 'C:\sc\ws1\YOV Services\Account\Account.EF\obj\Account.EF.csproj.EntityFrameworkCore.targets'...
dotnet msbuild /target:GetEFProjectMetadata /property:EFProjectMetadataFile=C:\Users\....\AppData\Local\Temp\1\tmp3D56.tmp /verbosity:quiet /nologo "C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj"
Build started...
dotnet build "C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj" /verbosity:quiet /nologo

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.74
Build succeeded.
dotnet exec --depsfile "C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\Account.EF.deps.json" --additionalprobingpath C:\Users\....\.nuget\packages --additionalprobingpath "C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages" --additionalprobingpath "C:\Program Files (x86)\Microsoft\Xamarin\NuGet" --runtimeconfig "C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\Account.EF.runtimeconfig.json" C:\Users\....\.dotnet\tools\.store\dotnet-ef\7.0.0\dotnet-ef\7.0.0\tools\net6.0\any\tools\netcoreapp2.0\any\ef.dll migrations bundle --force --assembly "C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\Account.EF.Migrations.dll" --project "C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\Account.EF.Migrations.csproj" --startup-assembly "C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\Account.EF.dll" --startup-project "C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj" --project-dir "C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\\" --root-namespace Account.EF.Migrations --language C# --framework net7.0 --nullable --working-dir "C:\sc\ws1\YOV Services\Account\Account.EF" --verbose
Using assembly 'Account.EF.Migrations'.
Using startup assembly 'Account.EF'.
Using application base 'C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0'.
Using working directory 'C:\sc\ws1\YOV Services\Account\Account.EF'.
Using root namespace 'Account.EF.Migrations'.
Using project directory 'C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\'.
Remaining arguments: .
Finding DbContext classes...
Finding IDesignTimeDbContextFactory implementations...
Finding application service provider in assembly 'Account.EF'...
Finding Microsoft.Extensions.Hosting service provider...
Using environment 'Development'.
Using application service provider from Microsoft.Extensions.Hosting.
Using UseSqlServer options to set Connection String.
Found DbContext 'AccountModelContext'.
Finding DbContext classes in the project...
Using context 'AccountModelContext'.
optionsBuilder is configured. Ignoring appsettings.Development.json
dbug: 11/16/2022 22:46:02.270 CoreEventId.ShadowPropertyCreated[10600] (Microsoft.EntityFrameworkCore.Model.Validation)
      The property 'AccountServicePrice.AutoRenewPaymentProviderId' was created in shadow state because there are no eligible CLR members with a matching name.
dbug: 11/16/2022 22:46:02.499 CoreEventId.ContextInitialized[10403] (Microsoft.EntityFrameworkCore.Infrastructure)
      Entity Framework Core 7.0.0 initialized 'AccountModelContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer:7.0.0' with options: CommandTimeout=300 MigrationsAssembly=Account.EF.Migrations using lazy loading proxies
dbug: 11/16/2022 22:46:02.505 RelationalEventId.ConnectionCreating[20005] (Microsoft.EntityFrameworkCore.Database.Connection)
      Creating DbConnection.
dbug: 11/16/2022 22:46:02.531 RelationalEventId.ConnectionCreated[20006] (Microsoft.EntityFrameworkCore.Database.Connection)
      Created DbConnection. (25ms).
dbug: 11/16/2022 22:46:02.533 CoreEventId.ContextDisposed[10407] (Microsoft.EntityFrameworkCore.Infrastructure)
      'AccountModelContext' disposed.
dbug: 11/16/2022 22:46:02.535 RelationalEventId.ConnectionDisposing[20007] (Microsoft.EntityFrameworkCore.Database.Connection)
      Disposing connection to database 'Account' on server '(localdb)\MSSQLLocalDB'.
dbug: 11/16/2022 22:46:02.538 RelationalEventId.ConnectionDisposed[20008] (Microsoft.EntityFrameworkCore.Database.Connection)
      Disposed connection to database '' on server '' (1ms).
Building bundle...
dotnet publish --runtime win10-x64 --output C:\Users\....\AppData\Local\Temp\1\mgkdrmg3.xx1\publish --no-self-contained
MSBuild version 17.4.0+18d5aef85 for .NET
  Determining projects to restore...
  Restored C:\sc\ws1\YOV Services\Shared\YOV.Contracts\YOV.Contracts.csproj (in 292 ms).
  Restored C:\sc\ws1\YOV Services\Shared\Shared.ConsoleServices\Shared.ConsoleServices.csproj (in 411 ms).
  Restored C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj (in 506 ms).
  Restored C:\Users\....\AppData\Local\Temp\1\mgkdrmg3.xx1\efbundle.csproj (in 579 ms).
  1 of 5 projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(1136,5): warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used. [C:\sc\ws1\YOV Services\Account\Account.EF\Account.EF.csproj]
  Shared.ConsoleServices -> C:\sc\ws1\YOV Services\Shared\Shared.ConsoleServices\bin\Debug\net7.0\Shared.ConsoleServices.dll
  YOV.Contracts -> C:\sc\ws1\YOV Services\Shared\YOV.Contracts\bin\Debug\net7.0\YOV.Contracts.dll
  Account.EF -> C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\win10-x64\Account.EF.dll
  Account.EF -> C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\Account.EF.dll
  Account.EF.Migrations -> C:\sc\ws1\YOV Services\Account\Account.EF.Migrations\bin\Debug\net7.0\Account.EF.Migrations.dll
  efbundle -> C:\Users\....\AppData\Local\Temp\1\mgkdrmg3.xx1\bin\Debug\net7.0\win10-x64\efbundle.dll
C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: C:\sc\ws1\YOV Services\Account\Account.EF\obj\Debug\net7.0\win10-x64\apphost.exe, C:\sc\ws1\YOV Services\Account\Account.EF\obj\Debug\net7.0\apphost.exe, C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\win10-x64\Account.EF.runtimeconfig.json, C:\sc\ws1\YOV Services\Account\Account.EF\bin\Debug\net7.0\Account.EF.runtimeconfig.json. [C:\Users\....\AppData\Local\Temp\1\mgkdrmg3.xx1\efbundle.csproj]
Microsoft.EntityFrameworkCore.Tools.CommandException: Build failed. Use --verbose to see errors.
   at Microsoft.EntityFrameworkCore.Tools.Commands.MigrationsBundleCommand.Execute(String[] args)
   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)
Build failed. Use --verbose to see errors.

MSBuild version 17.4.0+18d5aef85 for .NET EF Core version: 7.0.0 Database provider: Microsoft.EntityFrameworkCore.SqlServer Target framework: .NET 7.0 Operating system: Windows 10 IDE: Visual Studio 2022 17.4.1

[nagilson]

@dantheman999301 @Relki Given that this is publishing a solution, I believe this is a known issue. The problem is that currently a solution publish, build, or whatever else, flows a RuntimeIdentifier when it is not supposed to. Generally a library project is RidAgnostic … probably dotnet restore tried to restore the library without a RID, but since the solution build/publish incorrectly flowed the RID, it failed. It ultimately boils down to something similar to https://github.com/dotnet/msbuild/issues/8154 which will require a restructuring of a lot of code, I don’t expect it to be handled soon. There were some bug fixes to how properties flow which may have impacted this. RuntimeIdentifiers likely bypasses the RidAgnostic flag for restore which causes it to work again. I’ll try to take a look and see if I can provide any other help here.

@pimbrouwers What you mention is a different issue entirely and is related to how dotnet clean works. We know why this is happening and I’ll try to write up a separate issue for it. It is because clean cleans for the each configuration, rid, tfm, etc, but there is no runtime config assets jsons for the rid because it doesnt exist until build.

If you run a dotnet build then the clean would work.

[deadwards90]

We’ve just run into this issue as well.

What is really peculiar is that it seems to only affect one project in our solution. We’re in the process of splitting out a Monolith that has a lot of Contexts into individual Microservices each with its own one.

The old Monolith build was unaffected by migrating from .NET 6 to .NET 7, the bundles all work fine but for whatever reason, the new Microservice runs into the same issue described. Adding the runtime identifiers worked so thanks @Relki for that tip!

The way we build the projects and then bundle the migrations is practically identical and the csproj files are similar outside of the usual PackageReference details.

Would be great to get to the bottom of this, would rather not have to explicitly have RuntimeIdentifiers in every service project from a maintenance point of view. If there is anything other information I can provide, please let me know.