TargetFramework logic insufficient for .NET 5

[sfoslund]

With .NET 5 we are introducing a new style of target framework that includes target platform information (for example, net5.0-windows). This repo contains logic that will break with these new target framework and duplicated target framework logic.

Details:

• https://github.com/dotnet/wcf/blob/master/eng/TargetFramework.props#L5: TargetFrameworkIdentifier and TargetFrameworkVersion properties are defined by the SDK and should be used directly. If that is impossible, these MSBuild functions can be used to parse: Allow TFM/TPM checks in a concise, understandable way msbuild#5171 (comment)
• https://github.com/dotnet/wcf/blob/master/eng/TargetFramework.props#L16: this section seems to be trying to parse target platform information out of the target framework, which is a supported scenario with .NET 5 and will likely conflict with the new default logic.
• https://github.com/dotnet/wcf/blob/master/eng/TargetFramework.props: I don't have context on this file, but there is a lot of code that looks suspicious and likely will break with .NET 5. For example, this condition seems to be looking for platforms in the target framework identifier.
• https://github.com/dotnet/wcf/blob/master/src/dotnet-svcutil/lib/src/Shared/TargetFrameworkHelper.cs: I don't see any issues that jump out in this file, but it should probably be audited by someone who understands the context better. It is also possible that some of the logic here surrounding supported target frameworks is duplicated and could be replaced with NuGet API calls.

[sfoslund]

cc @mconnew

[HongGit]

This is probably fine because WCF has not been updated to .NET 5.0, we are still staying on .NET 3.0.

[Doomblaster]

it definetly doesn't work

Even setting --targetFramework doesn't work

Problem is that it picks the targetframework moniker from csproj file regardless it seems. Doing the same outside of the project works, but something is not right here

[HongGit]

@imcarolwang can you please take a look at this issue?

[akoeplinger]

This also impacts the new .NET6 based Xamarin projects which use net6.0-android and net6.0-ios TFMs.

A workaround is to temporarily change the TFM in the project to net6.0, run dotnet-svcutil and then change it back.

[HongGit]

@imcarolwang, can you please verify whether these new versions are already included?

[imcarolwang]

In PR #4650 we added support of net5.0-* and net6.0-* targets, the code has been merged so the next release of dotnet-svcutil and WCF Connected Service tool should support project types such as net6.0-android , net6.0-ios, net6.0-windows.

[akoeplinger]

@imcarolwang the code hardcodes net5.0 and net6.0 though so it'll break again on net7.0:

wcf/src/dotnet-svcutil/lib/src/Shared/MSBuildProj.cs

Line 163 in 88c3d39

if (tfx.Length > 1 && (tfx[0] == "net5.0" || tfx[0] == "net6.0"))

[imcarolwang]

@imcarolwang the code hardcodes net5.0 and net6.0 though so it'll break again on net7.0:

wcf/src/dotnet-svcutil/lib/src/Shared/MSBuildProj.cs

Line 163 in 88c3d39

if (tfx.Length > 1 && (tfx[0] == "net5.0" || tfx[0] == "net6.0"))

Address in PR #4893 which is under review.

[imcarolwang]

Fix is in and released to dotnet-svcutil version 2.1.0. Closing issue.