Zmienia fale
Fala zmian to zestaw zmian w działaniu programu MSBuild, których można uniknąć, ustawiając odpowiednią flagę jako zmienną środowiskową. Celem tego jest ostrzeżenie przed potencjalnie destrukcyjnymi zmianami, dzięki czemu masz elastyczność dostosowywania się do tych zmian, zanim staną się one standardową funkcjonalnością. Wszystkie funkcje określonej fali zmian można włączać lub wyłączać tylko razem, a nie osobno.
Po aktualizacji do nowszej wersji MSBuild, zmiany mogące powodować problemy z kompatybilnością są domyślnie włączone, ale jeśli funkcja wpłynie negatywnie na budowę, można łatwo wyłączyć tę grupę zmian. Każda fala zmian jest identyfikowana przez numer wersji programu MSBuild (na przykład 16.8), ale ustawienie fali zmian kontroluje tylko niektóre funkcje, które mogą mieć wpływ na proces kompilacji, a nie wszystkie zmiany w tej wersji programu MSBuild. Lista funkcji w każdej fali zmian zostanie wyświetlona w dalszej części tego artykułu. Wyłączenie fali zmian wyłącza również fale zmian w wyższych wersjach.
Zrezygnuj z funkcji fal zmianowych
Aby wyłączyć funkcje w fali zmian, ustaw zmienną środowiskową MSBuildDisableFeaturesFromVersion
na falę zmian (lub wersję programu MSBuild), która zawiera funkcję, którą chcesz wyłączone. Jest to wersja programu MSBuild, dla którego zostały opracowane funkcje. Zobacz odwzorowanie etapów zmian na funkcje poniżej.
Wartości MSBuildDisableFeaturesFromVersion
Jeśli nie ustawisz MSBuildDisableFeaturesFromVersion
na prawidłową falę, zostanie wyświetlone ostrzeżenie i/lub zostaniesz domyślnie przypisany do określonej fali. W poniższej tabeli przedstawiono możliwe ustawienia:
wartość MSBuildDisableFeaturesFromVersion |
Wynik | Otrzymujesz ostrzeżenie? |
---|---|---|
Nieustawiony | Włącz wszystkie fale zmian, co oznacza, że dzięki każdej fali wszystkie funkcje są włączone. | Nie |
Każda prawidłowa i bieżąca fala zmian (na przykład 16.8 ) |
Wyłącz wszystkie funkcje za falą zmian 16.8 i nowszych. |
Nie |
Nieprawidłowa wartość (na przykład 16.9 , gdy prawidłowe fale są 16.8 i 16.10 ) |
Ustawienie domyślne najbliższej prawidłowej wartości (rosnąco). Na przykład ustawienie 16.9 ustawi cię na domyślne 16.10 . |
Nie |
Poza rotacją (na przykład 17.1 , gdy najwyższa fala jest 17.0 ) |
Zaciśnięty do najbliższej prawidłowej wartości. Na przykład 17.1 przymocowuje się do 17.0 , a 16.5 przymocowuje się do 16.8 |
Tak |
Nieprawidłowy format (na przykład 16x8 , 17_0 , garbage ) |
Włącz wszystkie fale zmian, co oznacza, że wszystkie funkcje związane z każdą falą zmian są aktywowane. | Tak |
Zmiana fal i powiązanych cech
17.10
-
konfiguracja AppDomain jest serializowana bez używania BinFmt — można zrezygnować z funkcji tylko wtedy, gdy BinaryFormatter jest dozwolona w czasie wykonywania, edytując
MSBuild.runtimeconfig.json
- Rozpoznawanie danych pamięci podręcznej SDK w całym procesie
17.8
- [RAR] Nie wykonuj operacji wejścia/wyjścia na odniesieniach dostarczonych przez SDK
- Usuń plik docelowy przed skopiowanie
- Przejście od SHA1 do SHA256 dla zadania haszowania
-
Przestarzałe własne pochodne BuildEventArgs — z funkcji można zrezygnować tylko wtedy, gdy BinaryFormatter jest dozwolony w czasie wykonywania, edytując
MSBuild.runtimeconfig.json
17.6
- Analizowanie nieprawidłowej właściwości w kontekście celu
- Usunięcie pamięci podręcznej projektu
- Rejestrowanie błędu, gdy nie ma podanej ścieżki wyszukiwania dla importu
- Zestaw dziennika ładuje
- AnyHaveMetadataValue zwraca wartość false po przekazaniu pustej listy
- samodzielne rozszerzanie elementu dziennika
17.4
- Przestrzegaj deps.json podczas ładowania zestawów
-
rozważ
Platform
jako domyślne ustawienie podczas negocjacji dotyczących platformy - Dodawanie akceptowanego wzorca dopasowania nazwy zestawu SDK do manifestów zestawu SDK
- Wygenerować ostrzeżenie wskazujące na nieprawidłowe typy projektów
- serwer MSBuild
- Wywołaj nowe API CultureInfo podczas weryfikacji kultur (tylko .NET Core)
17.0
- Scheduler powinien uwzględniać parametr BuildParameters.DisableInprocNode
- Nie kompiluj wzorców globów z użyciem wyrażeń regularnych na .NET Framework
- Domyślnie stosuj transytowe kopiowanie elementów treści
- Zestawy odniesienia nie są już domyślnie umieszczane w katalogu
bin
(odwrócone tutaj i przywrócone tutaj) - Ulepsz środowisko debugowania: dodaj globalny przełącznik MSBuildDebugEngine; Wstrzyknij rejestrator binarny z narzędzia BuildManager; drukuj graf statyczny jako plik .dot
- Naprawa zakleszczenia w BuildManager vs LoggingService
- Optymalizowanie poziomu diag dla rejestratora plików i rejestratora konsoli
- Zoptymalizowane sprawdzanie aktualności plików niezmiennych
- Dodaj Microsoft.IO.Redist do enumeracji katalogów
- Ogólnoprocesowe buforowanie ToolsetConfigurationSection
- Normalizacja ścieżek wyjściowych RAR
Zmiana fal nie jest już w rotacji
16.8
- Włącz NoWarn
- Obcięcie komunikatów dziennika związanych z celem/zadaniem do 1024 znaków
- Nie rozszerzaj pełnych globów dysku z fałszywym warunkiem
16.10
- Błąd, gdy rozszerzenie właściwości w warunku zawiera znak odstępu
- zezwalaj na niestandardową lokalizację CopyToOutputDirectory przy użyciu TargetPath
- Pozwól użytkownikom, którzy mają określone znaki specjalne w nazwie użytkownika, pomyślnie budować używając exec
- Niepowodzenie operacji przywracania, gdy zestaw SDK jest nierozwiązywalny
- Optymalizacja oceny glob
FAQ
Dlaczego celować w każdą alternatywną wersję dla wprowadzania zmian etapami?
Uważamy, że jest to wystarczająco dużo czasu, aby prowadzić dyskusje z tymi, których dotyczy problem, i pomóc w dostosowaniu się do zmian.
Dlaczego zmienna środowiskowa, a nie właściwość projektu?
Istnieją scenariusze, w których chcemy umieścić funkcję na fali zmian, zanim program MSBuild załadował projekt. Z tego powodu fale zmian wymagają użycia zmiennych środowiskowych.
Dlaczego zrezygnować z zgody?
Automatyczna rezygnacja jest dla nas lepszym rozwiązaniem. W przeciwnym razie prawdopodobnie otrzymalibyśmy ograniczoną opinię, gdy funkcjonalność wpłynie na wersje oprogramowania klientów.
Powiązana zawartość
- MSBuild
- Co nowego w programie MSBuild 16