Unknown target framework moniker

[AroglDarthu]

MSBuild.Sdk.SqlProj/src/DacpacTool/DacpacTool.csproj

Line 5 in e57fc24

<TargetFrameworks>netcoreapp2.1;netcoreapp3.1;netcoreapp5.0</TargetFrameworks>

netcoreapp5.0 should be net5.0
The test project targets net5.0. In Visual Studio that leads to the error message:

Project '....\src\DacpacTool\DacpacTool.csproj' targets 'netcoreapp2.1;netcoreapp3.1;netcoreapp5.0'. It cannot be referenced by a project that targets '.NETFramework,Version=v5.0'.

[jmezach]

Hmm, I believe that netcoreapp5.0 and net5.0 are actually synonymous. The reason we're using netcoreapp5.0 is because of this check.

I haven't had any problems with it so far to be honest, although I haven't opened the solution in Visual Studio at all. I usually use VS Code which doesn't seem to have any issues with it.

[AroglDarthu]

You could be right in that netcoreapp5.0 can still be used. The error that I got, made me look for it in the docs. The moniker netcoreapp5.0 is no longer official: https://docs.microsoft.com/en-us/dotnet/standard/frameworks

On the bright side: I got the error because of a newer .NET5 SDK and an old(er) version of Visual Studio.

The following line will also need to be changed:

MSBuild.Sdk.SqlProj/src/MSBuild.Sdk.SqlProj/MSBuild.Sdk.SqlProj.csproj

Line 34 in e57fc24

<_DacpacToolSupportedTfms>netcoreapp2.1;netcoreapp3.1;netcoreapp5.0</_DacpacToolSupportedTfms>

And then of course the line you mentioned (and the error message below it) should be altered. I thought $(MicrosoftNETBuildTasksTFM) could be used, but it outputs netstandard2.0 for SDK 2.1.*

[jmezach]

I wonder how long MicrosoftNETBuildTasksTFM has been there. I remember looking for something like that but I wasn't able to find it. I guess we could try changing the logic to depend on that property instead of BundledNETCoreAppTargetFrameworkVersion and then see what CI thinks of that. We already build with different versions of the SDK anyway, so if older versions didn't have it it would probably fail ;).

[AroglDarthu]

I edited my comment above. Turns out SDK 2.1 sets $(MicrosoftNETBuildTasksTFM) to netstandard2.0.
Bummer.

[jmezach]

I guess it is time to drop support for .NET Core 2.1 anyway since it has gone out of support.

[jmezach]

I'm thinking that maybe we should do a 2.0 release in which we drop support for .NET Core 2.1 (since it is out of support) and add support for .NET 6 (since that is now Go Live) and include all of the other changes and include this change as well. For people that are still on .NET Core 2.1 they can stick with version 1.16 for now, but my guess is that most people use at least 3.1 so they can easily upgrade to 2.0.

@jeffrosenberg @ErikEJ What do you think?

[ErikEJ]

Good idea, maybe it should stay as 2.0-preview until 6.0 RTM?

[jmezach]

Yeah, that makes sense.

[jeffrosenberg]

Sounds good to me!

[AroglDarthu]

MSBuild.Sdk.SqlProj/version.json

Line 3 in addbf26

"version": "1.17.0-beta.{height}",

Does the pipeline change this automatically, or can I just replace this with 2.0.0-beta?

[jmezach]

Yeah, that should probably be updated to be 2.0.0-beta.{height}. It is used by the pipeline to calculate the final version number automatically.

[AroglDarthu]

I can get the MSBuild.Sdk.SqlProj itself to build nicely for target framework net6.0.
However, building one of the test projects while using the net6.0 SDK fails with the following message:

  Determining projects to restore...
  All projects are up-to-date for restore.
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
  Using target framework net6.0 to run DacpacTool
  Using package name TestProject and version 1.0.0
  Setting property ServiceBrokerOption to value EnableBroker
  Setting property RecoveryMode to value Simple
  Setting property AllowSnapshotIsolation to value True
  Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
   ---> System.PlatformNotSupportedException: Strong-name signing is not supported on this platform.
     at System.Reflection.AssemblyName.get_KeyPair()
     at Microsoft.Data.Tools.Schema.Extensibility.ExtensionTypeLoader.ExtensionAssemblies.CreateAssemblyName(String partialName, AssemblyName templateName)

The command leading to this exception:

/Sdk.targets(228,5): error MSB3073: The command "dotnet "/Sdk/../tools/net6.0/DacpacTool.dll" build -o "obj/Debug/netstandard2.0/TestProject.dacpac" -n "TestProject" -v "1.0.0" -sv Sql150 -i "obj/Debug/netstandard2.0/TestProject.InputFiles.txt" -p ServiceBrokerOption=EnableBroker -p RecoveryMode=Simple -p AllowSnapshotIsolation=True " exited with code 1.

Adding a global.json to force SDK 5.0.401 resolves the issue, so I find it reasonable to assume that the problem is related to using the current net6.0 SDK.

Any ideas on how to solve this?

[jmezach]

That's an interesting error. I thought .NET Core has never supported strong-name signing, but perhaps they've only started throwing exceptions when trying to use it with .NET 6.

Do we know where this occurs in our code? The TargetInvocationException suggests this is coming from some code that we're calling through reflection. This sounds like an issue in the DacFx assembly, so maybe we can file that here.

[AroglDarthu]

I'm thinking this is the same issue. Looks like it should have been resolved? dotnet/msbuild#6389
🤔 The fix was merged, but I think it will take a while before it gets shipped with the next net6.0 rc?

[AroglDarthu]

I've asked about it here: dotnet/core#6688 (comment)
Let's see what comes back...

[KalleOlaviNiemitalo]

The MSBuild fix dotnet/msbuild#6395 modified only the Microsoft.Build.BackEnd.TranslatorHelpers class, which also appeared in the stack trace in dotnet/msbuild#6389. Because your stack trace does not include that class, I don't think the MSBuild fix can help solve this issue.

[AroglDarthu]

I'm afraid you are correct.

[jmezach]

I really think this is an issue in DacFx and has to be fixed there. Unfortunately that isn't open source yet. But they do have a repo for filing issues here. I'll go ahead and file an issue there.

[jmezach]

See microsoft/DacFx#33

[jmezach]

It seems that the 16.x preview release of DACFX solves that issue, so that's the good news.

Unfortunately it seems that we can't use MicrosoftNETBuildTasksTFM to reliably determine the correct version of DacpacTool to run either since it is set to netcoreapp2.1 even for the .NET 3.1 SDK release (see here) for which we're trying to drop support.

[jmezach]

So I've gone back to using BundledNETCoreAppTargetFrameworkVersion and then special casing .NET Core 3.1 to use netcoreapp as the prefix, while for other versions we use net as the prefix. Since we're dropping support for .NET Core 2.1 I think that'll be fine for now. I guess we could remove it again once 3.1 goes out of support.