12

We have a simple netcore 2.2 console application using DbContext from Microsoft.EntityFrameworkCore. When launched from console as is it works as expected.

However we decided to utilize it as a dotnet CLI tool. It's .csproj file contains:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AssemblyName>dotnet-dbupdate</AssemblyName>
    <Title>Db Updater</Title>
    <Version>1.0.1</Version>
    <PackageId>DbUpdater</PackageId>
    <Product>DbUpdater</Product>
    <PackageVersion>1.0.1</PackageVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
  </ItemGroup>
</Project>

We pack it to our Nuget server with dotnet pack. Then in a target folder we've got the following .csproj file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="DbUpdater" Version="1.0.1" />
  </ItemGroup>
</Project>

From this folder we restore it and exec:

dotnet restore
dotnet dbupdate

And suddenly, on DbSet's ToList method invocation we receive:

System.Data.SqlClient is not supported on this platform

Definetely there is an issue with launching it as a dotnet CLI tool. However yet we failed to get what this issue is and how to solve it. Searching on the web did not give us any ideas what to try.

horgh
  • 17,918
  • 22
  • 68
  • 123
  • Does the code run ok before you package it up? I.e if you run `dotnet run` in your source directory or hit Run in your IDE – Jamie Taylor May 22 '19 at 13:39
  • In the very beginning of this post I wrote: "When launched from console as is it works as expected." – horgh May 22 '19 at 13:41
  • Ah yes. Apologies – Jamie Taylor May 22 '19 at 15:20
  • adding the reference of the entire entityfw beside SqlServer one solve something? `` – Legion May 27 '19 at 16:02
  • @Legion, unfortunately it does not. – horgh May 27 '19 at 23:38
  • It is not very obvious why you want to do this with the CLI tooling. Unless you changed the platform, you're likely to get this exception on one of the Unixes. – Hans Passant May 28 '19 at 00:59
  • Looking at the dependencies you need both of that: `Dependencies: Microsoft.EntityFrameworkCore.Relational ; System.Data.SqlClient; ` try to include that in your project and see if the problem persist. – Legion May 28 '19 at 08:59
  • @HansPassant it's all on Windows. This application is supposed to apply sql scripts to a database and we wanted to call it with the dotnet cli interface. It is also convinient when running powershell script in a CI build step. – horgh May 28 '19 at 15:25
  • This may be stupid, but try removing Exe from your project. I had issues with that once. – Shak Ham May 28 '19 at 16:33
  • @ShakHam per the docs it should be Exe; and without OutputType the application is not even launched via dotnet cli command. – horgh May 29 '19 at 01:05
  • What if you pack it specifying the framework? dotnet pack -p:TargetFrameworks=netcoreapp2.2 – Shak Ham May 29 '19 at 01:40
  • @ShakHam I tried your suggestion, however it did not change anything either. Besides TargetFramework is specified .csproj file, why would dotnet pack ignore it... – horgh May 29 '19 at 04:10
  • @horgh version `2.0.0` of Microsoft.EntityFrameworkCore.SqlServer is almost 2 years old and depends on an equally old version of Microsoft.Data.SqlClient that targeted .NET Core 2.0, a short-term version that went out of support 2 years ago. Versioning was a big mess back then (to say the least). The LTS version is .NET Core 2.1. Your application targets .NET Core 2.2. You should probably use the matching EF Core version just to avoid such incompatibilities – Panagiotis Kanavos May 29 '19 at 11:35
  • @horgh another option is to update only SqlClient to the latest stable version. – Panagiotis Kanavos May 29 '19 at 11:37
  • What do you get when running `dotnet --list-runtimes` i.e. do you have multiple versions of .NET Core installed? I am thinking of some incompatibility between the preferred version of the CLI and the one of your project. – Siavas May 29 '19 at 15:11
  • @PanagiotisKanavos I actually downgraded to version 2.0 because found somewhere on the internet an idea that it may work on older versions. It does not work neither with the latest stable version (2.2.4) nor with the available preview versions. And it's always one and the same error. – horgh May 29 '19 at 15:53
  • @Siavas `dotnet --list-runtimes` output is: https://monosnap.com/file/erFa40zaMMOXXN6cNTuCZI2sgHoi8o – horgh May 29 '19 at 15:55
  • @horgh `found somewhere on the internet` is not a valid reason to downgrade and actually makes it *harder* for people to help – Panagiotis Kanavos May 30 '19 at 06:28
  • @PanagiotisKanavos it was this thread: https://entityframeworkcore.com/knowledge-base/49355530/system-data-sqlclient-is-not-supported-on-this-platform – horgh May 30 '19 at 08:42
  • i have challenged an error very close to this and below has resolved my problem! *Could you share a minimal project on github? – Hamit YILDIRIM Jun 03 '19 at 14:45

6 Answers6

0

Try to specify the .NET version to use for CLI:

dotnet dbupdate --fx-version 2.2.4

If the above does not work, also try with the other version you have installed (2.2.2).

