Wellen ändern

Eine Änderungswelle besteht aus mehreren Behavior Changes in MSBuild, die Sie deaktivieren können, indem Sie ein bestimmtes Flag als Umgebungsvariable angeben. Dies dient dazu, Sie vor potenziell störenden Änderungen zu warnen, damit Sie flexibilität haben, sich an diese Änderungen anzupassen, bevor sie zu Standardfunktionen werden. Alle Features in einer bestimmten Änderungswelle können nur gemeinsam aktiviert oder deaktiviert werden, nicht einzeln.

Wenn Sie ein Upgrade zu einer neuen MSBuild-Version durchführen, sind Änderungen, die möglicherweise Breaking Changes sind, standardmäßig aktiviert. Wenn sich ein Feature jedoch negativ auf Ihr Build auswirkt, können Sie die entsprechende Änderungswelle problemlos deaktivieren. Jede Änderungswelle wird durch eine MSBuild-Versionsnummer (z. B. 16.8) identifiziert, das Festlegen der Änderungswelle steuert jedoch nur bestimmte Features, die das Potenzial haben, den Buildprozess zu beeinflussen, nicht alle Änderungen in dieser MSBuild-Version. Eine Liste der Features der verschiedenen Änderungswellen finden Sie im Abschnitt Änderungswellen und dazugehörige Features in diesem Artikel. Durch deaktivieren einer Änderungswelle werden auch Änderungswellen höherer Versionen deaktiviert.

Deaktivieren der Features von Änderungswellen

Wenn Sie die Features einer Änderungswelle deaktivieren möchten, legen Sie die Umgebungsvariable MSBuildDisableFeaturesFromVersion auf die Änderungswelle (oder die MSBuild-Version) fest, die die Features enthält, die Sie deaktivieren möchten. Dies ist die Version von MSBuild, für die die Features entwickelt wurden. Sehen Sie sich die Zuordnung von Änderungswellen zu den folgenden Features an.

Beständige MSBuild-Prozesse behalten den Wert MSBuildDisableFeaturesFromVersion , mit dem sie begonnen haben. Nachdem Sie die Umgebungsvariable geändert haben, beenden Sie persistente Buildprozesse, bevor Sie einen anderen Build ausführen. Verwenden Sie dotnet build-server shutdownfür Builds, die mit der .NET CLI ausgeführt werden. Für Builds mit Visual Studio oder MSBuild.exeschließen Sie Visual Studio, und beenden Sie alle verbleibenden MSBuild.exe Prozesse. Andernfalls verwenden wiederverwendete Prozesse möglicherweise weiterhin den vorherigen Wert, und projekte, die parallel erstellt wurden, verwenden möglicherweise unterschiedliche Werte.

MSBuildDisableFeaturesFromVersion-Werte

Wenn Sie MSBuildDisableFeaturesFromVersion nicht auf eine gültige Änderungswelle festlegen, erhalten Sie eine Warnung und/oder Sie werden standardmäßig auf eine bestimmte Welle zurückgesetzt. In der folgenden Tabelle sind die möglichen Einstellungen aufgeführt:

Änderungswellen und dazugehörige Features

Aktuelle Abfolge der Änderungswellen

18.10

• Lösen Sie relative Projektpfade anhand des logischen aktuellen Unix-Verzeichnisses von PWD aus auf, damit Builds unter Verzeichnissen mit symbolischen Verknüpfungen stabile vollständige Projektpfade und zugehörige Ausgabepfade erzeugen.
• Restore wird als globale Eigenschaft übergeben, sodass die NuGet-Wiederherstellung keine zweite Auswertung aller Projekte mehr auslöst.
• -getProperty / -getItem (ohne Ziel) beenden die Auswertung nach dem Durchgang, der die angeforderten Daten erzeugt, anstatt eine vollständige Auswertung durchzuführen, wodurch spätere Durchgänge wie die Zielregistrierung vermieden werden.

18.9

• GenerateResource: Eingegebene ResX-Daten/Metadateneinträge in Mark-of-the-Web-Dateien werden jetzt als nicht vertrauenswürdig behandelt und mit MSB3821 blockiert; Heben Sie die Blockierung der Datei auf (oder legen Sie MSBUILDDISABLEFEATURESFROMVERSION=18.9) fest, um das vorherige Verhalten wiederherzustellen. ResXFileRef-Einträge werden unabhängig von dieser Welle immer blockiert.
• TaskHost-Named-Pipe-Puffer sind standardmäßig auf 1 MB festgelegt (zuvor 128 KB), was den Backpressure beim Senden großer TaskHostConfiguration-Pakete reduziert. Einstellbar über MSBUILDNODECONNECTIONBUFFERSIZE

