Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/6.0] Tools: Target .NET 6 to improve compatibility with osx-arm64 #27807

Merged
merged 1 commit into from
May 13, 2022

Conversation

bricelam
Copy link
Contributor

@bricelam bricelam commented Apr 12, 2022

For tools targeting versions below 6.0, the dotnet tool install command creates an x64 shim. When users try to run dotnet ef, it errors with The required library libhostfxr.dylib could not be found.

For tools targeting 6.0 or higher, it will generate an arm64 shim. This enables the tool to work as expected.

Fixes #27787, fixes #27827

Customer impact

Without this, users are required to specify -a arm64 when installing the tool on osx-arm64 before it will work.

Regression?

Sort of. The dotnet tool install behavior changed in 6.0.1 causing our tool to stop working.

Risk

Low. EF Core 6.0 already requires .NET 6.0, so users already have it installed, and because we specify RollForward= Major, it's already being used to run dotnet-ef.

@bricelam bricelam requested a review from a team April 12, 2022 17:30
@@ -8,6 +8,7 @@
<RootNamespace>Microsoft.EntityFrameworkCore.Tools</RootNamespace>
<CheckEolTargetFramework>False</CheckEolTargetFramework>
<CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)..\..\rulesets\EFCore.noxmldocs.ruleset</CodeAnalysisRuleSet>
<RollForward>Major</RollForward>
Copy link
Contributor Author

@bricelam bricelam Apr 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change isn't really related to the M1 issues. It's a cherry-pick from main of PR #27671.

It helps in a few corner cases where dotnet-ef can't determine a project's target framework. On other platforms, the workaround is to install an older version of the runtime. But on osx-arm64, there is no workaround since that older version isn't available.

We've had a fair amount of users hit this on other platforms, and I suspect that once we unblock osx-arm64 we'll see a few more reports from those users who won't be able to work around it. It seems prudent to me to eagerly fix this now as part of this change rather than making users wait a few more months for another patch.

@bricelam bricelam added this to the 6.0.x milestone Apr 12, 2022
src/dotnet-ef/dotnet-ef.csproj Outdated Show resolved Hide resolved
src/dotnet-ef/dotnet-ef.csproj Show resolved Hide resolved
<OutputType>Exe</OutputType>
<PackAsTool>true</PackAsTool>
<PackAsToolShimRuntimeIdentifiers>win-x64;win-x86</PackAsToolShimRuntimeIdentifiers>
<PackAsToolShimRuntimeIdentifiers>win-x64;win-x86;win-arm64</PackAsToolShimRuntimeIdentifiers>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also not related to osx-arm64, but allows us to codesign a win-arm64 shim.

Also adds a shim we can sign for win-arm64 and rolls ef.dll forward across major runtime versions.

Fixes dotnet#27787, fixes dotnet#27827
@bricelam bricelam merged commit 23895c7 into dotnet:release/6.0 May 13, 2022
@bricelam bricelam deleted the m1 branch May 13, 2022 16:56
@AraHaan
Copy link
Member

AraHaan commented May 16, 2022

So this pr was a cherry pick from main entirely?

@bricelam
Copy link
Contributor Author

@AraHaan It includes all the changes in PR #27671 if that's what you're asking...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants