Blazor: Pola publiczne renderTreeFrame do odczytu stały się właściwościami
W ASP.NET Core 3.0 i 3.1 RenderTreeFrame struktura uwidoczniła różne readonly public
pola, w tym FrameType, Sequencei inne. W wersji ASP.NET Core 5.0 RC1 i nowszych wszystkie readonly public
pola zmieniły się na readonly public
właściwości.
Ta zmiana nie wpłynie na wielu deweloperów, ponieważ:
- Każda aplikacja lub biblioteka, która po prostu używa
.razor
plików (a nawet wywołań ręcznych RenderTreeBuilder ), aby zdefiniować jego składniki, nie będzie bezpośrednio odwoływała się do tego typu. - Sam
RenderTreeFrame
typ jest traktowany jako szczegóły implementacji, który nie jest przeznaczony do użytku poza strukturą. ASP.NET Core 3.0 lub nowszy zawiera analizator, który wyświetla ostrzeżenia kompilatora, jeśli typ jest używany bezpośrednio. - Nawet jeśli odwołujesz się
RenderTreeFrame
bezpośrednio do tej zmiany, jest to niezgodność binarna, ale nie powodująca przerwania źródła. Oznacza to, że istniejący kod źródłowy będzie kompilować i zachowywać się prawidłowo. Napotkasz problem tylko w przypadku kompilowania na platformie .NET Core 3.x, a następnie uruchamiania tych plików binarnych na platformie .NET 5 lub nowszej.
Aby zapoznać się z dyskusją, zobacz problem z usługą GitHub dotnet/aspnetcore#25727.
Wprowadzona wersja
5.0 RC1
Stare zachowanie
Publiczne elementy członkowskie są RenderTreeFrame
definiowane jako pola. Przykład: renderTreeFrame.Sequence
i renderTreeFrame.ElementName
.
Nowe zachowanie
Publiczne elementy członkowskie są RenderTreeFrame
definiowane jako właściwości o takich samych nazwach jak poprzednio. Przykład: renderTreeFrame.Sequence
i renderTreeFrame.ElementName
.
Jeśli starszy wstępnie skompilowany kod nie został ponownie skompilowany od tej zmiany, może zgłosić wyjątek podobny do MissingFieldException: Nie znaleziono pola: "Microsoft.AspNetCore.Components.RenderTree.RenderTreeFrame.FrameType".
Przyczyna wprowadzenia zmiany
Ta zmiana była konieczna do zaimplementowania wysokiej wydajności w renderowaniu składników Razor w ASP.NET Core 5.0. Utrzymywane są te same poziomy bezpieczeństwa i hermetyzacji.
Zalecana akcja
Na tę zmianę nie ma wpływu większość deweloperów platformy Blazor. Zmiana jest bardziej prawdopodobna, aby wpłynąć na autorów bibliotek i pakietów, ale tylko w rzadkich przypadkach. W szczególności, jeśli tworzysz:
- Aplikacja i korzystanie z platformy ASP.NET Core 3.x lub uaktualniania do wersji 5.0 RC1 lub nowszej nie trzeba zmieniać własnego kodu. Jeśli jednak zależysz od biblioteki, która została uaktualniona do konta tej zmiany, musisz przeprowadzić aktualizację do nowszej wersji tej biblioteki.
- Biblioteka i chce obsługiwać tylko ASP.NET Core 5.0 RC1 lub nowszy, nie jest wymagana żadna akcja. Upewnij się, że plik projektu deklaruje
<TargetFramework>
wartośćnet5.0
lub nowszą wersję. - Biblioteka i chce obsługiwać zarówno ASP.NET Core 3.x , jak i 5.0, określić, czy kod odczytuje jakieś
RenderTreeFrame
elementy członkowskie. Na przykład ocenasomeRenderTreeFrame.FrameType
elementu .- Większość bibliotek nie odczytuje
RenderTreeFrame
elementów członkowskich, w tym bibliotek zawierających.razor
składniki. W takim przypadku nie jest wymagana żadna akcja. - Jeśli jednak biblioteka to robi, musisz obsługiwać
netstandard2.1
zarówno wiele obiektów docelowych, jak inet5.0
. Zastosuj następujące zmiany w pliku projektu:Zastąp istniejący
<TargetFramework>
element ciąg .<TargetFrameworks>netstandard2.0;net5.0</TargetFrameworks>
Użyj odwołania do pakietu warunkowego
Microsoft.AspNetCore.Components
, aby uwzględnić obie wersje, które chcesz obsługiwać. Na przykład:<PackageReference Include="Microsoft.AspNetCore.Components" Version="3.0.0" Condition="'$(TargetFramework)' == 'netstandard2.0'" /> <PackageReference Include="Microsoft.AspNetCore.Components" Version="5.0.0-rc.1.*" Condition="'$(TargetFramework)' != 'netstandard2.0'" />
- Większość bibliotek nie odczytuje
Aby uzyskać więcej wyjaśnień, zobacz ten artykuł diff showing how @jsakamoto already upgraded the Toolbelt.Blazor.HeadElement
library.