Teilen über

MSBuild-Breaking Changes in .NET Core 2.1 bis 3.1

  • Artikel

Auf dieser Seite sind die folgenden Breaking Changes dokumentiert:

Unterbrechende Änderung Eingeführt in Version
Entwurfszeitbuilds geben nur allgemeine Paketverweise zurück 3.1
Änderung des Manifestdateinamens der Ressource 3.0
Projekttools, die jetzt im SDK enthalten sind 2.1

.NET Core 3.1

Entwurfszeitbuilds geben nur allgemeine Paketverweise zurück

Ab .NET Core SDK 3.1.400 werden vom RunResolvePackageDependencies-Ziel nur Verweise auf Pakete der obersten Ebene zurückgegeben.

Eingeführt in Version

.NET Core SDK 3.1.400

Änderungsbeschreibung

In früheren Versionen des .NET Core SDK erstellte das RunResolvePackageDependencies-Ziel die folgenden MSBuild-Elemente, die Informationen aus der NuGet-Ressourcendatei enthielten:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Mit diesen Daten füllt Visual Studio den Knoten „Abhängigkeiten“ im Projektmappen-Explorer auf. Es kann sich dabei jedoch um eine große Menge von Daten handeln, die nur benötigt werden, wenn der Knoten „Abhängigkeiten“ aufgeklappt wird.

Ab Version 3.1.400 des .NET Core SDK werden die meisten dieser Elemente nicht standardmäßig generiert. Nur Elemente vom Typ Package werden zurückgegeben. Wenn Visual Studio die Elemente zum Auffüllen des Knotens „Abhängigkeiten“ benötigt, liest Visual Studio die betreffenden Informationen direkt aus der Ressourcendatei.

Grund für die Änderung

Diese Änderung wurde eingeführt, um die Leistung beim Laden von Projektmappen in Visual Studio zu verbessern. Zuvor wurden alle Paketverweise geladen, darunter viele, die von den meisten Benutzern nie angezeigt wurden.

Wenn Sie über eine MSBuild-Logik verfügen, die von der Erstellung dieser Elemente abhängt, legen Sie die Eigenschaft EmitLegacyAssetsFileItems in Ihrer Projektdatei auf true fest. Mit dieser Einstellung aktivieren Sie das vorherige Verhalten, bei dem alle Elemente erstellt werden.

Kategorie

MSBuild

Betroffene APIs

Nicht zutreffend

.NET Core 3.0

Änderung des Manifestdateinamens der Ressource

Ab .NET Core 3.0 generiert MSBuild im Standardfall einen anderen Manifestdateinamen für Ressourcendateien.

Eingeführt in Version

3.0

Änderungsbeschreibung

Vor .NET Core 3.0 hat MSBuild im Muster <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources einen Manifestdateinamen generiert, wenn für ein EmbeddedResource-Element in der Projektdatei nicht LogicalName-, ManifestResourceName- oder DependentUpon-Metadaten angegeben wurden. Wenn RootNamespace nicht in der Projektdatei definiert ist, wird standardmäßig der Projektname verwendet. Beispielsweise lautete der Name des generierten Manifests für eine Ressourcendatei mit dem Namen Form1.resx im Stammverzeichnis des Projekts MyProject.Form1.resources.

Ab .NET Core 3.0 verwendet MSBuild Typinformationen aus der Quelldatei, wenn eine Ressourcendatei mit einer Quelldatei desselben Namens (z. B. Form1.resx und Form1.cs) angeordnet wird, um den Manifestdateinamen im Muster <Namespace>.<ClassName>.resources zu generieren. Der Namespace- und Klassenname werden aus dem ersten Typ in der angeordneten Quelldatei extrahiert. Beispielsweise lautet der generierte Manifestname für eine Ressourcendatei mit dem Namen Form1.resx, die mit einer Quelldatei mit dem Namen Form1.cs angeordnet wird, MyNamespace.Form1.resources. Wichtig ist zu beachten, dass der erste Teil des Dateinamens sich von früheren Versionen von .NET Core unterscheidet (MyNamespace anstelle von MyProject).

Hinweis

Wenn LogicalName-, ManifestResourceName- oder DependentUpon-Metadaten für ein EmbeddedResource-Element in der Projektdatei angegeben sind, wirkt sich diese Änderung nicht auf diese Ressourcendatei aus.

Dieser Breaking Change wurde mit dem Hinzufügen der EmbeddedResourceUseDependentUponConvention-Eigenschaft zu .NET Core-Projekten eingeführt. Standardmäßig werden Ressourcendateien nicht explizit in einer .NET Core-Projektdatei aufgelistet, sodass Ihnen keine DependentUpon-Metadaten zur Verfügung stehen, um anzugeben, wie die generierte RESOURCES-Datei benannt werden soll. Wenn EmbeddedResourceUseDependentUponConvention dem Standard entsprechend auf true festgelegt ist, sucht MSBuild nach einer angeordneten Quelldatei und extrahiert einen Namespace- und Klassennamen aus dieser Datei. Wenn Sie EmbeddedResourceUseDependentUponConvention auf false festlegen, generiert MSBuild den Namen des Manifests gemäß dem vorherigen Verhalten, wobei RootNamespace und der relative Dateipfad kombiniert werden.

In den meisten Fällen ist keine Aktion seitens des Entwicklers erforderlich, und Ihre App sollte weiterhin funktionieren. Wenn diese Änderung jedoch Ihre App beeinträchtigt, haben Sie folgende Möglichkeiten:

  • Ändern Sie den Code so, dass er den neuen Manifestnamen erwartet.

  • Um die neue Namenskonvention zu umgehen, legen Sie in Ihrer Projektdatei EmbeddedResourceUseDependentUponConvention auf false fest.

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

Kategorie

MSBuild

Betroffene APIs

Nicht zutreffend

.NET Core 2.1

Jetzt im SDK enthaltene Projekttools

Das SDK für .NET Core 2.1 enthält nun gängige CLI-Tools, auf die nun nicht mehr im Projekt verwiesen werden muss.

Änderungsbeschreibung

In .NET Core 2.0 verweisen Projekte mit der Projekteinstellung <DotNetCliToolReference> auf externe .NET-Tools. In .NET Core 2.1 sind einige dieser Tools im .NET Core SDK enthalten, weshalb die Einstellung nicht mehr erforderlich ist. Wenn Sie Verweise auf diese Tools in Ihr Projekt aufnehmen, erhalten Sie eine Fehlermeldung ähnlich der folgenden: Das Tool "Microsoft.EntityFrameworkCore.Tools.DotNet" ist jetzt im .NET Core SDK enthalten.

Tools, die jetzt im SDK für .NET Core 2.1 enthalten sind:

Wert <DotNetCliToolReference> Tool
Microsoft.DotNet.Watcher.Tools dotnet-watch
Microsoft.Extensions.SecretManager.Tools dotnet-user-secrets
Microsoft.Extensions.Caching.SqlConfig.Tools dotnet-sql-cache
Microsoft.EntityFrameworkCore.Tools.DotNet dotnet-ef

Eingeführt in Version

.NET Core SDK 2.1.300

Entfernen Sie die Einstellung <DotNetCliToolReference> aus Ihrem Projekt.

Kategorie

MSBuild

Betroffene APIs

–