[release/3.1] Fix dotnet-ef RuntimeFrameworkVersion

[bricelam]

Description

The dotnet-ef global tool was built incorrectly:

• dotnet-ef 3.1.2 depends on runtime 3.1.2
• This fails on any machine with just 3.1 on it. This includes when the web tools try to load dotnet-ef from within VS.
• It should depend on 3.1.0

Customer Impact

This will break common VS scenarios as well as people who install the latest tool on the command line.

How found

CTI validation using VS following the patch release, and also customer-reported on the command line.

Test coverage

We have done manual validation on the new PR and will validate again once it is in the build.

Going forward we need to make sure that we can reproduce this in the CTI validation before the new packages are pushed to NuGet.

Also, since we knew about this before and thought it was fixed we will investigate what happened in the process that allowed this.

Regression?

Yes, from 3.0.

Risk

Low.

---

We had some dead code in the project files: (I'm not exactly sure what happened, but it looks like it broke while migrating to Arcade.)

<!--
    This keeps dotnet-ef targeting the default version of .NET Core for netcoreapp3.1,
    which maximizes the machines on which this tool will be compatible.
-->
<TargetLatestDotNetRuntime Condition=" '$(IsServicingBuild)' == 'true' ">false</TargetLatestDotNetRuntime>

Fixes errors like:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '3.1.2' was not found.

Verification:

Installed a local 3.1.3 build of dotnet-ef with only runtime 3.1.1 available and it worked where dotnet-ef 3.1.2 failed. Also verified that the runtimeconfig contains 3.1.0 instead of the latest patch version.

Fixes #20005

[wtgodbe]

Change looks reasonable, but could you add a description of why it's needed? Do we need to take this for 3.1.3 (the march release)?

[bricelam]

(Description updated)

[ajcvickers]

@bricelam What validation have we done? What should we do to make sure it works once it is merged?

@Pilchie We should try to get this in to the next shipping patch. I can send a request to Tactics if that's the best way to go here.

[bricelam]

Verification: Installed a local 3.1.3 build of dotnet-ef with only runtime 3.1.1 available and it worked where dotnet-ef 3.1.2 failed. Also verified that the runtimeconfig contains 3.1.0 instead of the latest patch version.

[wtgodbe]

If we merge this today it shouldn't affect our ability to get a 3.1.3 build by tomorrow. Tell-mode should be fine since this is an infrastructure change, but let's still wait for @Pilchie's signoff

[Pilchie]

I don't totally understand the fix, but I'm supportive of the scenario. I think we should still email Tactics, since this was an issue we discussed today.

One thing we could consider is publishing this package earlier than the full 3.1.3 release too.

[ajcvickers]

I'll send email to tactics and we'll get this in for 3.1.3 today.

@Pilchie If an earlier train arrives, then we should hop on it.

[bricelam]

Similar code existed before the move to Arcade:

efcore/version.props

Line 38 in 2f07f47

<IsServicingBuild Condition=" '$(PreReleaseLabel)' == 'servicing' ">true</IsServicingBuild>

efcore/Directory.Build.targets

Lines 2 to 6 in 2f07f47

	<PropertyGroup Condition=" '$(TargetLatestDotNetRuntime)' != 'false' ">
	<!-- Assign these values at the end of the project after TargetFramework has been assigned. TargetFramework is not assigned yet in Directory.Build.props. -->
	<RuntimeFrameworkVersion Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">$(MicrosoftNETCoreApp20PackageVersion)</RuntimeFrameworkVersion>
	<RuntimeFrameworkVersion Condition=" '$(TargetFramework)' == 'netcoreapp3.0' ">$(MicrosoftNETCoreAppPackageVersion)</RuntimeFrameworkVersion>
	</PropertyGroup>

[bricelam]

I'd like to clean this up more in master--just doing the minimal thing for patches

[ajcvickers]

This is approved for 3.1.3 by tactics.

@bricelam Let's get this merged today. Also can you file an issue (or use an existing one) so we can have an issue tracking this in 3.1.3.