18.8

• RAR-Aufgabe: Bei mehreren Eingabeeigenschaften relative Pfade anhand des Projektverzeichnisses auflösen (nicht anhand des aktuellen Prozessverzeichnisses)
• Konsolen-, parallele Konsolen- und Terminalprotokollierer drucken die Pfade von Protokolldateien, die von registrierten Loggern (z. B. Dateiprotokollierer und binärer Logger) als Teil der End-of-Build-Zusammenfassung geschrieben wurden.

18,7

• Der Kopiervorgang wird bei ERROR_ACCESS_DENIED auf Nicht-Windows-Plattformen wiederholt, um vorübergehende Sperrkonflikte zu bewältigen (z. B. macOS-CoW-Dateisysteme)
• ASP.NET-WebSite-Projekte zur Auflösung von netstandard2.0-Abhängigkeiten korrigieren – TargetFrameworkVersion an die RAR-Aufgabe übergeben und die netstandard.dll-Facade für .NET-Framework-Webprojekte ab 4.7.1 kopieren.

18.6

• AbsolutePath.GetCanonicalForm-Optimierung – vermeiden Sie teure Path.GetFullPath-Aufrufe, wenn Pfade keine Kanonisierung benötigen
• TaskHostTask leitet globale Eigenschaften auf Anforderungsebene (z. B. MSBuildRestoreSessionId) im -mt Modus an out-of-proc TaskHost weiter.
• Behebt, dass ShouldTreatWarningAsError im OOP TaskHost die falsche Sammlung prüft (WarningsAsMessages anstelle von WarningsAsErrors)
• Behebt das Hängenbleiben von ToolTask, wenn das Tool Prozesse zweiter Generation startet, die die Pipe-Handles für stdout/stderr erben

18,5

• FindUnderPath- und AssignTargetPath-Aufgaben werden bei Verwendung von TaskEnvironment.GetAbsolutePath nicht mehr für ungültige Pfadzeichen ausgelöst.
• AssignTargetPath unter Linux berücksichtigt die Groß-/Kleinschreibungsempfindlichkeit des Dateisystems, anstatt den Fall immer zu ignorieren.

18.4

• Beginnen Sie mit dem Auslösen von Null- oder leeren Pfaden in MultiProcess- und MultiThreaded Task Environment Drivers.

Änderungswellen, die im Release zusammen mit .NET 11 entfernt werden

18.3

• Ersetzen Sie die Eigenschaft Transactional durch das Steuerelement ChangeWave, implementieren Sie das atomare Ersetzen von Dateien mit Wiederholungslogik und aktualisieren Sie die Tests.

17.14

• ~ .SLNX-Unterstützung – Verwendung des neuen Parsers für .sln und .slnx~ nach Feststellung von Kompatibilitätsproblemen zurückgenommen
• Unterstützung von benutzerdefinierter Kultur in RAR – details finden Sie unter 11607
• VS-Telemetrie

17.12

• Log TaskParameterEvent für skalare Parameter
• Convert.ToString während einer Eigenschaftsauswertung verwendet den InvariantCulture für alle Typen.
• Beheben des übermäßigen Teilens von Buildergebnissen in ResultsCache
• Hinzufügen von ParameterName und PropertyName zu TaskParameterEventArgs
• Ausgabe von Evaluierungseigenschaften, wenn dies von einer Senke angefordert wird
• Microsoft.DotNet.MSBuildSdkResolver in den Standardladekontext laden (nur MSBuild.exe)

17.10

• Die AppDomain-Konfiguration wird serialisiert, ohne BinFmt zu verwenden – die Funktion kann nur deaktiviert werden, wenn BinaryFormatter zur Laufzeit durch Bearbeiten von MSBuild.runtimeconfig.json zugelassen ist. Bitte beachten Sie, dass jede Verwendung von BinaryFormatter unsicher ist.
• Warnung zu benutzerdefinierten Serialisierungsereignissen standardmäßig im .NET Framework
• SDK-Resolver-Daten prozessweit zwischenspeichern
• Zielparameter werden nicht in Anführungszeichen gesetzt, das heißt, dass das Symbol ";" im Zielnamen des Parameters immer als Trennzeichen behandelt wird.
• Hinzufügen von Linkmetadaten zu Ressourcen im AssignLinkMetadata-Ziel
• Versionswechsel so ändern, dass er mit einem Zeilenumbruch endet
• NuGet.Frameworks in eine sekundäre AppDomain laden (nur MSBuild.exe)
• Aktualisieren von Merkmalen, wenn die Umgebung geändert wurde
• Die Exec-Aufgabe schneidet führende Leerzeichen für ConsoleOutput nicht ab.
• [MSBuild]::StableStringHash-Überladungen einführen
• Halten Sie die Codierung der Standardausgabe und des Fehlers konsistent mit der Konsolencodeseite für ToolTask

