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

[Relki]

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

[Relki]

Looks like I resolved the issue. I had to update the Entity Framework project and the Migrations project files and add to PropertyGroup.

	<RuntimeIdentifiers>win-x64;win-x86;linux-arm64</RuntimeIdentifiers>

I also deleted the .vs folder. This didn't have an impact that I can recall but doesn't hurt.

Now it builds the efBundle.exe file like it did before upgrade VS 2022. So, I'm now on latest VS 2022 and all projects upgraded to .Net 7.0. Cross fingers, checking Azure Devops pipelines still work.

Edit: Azure Devops Pipleine works. Just had to make sure my agents had latest .Net 7 SDK installed. I also run a powershell script when agent first starts to update Ef bundles tools to latest; Since I use a migrations project and an entity framework project, I did have to update my .NET Core command to output my migrations project with .NET Core arguments; -o ./bin/Debug/net7.0/ instead of -o ./bin/Debug/net6.0/, but operation success.

$packageName = "dotnet-ef"

$output = dotnet tool search $packageName --prerelease --take 1
$outputString = ("" + $output)
$indexOfVersionLine = $outputString.IndexOf($packageName)
$latestVersion = $outputString.substring($indexOfVersionLine + $packageName.length).trim().split(" ")[0].trim()

Write-Host "Updating "$packageName" to" $latestVersion
dotnet tool update -g $packageName --version $latestVersion

[ajcvickers]

/cc @bricelam

[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.

[Relki]

Glad this helped you. It only consumed a couple of days of blockage for me, but I had new features to roll out that relied on database changes which couldn't do after VS2022 update. If I was really desperate, I might have rolled back the VS update or jumped on a different machine that didn't have the update yet. I didn't see what our build pipelines would do with it though so I didn't check if it was affected.

…

________________________________ From: Daniel Edwards ***@***.***> Sent: Wednesday, November 23, 2022 2:55 AM To: dotnet/efcore ***@***.***> Cc: Craig ***@***.***>; Mention ***@***.***> Subject: Re: [dotnet/efcore] Upgraded VS2022 to latest supporting .Net 7 - Now dotnet ef migrations bundle throws exception. (Issue dotnet/sdk#29859) 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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRelki&data=05%7C01%7C%7C2db8eea3890c4599ad6d08dacd4132c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638047977152791720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xBGvlOwIjXwtTuxBWWrMZYMjGMofXTr7HaNVYTZQRoc%3D&reserved=0> 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. — Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fefcore%2Fissues%2F29594%23issuecomment-1324871051&data=05%7C01%7C%7C2db8eea3890c4599ad6d08dacd4132c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638047977152791720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uWn3Z6%2Bfe1MLo%2F%2FkNEGhQYsR%2FPkbAomHRKczoFC96lM%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAK6SED56IIQ6JNC3VUVRNVLWJXZZBANCNFSM6AAAAAASDBNPLY&data=05%7C01%7C%7C2db8eea3890c4599ad6d08dacd4132c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638047977152791720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xay9Hpz7t%2BLKtdNQJoincOozW9hSk4TFvJopN6LBGjg%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ctolkien]

We're now hitting this in GitHub actions

[bricelam]

I'm not able to repro this. If anyone could provide more information about their project (e.g. the .csproj) that may help us investigate.

I'm going to hand this off to the .NET SDK team since all EF Core does is call dotnet publish on a generated project. Here's a repro project that takes dotnet ef out of the picture.

[pimbrouwers]

I can confirm/repro this using the 7.0.102 SDK.

I've been working on a project for the past several months targeting net7.0 publishing to win-x64 without any issues whatsoever. After coming back from the holiday's I now get this error as well during restore. I was able to repro it with a blank console app, adding the win-x64 runtime identifier to the project file.

FsConsole.fsproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net7.0</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>

</Project>

Program.fs

printfn "Hello world"

Console output

PS C:\Users\pim\Downloads\FsConsole> dotnet clean
MSBuild version 17.4.1+9a89d02ff for .NET
Build started 2023-01-15 11:31:20 AM.
     1>Project "C:\Users\pim\Downloads\FsConsole\FsConsole.fsproj" on node 1 (Clean target(s)).
     1>C:\Program Files\dotnet\sdk\7.0.102\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1047: 
       Assets file 'C:\Users\pim\Downloads\FsConsole\obj\project.assets.json' doesn't have a target for 'net7.0/win-x64'. Ensure that restore has 
       run and that you have included 'net7.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's 
       RuntimeIdentifiers. [C:\Users\pim\Downloads\FsConsole\FsConsole.fsproj]
     1>Done Building Project "C:\Users\pim\Downloads\FsConsole\FsConsole.fsproj" (Clean target(s)) -- FAILED.

Build FAILED.

       "C:\Users\pim\Downloads\FsConsole\FsConsole.fsproj" (Clean target) (1) ->
       (ResolvePackageAssets target) -> 
         C:\Program Files\dotnet\sdk\7.0.102\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1047
       : Assets file 'C:\Users\pim\Downloads\FsConsole\obj\project.assets.json' doesn't have a target for 'net7.0/win-x64'. Ensure that restore ha
       s run and that you have included 'net7.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project'
       s RuntimeIdentifiers. [C:\Users\pim\Downloads\FsConsole\FsConsole.fsproj]

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.62

[deadwards90]

@bricelam

<Project Sdk="Microsoft.NET.Sdk.Web">

    <PropertyGroup>
        <TargetFramework>net7.0</TargetFramework>
        <Nullable>enable</Nullable>
        <ImplicitUsings>enable</ImplicitUsings>
        <AnalysisMode>All</AnalysisMode>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
        <WeaverConfiguration>
          <Weavers>
            <RuntimeNullables CheckNonPublic="true" CheckOutputs="false" />
            <ConfigureAwait ContinueOnCapturedContext="false" />
          </Weavers>
        </WeaverConfiguration>
        <RuntimeIdentifiers>win-x64;linux-arm64;linux-x64;osx-x64</RuntimeIdentifiers>
      
    </PropertyGroup>

    <ItemGroup>
      <ProjectReference Include="..\..\..\Common\WebApi\WebApi.csproj" />
      <ProjectReference Include="..\..\Common.Microservices\Common.Microservices.csproj" />
      <ProjectReference Include="..\Accounting.ApiModels\Accounting.ApiModels.csproj" />
    </ItemGroup>
  
</Project>

This is it in a working state, removing the RuntimeIdentifiers breaks it.

[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 dotnet/msbuild#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.