0

I have a something.csproj project like this:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Data.SqlClient" Version="4.1.0" />
  </ItemGroup>

</Project>

and a something.cs program like this:

using System;
using System.IO;
using System.Data.SqlClient;

namespace SomethingNS
{
    public class Something
    {
       public static void Main()
       {
           var a = new SqlCommand();
       }
    }
}

Using dotnet 2.0, I execute:

dotnet publish

But I don't see the System.Data.SqlClient.dll at folder \bin\Debug\netcoreapp1.0\publish\System.Data.SqlClient.dll?

Why is that?

Michael J Swart
  • 3,060
  • 3
  • 29
  • 46
  • If I use `Version="4.4.0"` instead of `Version="4.1.0"`, it does show up there – Michael J Swart Aug 16 '17 at 15:01
  • WAG, but check your GAC to see if you have 4.1.0 installed. –  Aug 16 '17 at 15:02
  • I don't see any version of that dll in `C:\Windows\assembly`. (That's where I look in the GAC right?) But I do see different versions in `%userprofile%\.nuget\packages\system.data.sqlclient` – Michael J Swart Aug 16 '17 at 15:10
  • 1
    Welp, if you searched the entire GAC and didn't find it installed, then my AG was a bit too W. Good luck. –  Aug 16 '17 at 15:13
  • 2
    @Will .NET Core applications do not use the GAC. – Martin Ullrich Aug 16 '17 at 15:23
  • Bah, you kids with your net core and the hippety hoppety –  Aug 16 '17 at 16:01
  • dotnet v2 finally acquired the new `--self-contained` option, necessary if you also want the whole ball of wax that includes the entire runtime. It is getting closer to actually being usable. – Hans Passant Aug 16 '17 at 16:02
  • side note: '\bin\Debug\netcoreapp1.0\...' means .Net Core 2 not being used. by default it should be '\bin\Debug\netcoreapp2.0\' – Jawad Al Shaikh Aug 16 '17 at 16:50

1 Answers1

5

The reason is that the .NET Core implementation of System.Data.SqlClient is different on windows and unix and thus makes use of .NET Core's ability to load the specific library needed.

You published a "portable" application, that is able to run on windows, linux, macOS etc. and the appropriate libraries will be loaded from e.g. the runtimes/unix/lib/netstandard1.3/System.Data.SqlClient.dll or runtimes/win/lib/netstandard1.3/System.Data.SqlClient.dll. There are a few other platform-specific assets as well (a managed System.IO.Pipes.dll for unix and two native sni.dll files for 32 and 64 bit windows).

This is the reason there is no System.Data.SqlClient.dll in the root level of your publish output. There should be variants inside the bin\Debug\netcoreapp1.0\publish\runtimes subfolder.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • Thanks Marin, I understand now – Michael J Swart Aug 16 '17 at 16:02
  • Well explained Martin, thanks! I was struggling with this today. I was confused why my deployment package was so big, and it turned out to be because of the runtimes folder. I tried setting the --runtime win-x64 param when doing dotnet publish, expecting it to then not include the libs for the other runtimes, but it ended up creating a publish directory over 90MB! After research, it looks like supplying the runtime turns it into a SCD - hence the size of the published app. Is there any way to specify the runtime such that it's not a SCD, and that it doesn't include all of the runtimes? – Tophat Gordon Aug 07 '18 at 19:24
  • @Tophat, to publish a dotnet core that is not SCD and does not include all the runtimes please see the parameters that I used in this post: https://stackoverflow.com/questions/56959856/net-core-3-0-nuget-dlls/57011227#57011227 – Yogi Jul 19 '19 at 20:32