web-dev-qa-db-fra.com

Quelles sont les différences entre Microsoft.NET.Sdk et Microsoft.NET.Sdk.Web

J'ai une solution avec deux projets Host (l'un est un Web Host et l'autre est Generic Host ) et un projet de bibliothèque de classe référencé par ces deux projets Host.

Dans l'attribut Sdk de la balise racine <Project> du fichier * .csproj, les deux projets Host (hôte Web et hôte générique) utilisent Microsoft.NET.Sdk.Web, mais le projet de bibliothèque de classes utilise le Microsoft.NET.Sdk.

Les deux projets Host font référence au Microsoft.AspNetCore.App métapaquet.

Le projet de bibliothèque de classes utilise Microsoft.NETCore.App, mais il fait référence à certains packages ASP.NET Core individuellement (packages de Microsoft.AspNetCore.App qui ne sont pas dans Microsoft.NETCore.App).

À propos du SDK et des métapaquets appropriés:

1) Dans le projet hôte générique, dois-je utiliser pure . NET Core (Microsoft.NET.Sdk et Microsoft.NETCore.App) au lieu de ASP.NET Core (Microsoft.NET.Sdk.Web et Microsoft.AspNetCore.App) puisqu'il ne s'agit pas d'un projet web?

2) Dans le projet de bibliothèque de classes, est-il correct d'utiliser Microsoft.NET.Sdk avec Microsoft.AspNetCore.App pour éviter la possibilité de référencer différentes versions de packages appartenant à Microsoft.AspNetCore.App (pour éviter par exemple, [email protected] dans le projet Host et [email protected] dans le projet de bibliothèque de classes)? Ou je ne peux utiliser que Microsoft.AspNetCore.App métapaquet avec Microsoft.NET.Sdk.Web SDK?

3) Quelle différence cela fait-il d'utiliser Microsoft.NET.Sdk ou Microsoft.NET.Sdk.Web? Le docs dit que "Le SDK, comme le décrit le document de superposition, est un ensemble de tâches et de cibles MSBuild qui peuvent créer du code .NET Core." , mais pourquoi avons-nous besoin des deux? En pratique, ce que Microsoft.NET.Sdk.Web est-ce que Microsoft.NET.Sdk non?

c#.netmsbuild.net-core
19
lmcarreiro

Ad (1) et (3): Quelles sont les différences entre le "noyau" et les SDK Web, comment cela affecte-t-il les applications hôtes génériques?

Les différences les plus importantes sont:

  1. Éléments par défaut

    Le SDK Web a différentes définitions et modèles de globalisation pour les fichiers à inclure dans votre application publiée.

    Par exemple. quand vous avez un appsettings.json, les projets utilisant le Web SDK l'incluront automatiquement car il existe des modèles qui garantissent que .config, .json les fichiers et tous les fichiers d'un dossier wwwroot font tous partie de la sortie de publication. Voir le code source MSBuild sur GitHub pour ces modèles .

    Si vous disposez d'un hôte générique et que vous n'utilisez pas le SDK Web, vous devrez peut-être ajouter du code au fichier csproj pour spécifier les fichiers à copier dans le répertoire de publication (ou utiliser un IDE to modifiez le paramètre "copier dans le répertoire de sortie" qui inclut également les fichiers dans la sortie de publication mais les copiera également dans la sortie de génération):

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

  2. Logique de publication Web

    Une autre partie essentielle du SDK Web est qu'il contient la logique de déploiement des applications Web.

    Si vous prévoyez d'utiliser des profils de publication (.pubxml fichiers) ou déployer vers Azure ou des systèmes de fichiers à l'aide de MSBuild/MSDeploy, vous aurez besoin de cette logique de publication.

Ad (2): Quel SDK utiliser pour les bibliothèques de classes?

Pour une compatibilité maximale lors de la publication de bibliothèques publiques (par exemple via NuGet), utilisez le SDK de base et référencez les packages individuels avec la version la plus basse possible - par exemple 2.1.0/2.1.1.

Si vous développez une bibliothèque de classes contenant des vues de rasoir, vous devrez utiliser le Microsoft.NET.Sdk.Razor SDK pour obtenir des outils de rasage (par exemple, lorsque vous utilisez le dotnet new razorclasslib modèle).

Pour les bibliothèques et les projets de test où vous souhaitez utiliser la même référence de méta-package que l'application, les choses sont un peu compliquées pour le moment mais ça va s'améliorer:

Pour les outils ASP.NET Core 2.1 (!) (CLI 2.1. *), Je suggère d'utiliser le SDK non Web pour les bibliothèques de classes et d'utiliser la version 2.1.1 de ce package. Ne le mettez jamais à niveau, même si NuGet vous propose une mise à niveau.

Pour les projets de test dans les outils 2.1 (!) (CLI 2.1. *), C'est un peu différent et délicat, voir L'intégration et les tests unitaires ne fonctionnent plus sur ASP.NET Core 2.1 à défaut de trouver des assemblys au moment de l'exécution =

À partir des outils 2.2 (CLI 2.2.100+), les références de package sans version aux métapaquets ASP.NET Core sont déplacées vers le SDK principal afin que vous puissiez développer des bibliothèques et tester des projets pour ASP.NET Core 2.1 et 2.2 à l'aide de la " SDK "core" "(à condition d'utiliser les outils 2.2.100+) utilisant des références de package sans version:

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

Dans .NET Core/ASP.NET Core 3.0, vous pourrez référencer le framework via un nouveau mécanisme (aucun web-SDK nécessaire):

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
24
Martin Ullrich