Changements cassants MSBuild dans .NET Core 2.1 - 3.1

Les modifications cassantes suivantes sont documentées sur cette page :

.NET Core 3.1

Les builds design-time retournent uniquement les références de package de niveau supérieur

À compter du Kit de développement logiciel (SDK) .NET Core 3.1.400, seules les références de package de niveau supérieur sont retournées par la cible RunResolvePackageDependencies.

Version introduite

SDK .NET Core 3.1.400

Description de la modification

Dans les versions précédentes du Kit de développement logiciel (SDK) .NET Core, la cible RunResolvePackageDependencies créait les éléments MSBuild suivants qui contenaient des informations du fichier de ressources NuGet :

• PackageDefinitions
• PackageDependencies
• TargetDefinitions
• FileDefinitions
• FileDependencies

Ces données sont utilisées par Visual Studio pour remplir le nœud Dépendances dans l’Explorateur de solutions. Toutefois, il peut s’agir d’une grande quantité de données et les données ne sont pas nécessaires, sauf si le nœud Dépendances est développé.

À compter du Kit de développement logiciel (SDK) .NET Core version 3.1.400, la plupart de ces éléments ne sont pas générés par défaut. Seuls les éléments de type Package sont retournés. Si Visual Studio a besoin des éléments pour remplir le nœud Dépendances, il lit les informations directement à partir du fichier de ressources.

Raison du changement

Cette modification a été introduite pour améliorer les performances de chargement de solution à l’intérieur de Visual Studio. Auparavant, toutes les références de package étaient chargées, ce qui impliquait le chargement de nombreuses références que la plupart des utilisateurs n’afficheraient jamais.

Action recommandée

Si vous avez une logique MSBuild qui dépend de ces éléments créés, définissez la propriété EmitLegacyAssetsFileItems sur true dans votre fichier projet. Ce paramètre active le comportement précédent dans lequel tous les éléments sont créés.

Category

MSBuild

API affectées

N/A

.NET Core 3.0

Modification du nom du fichier manifeste de ressource

À compter de .NET Core 3.0, par défaut, MSBuild génère un autre nom de fichier manifeste pour les fichiers de ressources.

Version introduite

3.0

Description de la modification

Avant .NET Core 3.0, si aucune métadonnées LogicalName, ManifestResourceName ou DependentUpon avaient été spécifiées pour un élément EmbeddedResource dans le fichier projet, MSBuild générait un nom de fichier manifeste dans le modèle <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Si RootNamespace n’est pas défini dans le fichier projet, il est défini par défaut sur le nom du projet. Par exemple, le nom du manifeste généré pour un fichier de ressources nommé Form1.resx dans le répertoire du projet racine était MyProject.Form1.resources.

À compter de .NET Core 3.0, si un fichier de ressources est colocalisé avec un fichier source du même nom (par exemple, Form1.resx et Form1.cs), MSBuild utilise des informations type du fichier source pour générer le nom du fichier manifeste dans le modèle<Namespace>.<ClassName>.resources. L’espace de noms et le nom de classe sont extraits du premier type dans le fichier source colocalisé. Par exemple, le nom du manifeste généré pour un fichier de ressources nommé Form1.resx colocalisé avec un fichier source nommé Form1.cs est MyNamespace.Form1.resources. La principale chose à noter est que la première partie du nom de fichier est différente des versions antérieures de .NET Core (MyNamespace au lieu de MyProject).

Ce changement cassant a été introduit avec l’ajout de la propriété EmbeddedResourceUseDependentUponConvention aux projets .NET Core. Par défaut, les fichiers de ressources ne sont pas répertoriés explicitement dans un fichier projet .NET Core. Ils n’ont donc aucune métadonnées DependentUpon pour spécifier comment nommer le fichier .resources généré. Quand EmbeddedResourceUseDependentUponConvention est défini sur true, qui est la valeur par défaut, MSBuild recherche un fichier source colocalisé et extrait un espace de noms et un nom de classe à partir de ce fichier. Si vous définissez EmbeddedResourceUseDependentUponConvention sur false, MSBuild génère le nom du manifeste en fonction du comportement précédent, qui combine RootNamespace et le chemin du fichier relatif.

Action recommandée

Dans la plupart des cas, aucune action n’est requise de la part du développeur et votre application devrait continuer à fonctionner. Toutefois, si ce changement arrête votre application, vous pouvez :

• Modifier votre code pour avoir un nouveau nom de manifeste.

• Refuser la nouvelle convention d’affectation de noms en définissant EmbeddedResourceUseDependentUponConvention sur false dans votre fichier projet.

  <PropertyGroup>
    <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
  </PropertyGroup>
  

Category

MSBuild

API affectées

N/A

.NET Core 2.1

Outils de projet désormais inclus dans le Kit de développement logiciel (SDK)

Le kit SDK .NET Core 2.1 inclut désormais des outils CLI courants, et vous n’avez plus besoin de référencer ces outils à partir du projet.

Description de la modification

Dans .NET Core 2.0, les projets référencent des outils .NET externes avec le paramètre de projet <DotNetCliToolReference>. Dans .NET Core 2.1, certains de ces outils sont inclus dans le kit SDK .NET Core et le paramètre n’est plus nécessaire. Si vous incluez des références à ces outils dans votre projet, vous recevez une erreur de ce type : L’outil « Microsoft.EntityFrameworkCore.Tools.DotNet » est désormais inclus dans le kit SDK .NET Core.

Outils désormais inclus dans le kit SDK .NET Core 2.1 :

Version introduite

SDK .NET Core 2.1.300

Action recommandée

Supprimez le paramètre <DotNetCliToolReference> dans votre projet.

Category

MSBuild

API affectées

N/A