Dela via

MSBuild-icke-bakåtkompatibla ändringar i .NET Core 2.1– 3.1

  • Artikel

Följande icke-bakåtkompatibla ändringar dokumenteras på den här sidan:

Icke-bakåtkompatibel ändring Version introducerad
Designtidsversioner returnerar endast paketreferenser på toppnivå 3.1
Namnändring för resursmanifestfil 3,0
Projektverktyg som nu ingår i SDK 2.1

.NET Core 3.1

Designtidsversioner returnerar endast paketreferenser på toppnivå

Från och med .NET Core SDK 3.1.400 returneras endast paketreferenser på toppnivå av RunResolvePackageDependencies målet.

Version introducerad

.NET Core SDK 3.1.400

Ändra beskrivning

I tidigare versioner av .NET Core SDK RunResolvePackageDependencies skapade målet följande MSBuild-objekt som innehöll information från NuGet-resursfilen:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Dessa data används av Visual Studio för att fylla i noden Beroenden i Solution Explorer. Det kan dock vara en stor mängd data och data behövs inte om inte noden Beroenden expanderas.

Från och med .NET Core SDK version 3.1.400 genereras de flesta av dessa objekt inte som standard. Endast objekt av typen Package returneras. Om Visual Studio behöver objekten för att fylla i noden Beroenden läser den informationen direkt från resursfilen.

Orsak till ändringen

Den här ändrades för att förbättra prestanda för lösningsbelastning i Visual Studio. Tidigare skulle alla paketreferenser läsas in, vilket innebar att många referenser lästes in som de flesta användare aldrig skulle visa.

Om du har MSBuild-logik som är beroende av att dessa objekt skapas anger du EmitLegacyAssetsFileItems egenskapen till true i projektfilen. Den här inställningen aktiverar det tidigare beteendet där alla objekt skapas.

Kategori

MSBuild

Berörda API:er

Ej tillämpligt

.NET Core 3.0

Namnändring för resursmanifestfil

Från och med .NET Core 3.0 genererar MSBuild i standardfallet ett annat manifestfilnamn för resursfiler.

Version introducerad

3,0

Ändra beskrivning

Innan .NET Core 3.0, om inga , eller metadata angavs för ett EmbeddedResource objekt i projektfilen, genererade MSBuild ett manifestfilnamn i mönstret <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources.DependentUpon ManifestResourceNameLogicalName Om RootNamespace inte har definierats i projektfilen är det som standard namnet på projektet. Till exempel var det genererade manifestnamnet för en resursfil med namnet Form1.resx i rotprojektkatalogen MyProject.Form1.resources.

Från och med .NET Core 3.0, om en resursfil samplaceras med en källfil med samma namn (till exempel Form1.resx och Form1.cs), använder MSBuild typinformation från källfilen för att generera manifestfilens namn i mönstret <Namespace>.<ClassName>.resources. Namnområdet och klassnamnet extraheras från den första typen i den samlokaliserade källfilen. Det genererade manifestnamnet för en resursfil med namnet Form1.resx som samlokaliserats med en källfil med namnet Form1.cs är MyNamespace.Form1.resources. Det viktigaste att notera är att den första delen av filnamnet skiljer sig från tidigare versioner av .NET Core (MyNamespace i stället för MyProject).

Kommentar

Om du har LogicalNameangett , ManifestResourceNameeller DependentUpon metadata för ett EmbeddedResource objekt i projektfilen påverkar inte den här ändringen resursfilen.

Den här icke-bakåtkompatibla ändringen introducerades med tillägget av EmbeddedResourceUseDependentUponConvention egenskapen till .NET Core-projekt. Som standard visas inte resursfiler uttryckligen i en .NET Core-projektfil, så de har inga DependentUpon metadata för att ange hur den genererade .resources-filen ska namnges. När EmbeddedResourceUseDependentUponConvention är inställt på true, vilket är standardinställningen, letar MSBuild efter en samlokaliserad källfil och extraherar ett namnområde och klassnamn från filen. Om du anger EmbeddedResourceUseDependentUponConvention till falsegenererar MSBuild manifestnamnet enligt det tidigare beteendet, som kombinerar RootNamespace och den relativa filsökvägen.

I de flesta fall krävs ingen åtgärd från utvecklarens sida, och din app bör fortsätta att fungera. Men om den här ändringen bryter din app kan du antingen:

  • Ändra koden så att den förväntar sig det nya manifestnamnet.

  • Avregistrera dig från den nya namngivningskonventionen genom att ange EmbeddedResourceUseDependentUponConvention i false projektfilen.

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

Kategori

MSBuild

Berörda API:er

Ej tillämpligt

.NET Core 2.1

Projektverktyg som nu ingår i SDK

.NET Core 2.1 SDK innehåller nu vanliga CLI-verktyg och du behöver inte längre referera till dessa verktyg från projektet.

Ändra beskrivning

I .NET Core 2.0 refererar projekt till externa .NET-verktyg med projektinställningen <DotNetCliToolReference> . I .NET Core 2.1 ingår några av dessa verktyg i .NET Core SDK och inställningen behövs inte längre. Om du inkluderar referenser till dessa verktyg i projektet får du ett fel som liknar följande: Verktyget Microsoft.EntityFrameworkCore.Tools.DotNet ingår nu i .NET Core SDK.

Verktyg som nu ingår i .NET Core 2.1 SDK:

<DotNetCliToolReference-värde> Verktyg
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

Version introducerad

.NET Core SDK 2.1.300

Ta bort inställningen <DotNetCliToolReference> från projektet.

Kategori

MSBuild

Berörda API:er

Ej tillämpligt