47

I have a solution with two host projects (one is a Web Host and the other is a Generic Host) and a class library project referenced by those two host projects.

In the Sdk attribute of the root tag <Project> of the *.csproj file, both host projects (web host and generic host) are using Microsoft.NET.Sdk.Web, but the class library project uses the Microsoft.NET.Sdk.

The two host projects references the Microsoft.AspNetCore.App metapackage.

The class library project are using Microsoft.NETCore.App, but it references some ASP.NET Core packages individually (packages of Microsoft.AspNetCore.App that are not in Microsoft.NETCore.App).

About the correct SDK and metapackages:

1) In the generic host project, should I use pure .NET Core (Microsoft.NET.Sdk and Microsoft.NETCore.App) instead of ASP.NET Core (Microsoft.NET.Sdk.Web and Microsoft.AspNetCore.App) since it is not a web project?

2) In the class library project, is it fine to use Microsoft.NET.Sdk with Microsoft.AspNetCore.App to avoid the possibility to reference different versions of packages that belong to Microsoft.AspNetCore.App (to avoid for example, Microsoft.AspNetCore.App@2.1.0 in the host project and Microsoft.Extensions.Configuration@2.0.0 in the class library project)? Or I can only use Microsoft.AspNetCore.App metapackage with Microsoft.NET.Sdk.Web SDK?

3) What difference does it make to use Microsoft.NET.Sdk or Microsoft.NET.Sdk.Web? The docs says that "The SDK, as the layering document describes, is a set of MSBuild tasks and targets that can build .NET Core code.", but why do we need to have both of them? In practice, what Microsoft.NET.Sdk.Web does that Microsoft.NET.Sdk doesn't?

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
lmcarreiro
  • 5,312
  • 7
  • 36
  • 63
  • The web package is a subpackage of the base SDK. Anything in the regular Sdk should be available to Web applications, but not all applications made with .NET are for the web – OneCricketeer Sep 20 '18 at 23:52
  • 1
    The two comes from two different repos, and all relevant code is available, https://github.com/aspnet/websdk/blob/6b898ad0a39329ab5f0db281a9c1712e4303ed61/pack/Microsoft.NET.Sdk.Web/Microsoft.NET.Sdk.Web.csproj and https://github.com/dotnet/sdk/blob/ab2176b3447e3e7820b5a340408110b6d498f907/src/Tasks/Microsoft.NET.Build.Tasks/Microsoft.NET.Build.Tasks.csproj so you might dig and see if obvious differences can be observed. – Lex Li Sep 21 '18 at 02:22
  • I tried to cover many aspects in my answer but since it is potentially a bit topic, I suggest following up on or moving parts out to new (and more specific) questions – Martin Ullrich Sep 22 '18 at 11:38

1 Answers1

51

Ad (1) and (3): What are the differences between the "core" and and web SDKs, how do these affect generic host apps?

The most important differences are:

  1. Default Items

    The web SDK has different definitions and globbing patterns for which files to include in your published application.

    E.g. when you have an appsettings.json file, projects using the web sdk will automatically include it since there are patterns in place that ensure that .config, .json files and all files in a wwwroot folder are all part of the publish output. See the MSBuild source code on GitHub for these patterns.

    If you have a generic host and don't use the Web SDK, you may need to add code to the csproj file to specify which files to copy to the publish directory (or use an IDE to change the "copy to output directory" setting which also includes files in the publish output but will also copy them to the build output):

    <ItemGroup>
  <None Update="*.json" CopyToPublishDirectory="PreserveNewest" />
</ItemGroup>

  2. Web Publish logic

    Another essential part of the Web SDK is that it contains the deployment logic for web applications.

    If you plan to use publish profiles (.pubxml files) or deploy to azure or filesystems using MSBuild / MSDeploy, you will need this publishing logic.

Ad (2): Which SDK to use for class libraries?

For maximum compatibility when publishing public libraries (e.g. via NuGet), use the core SDK and reference individual packages with the lowest possible version - e.g. 2.1.0 / 2.1.1.

If you develop a class library containing razor views, you will need to use the Microsoft.NET.Sdk.Razor SDK to get razor tooling (e.g. when you use the dotnet new razorclasslib template).

For libraries and test projects where you want to use the same meta package reference as the application, things are a bit complicated at the moment but it's going to get better:

For ASP.NET Core 2.1 tools(!) (CLI 2.1.*), I suggest using the non-web SDK for class libraries and use the version 2.1.1 of that package. Don't ever upgrade it, even if NuGet offers you an upgrade.

For test projects in 2.1 tools(!) (CLI 2.1.*), it is a bit different and tricky, see Integration and unit tests no longer work on ASP.NET Core 2.1 failing to find assemblies at runtime

Beginning in 2.2 tools (CLI 2.2.100+), the version-less package references to ASP.NET Core metapackages are moved to the core SDK so you can develop libraries and test projects for both ASP.NET Core 2.1 and 2.2 using the ""core"" SDK (provided you use tools 2.2.100+) using version-less package references:

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

In .NET Core / ASP.NET Core 3.0, you will be able to reference the framework via a new mechanism altogether (no web-SDK needed):

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
poke
  • 369,085
  • 72
  • 557
  • 602
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217