Änderungswellen außerhalb der Rotation

16.8

• NoWarn- aktivieren
• Kürzen von Protokollmeldungen zu übersprungenen Zielen/Aufgaben auf 1.024 Zeichen
• Keine Erweiterung vollständiger Laufwerkglobs mit falscher Bedingung

16.10

• Fehler bei Leerraum einer Eigenschaftserweiterung in einer Bedingung
• Benutzerdefinierten CopyToOutputDirectory-Speicherort mit TargetPath- zulassen
• Zulassen erfolgreicher Builds unter Verwendung von exec durch Benutzer mit Sonderzeichen im Benutzernamen
• Wiederherstellungsvorgänge fehlschlagen, wenn ein SDK nicht aufgelöst werden kann
• Optimieren der Platzhalterbewertung

17.0

• Scheduler sollte BuildParameters.DisableInprocNode berücksichtigen
• Keine Kompilierung von regulären Ausdrücken mit Platzhaltern in .NET Framework
• Standardmäßig werden Inhaltselemente transitiv kopiert
• Referenzassemblys werden jetzt standardmäßig nicht mehr im Verzeichnis bin platziert (hier zurückgesetzt und hier wiederhergestellt)
• Verbessern der Debugerfahrung: Hinzufügen des globalen Switchs MSBuildDebugEngine; Binäre Logger aus BuildManager injizieren; Statisches Diagramm als DOT-Datei drucken
• Korrigieren eines Deadlocks in BuildManager wie in LoggingService
• Optimieren der Diagnoseebene für die Datei- und Konsolenprotokollierung
• Überprüfen optimierter unveränderlicher Dateien auf Aktualität
• Hinzufügen von Microsoft.IO.Redist für verzeichnisaufzählung
• Prozessweite Zwischenspeicherung von ToolsetConfigurationSection-
• Normalisieren von RAR-Ausgabepfaden

17.4

• Berücksichtigen von „deps.json“ beim Laden von Assemblys
• Berücksichtigen von Platform als Standardwert bei der Plattformverhandlung
• Hinzufügen des Übereinstimmungsmusters für akzeptierte SDK-Namen zu SDK-Manifesten
• Warnung auslösen, die auf ungültige Projekttypen hinweist
• MSBuild-Server

17.6

• Ungültige Eigenschaft unter Ziel parsen
• Projekt-String-Cache eliminieren
• Protokollieren eines Fehlers, wenn kein angegebener Suchpfad für einen Import vorhanden
• Assemblyladungen protokollieren
• AnyHaveMetadataValue gibt "false" zurück, wenn eine leere Liste übergeben wird.
• Selbständige Erweiterung von Elementen protokollieren

17.8

• [RAR] Keine E/A-Vorgänge für vom SDK bereitgestellten Verweise ausführen
• Zieldatei vor dem Kopieren löschen
• Wechseln von SHA1 zu SHA256 für Hashaufgaben
• Benutzerdefinierte abgeleitete BuildEventArgs-Elemente werden eingestellt: Das Feature kann nur deaktiviert werden, wenn BinaryFormatter zur Laufzeit durch Bearbeitung von MSBuild.runtimeconfig.json zugelassen wird.

Häufig gestellte Fragen

Warum sollten andere Releases als Ziel verwendet werden, wenn Änderungswellen aussortiert werden?

Wir glauben, dass dies ausreichend Zeit ist, um gespräche mit den betroffenen Personen zu führen und sich an die Änderungen anzupassen.

Warum eine Umgebungsvariable und keine Projekteigenschaft?

Es gibt Szenarien, in denen wir ein Feature unter einer Änderungswelle platzieren möchten, bevor MSBuild das Projekt geladen hat. Aus diesem Grund erfordern Änderungswellen die Verwendung von Umgebungsvariablen.

Warum Opt-out statt Opt-in?

Dieser Ansatz eignet sich besser für uns, da wir andernfalls nur eingeschränkt Feedback erhalten würden, wenn ein Feature Builds von Kunden beeinträchtigt.

Verwandte Inhalte

• MSBuild
• Neuerungen in MSBuild 16-