In essence the version of .NET used to run from CLI, the target SDK of the console app and the package versions of the dependencies all have to match for incompatibility issues to be avoided.

Siavas
  • 4,992
  • 2
  • 23
  • 33
  • @horgh is there any chance you could upload a repro to GitHub so that we can take a look from there? – Siavas Jun 01 '19 at 10:46
0

Just added compatibility v2 to local.settings.json:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "FUNCTIONS_V2_COMPATIBILITY_MODE": "true"
  }
}
Yefry López
  • 1
  • 1
0

I have come across the same issue, this is happening because of the wrong version of System.Data.SqlClient is used, in my case application is built with .NET 4.6 and the class library in .Net Standard 2.0 which has a dependency on System.Data.SqlClient. The issue is resolved after replacing the appropriate version of System.Data.SqlClient(.NET 4.6 in my case) in the production environment.

Naga
  • 2,368
  • 3
  • 23
  • 33
0

If you want to run it on Linux OS just make sure to publish your solution using the correct Target Runtime. For example pick linux-x64 if you want to run it on Red Hat Enterprise Linux.

Michel El Hajj
  • 184
  • 3
  • 13
-1

Note that the ToList() method fires the SQL command, say, the first time which he uses the corresponding DLL. So, simply your error says that There's a dependency mismatch for Microsoft.EntityFrameworkCore.SqlServer or System.Data.SqlClient, you know that the second one is a dependency for the first one. There are some dependencies for the second one too, however I think your problem doesn't come from it.

Check out default references (versions) after packing and try to change to a suitable one. Unfortunately, We can't reproduce your problem, so try this solution and let us know the result.

Edit

According to dotnet-pack documentation :

NuGet dependencies of the packed project are added to the .nuspec file, so they're properly resolved when the package is installed. Project-to-project references aren't packaged inside the project. Currently, you must have a package per project if you have project-to-project dependencies.

Web projects aren't packable by default. To override the default behavior, add the <IsPackable>true</IsPackable> property (inside <PropertyGroup>) to your .csproj file.

I think you need to include the following inside your .csproj file :

<ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="2.0.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.4.0"/>
</ItemGroup>

Also, no more need to use dotnet restore based on the following from the dotnet-pack documentation :

Starting with .NET Core 2.0, you don't have to run dotnet restore because it's run implicitly by all commands, such as dotnet build and dotnet run, that require a restore to occur. It's still a valid command in certain scenarios where doing an explicit restore makes sense.

Amirhossein Mehrvarzi
  • 18,024
  • 7
  • 45
  • 70
  • Could you, please, describe in detail how we can check out default references after packing? – horgh May 28 '19 at 15:20
  • @horgh check useful guides in https://github.com/dotnet/corefx/issues/34580 like `dotnet --info` command and some other guides. I believe in mismatch. – Amirhossein Mehrvarzi May 28 '19 at 19:30
  • The thread you referenced is talking about problems with launching an application on a different server. However in my case the problem is on the same machine. I compile and run the application without any problem on one machine, and run into this problem when launching the application as a dotnet cli tool on this very machine. – horgh May 29 '19 at 01:11
  • @horgh I know, And I mean a reference change after packing out of your sight. Note that .net may obtain the references from anywhere he prefers, not where you want, or where addressed first time, unless you assert that before packing with some ways like **copy locally** or changing a configuration. So the only way is to point the right reference for a successful `dotnet` command again. – Amirhossein Mehrvarzi May 29 '19 at 01:45
  • So could you please tell me the right way to explicitly specify the necessary packages before packing, so that they are not overriden after dotnet pack? – horgh May 29 '19 at 04:05
  • @horgh Please see my edition wish to solve the problem. – Amirhossein Mehrvarzi May 29 '19 at 14:56
  • Adding PackageReferences did not change anything unfortunately. – horgh May 29 '19 at 15:51
-1

If you are developing a project with Asp.net core 2.2 to pay attention to the following issues

The compiler cannot move the dll files to the destination folder when you change the target project settings (launch settings to cli) or type (as class lib to standard lib) or deleted some dipendecies from nuget section. (Compiler bug and microsoft corrected this in vs 2019 last 2 revision) You can try to move it manually but it's not guaranteed. Downgrading maybe a resulation in this case.

Asp.net framework core compiler looks primarily at the project file and other referenced modules take less priority. dotnet restore and dotnet update could'nt provide the settings as according our changes. For example if you remove a package and made a -dotnet restore command, after look to the nuget dependecy part of the visual studio. They maybe still there. For this reason, you try to place the Microsoft.EntityFrameworkCore.SqlServer to the final file of the final project.

solution with above

Self Contained application. In this case, if you are using a DLL related to another application (such as a SQLBase driver), or you can put other nuget dependencies to your application by isolating these DLLs. This gives you the flexibility to work from other resources in the system. In your case you should do this for Microsoft.EntityFrameworkCore.SqlServer

<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>

Please write comment if you dont agree

Hamit YILDIRIM
  • 4,224
  • 1
  • 32
  • 35