Open Relki opened 1 year ago
Looks like I resolved the issue. I had to update the Entity Framework project and the Migrations project files and add
<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
/cc @bricelam
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.
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 @Relkihttps://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 GitHubhttps://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 unsubscribehttps://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: @.***>
We're now hitting this in GitHub actions
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.
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
@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.
@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.
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.
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.
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