Błędy i ostrzeżenia związane z deklaracjami właściwości

Mogą wystąpić następujące błędy związane z deklaracjami właściwości:

• CS0200: Nie można przypisać właściwości lub indeksatora "właściwość" do — jest tylko do odczytu
• CS0545: "function" : nie można zastąpić, ponieważ property nie ma zastępowalnego akcesora get
• CS0571: "function" : nie można jawnie wywołać operatora lub akcesora
• CS0840: "Nazwa właściwości" musi zadeklarować ciało, ponieważ nie jest oznaczona jako abstrakcyjna ani extern. Automatycznie zaimplementowane właściwości muszą definiować zarówno akcesory get, jak i set.
• CS1014: Oczekiwano akcesora pobierającego lub ustawiającego
• CS1043: { lub ; oczekiwano
• CS8050: Tylko właściwości zaimplementowane automatycznie lub właściwości używające słowa kluczowego "field" mogą mieć inicjatory
• CS8051: Właściwości implementowane automatycznie muszą mieć akcesory get
• CS8053: Właściwości wystąpienia w interfejsach nie mogą mieć inicjalizatorów
• CS8145: Właściwości zaimplementowane automatycznie nie mogą być zwracane przez odwołanie
• CS8147: Właściwości zwracane przez odwołanie nie mogą mieć ustawionych metod dostępu
• CS8341: Automatycznie implementowane właściwości wystąpienia w strukturach tylko do odczytu muszą być oznaczone jako tylko do odczytu
• CS8657: Statyczny element członkowski nie może być oznaczony jako "readonly"
• CS8658: Automatycznie zaimplementowana metoda dostępu 'set' nie może być oznaczona jako 'readonly'
• CS8659: Właściwość implementowana automatycznie nie może być oznaczona jako "readonly", ponieważ ma ona metodę dostępu "set"
• CS8660: Nie można określić modyfikatorów "readonly" zarówno dla właściwości, jak i jej akcesora
• CS8661: Nie można określić modyfikatorów "readonly" na oba akcesory właściwości
• CS8664: "readonly" może być używany tylko w przypadku akcesorów, jeśli właściwość ma zarówno get, jak i set
• CS9029: Typy i aliasy nie mogą mieć nazwy "required".
• CS9030: Członek musi być wymagany, ponieważ zastępuje wymagany członek.
• CS9031: Wymagany element członkowski nie może być ukryty przez pochodny element członkowski.
• CS9032: Wymagany członek nie może być mniej widoczny ani mieć ustawiania mniej widocznego niż typ nadrzędny.
• CS9033: Nie używaj "System.Runtime.CompilerServices.RequiredMemberAttribute'. Zamiast tego użyj słowa kluczowego "required" dla wymaganych pól i właściwości.
• CS9034: Wymagany członek musi być możliwy do ustawienia.
• CS9035: Wymagany element członkowski musi być ustawiony w inicjatorze obiektu lub konstruktorze atrybutu.
• CS9036: Wymagany element członkowski "memberName" musi mieć przypisaną wartość, nie może użyć zagnieżdżonego elementu członkowskiego lub inicjatora kolekcji.
• CS9037: Lista wymaganych członków jest źle sformułowana i nie można jej zinterpretować.
• CS9038: Lista wymaganych elementów członkowskich dla typu podstawowego jest źle sformułowana i nie można jej interpretować. Aby użyć tego konstruktora, zastosuj atrybut "SetsRequiredMembers".
• CS9039: Ten konstruktor musi dodać 'SetsRequiredMembers', ponieważ odwołuje się do konstruktora, który ma ten atrybut.
• CS9040: Typ nie może spełnić ograniczenia "new()" dla parametru w typie ogólnym lub metodzie, ponieważ ma wymagane elementy członkowskie.
• CS9042: Wymagany członek nie powinien być przypisywany atrybutem "ObsoleteAttribute", chyba że typ zawierający jest przestarzały lub wszystkie konstruktory są przestarzałe.
• CS9045: Wymagani członkowie nie są dozwoleni na najwyższym poziomie skryptu ani w przesyłanym pliku.
• CS9258: W tej wersji języka słowo kluczowe "field" wiąże się z syntetyzowanym polem zapasowym dla właściwości. Aby uniknąć generowania zsyntetyzowanego pola zapasowego i odwołać się do istniejącego elementu członkowskiego, zamiast tego użyj "this.field" lub "@field".
• CS9263: Właściwość częściowa nie może mieć inicjatora zarówno definicji, jak i implementacji.

Dla właściwości opartych na polach można wygenerować następujące ostrzeżenia:

• CS9264: Właściwość niemająca wartości null musi zawierać wartość inną niż null przy wychodzeniu z konstruktora. Rozważ dodanie modyfikatora 'required', zadeklarowanie właściwości jako nullable lub dodanie atrybutów "[field: MaybeNull, AllowNull]".
• CS9266: Jeden akcesor właściwości powinien używać "field", ponieważ drugi akcesorium używa go.
• CS9273: W tej wersji językowej "field" stanowi słowo kluczowe wewnątrz akcesora właściwości. Zmień nazwę zmiennej lub użyj identyfikatora "@field" zamiast tego.

W poniższych sekcjach opisano przyczynę i poprawki tych błędów i ostrzeżeń.

Składnia dostępu do właściwości

• CS0545: "function" : nie można zastąpić, ponieważ właściwość nie ma zastępowalnej metody uzyskiwania dostępu
• CS0571: "function" : nie można jawnie wywołać operatora lub akcesora
• CS1043: { lub ; oczekiwano

Aby poprawić błędy składni akcesorów właściwości, zastosuj jedną z następujących zmian w oparciu o określoną diagnostykę:

Zastąp tylko metody dostępu istniejące w deklaracji właściwości klasy bazowej (CS0545). Nie można zastąpić akcesora właściwości, który nie jest obecny ani dostępny w klasie bazowej, ponieważ w skompilowanym IL nie istnieje metoda wirtualna do zastąpienia. Jeśli właściwość klasy bazowej ma tylko akcesor get, usuń akcesor set ze swojej nadpisanej wersji lub dodaj brakujący akcesor do klasy bazowej i oznacz go jako virtual. Alternatywnie, użyj słowa kluczowego new zamiast override, aby ukryć właściwość klasy bazowej za pomocą całkowicie nowej definicji właściwości, która ma inne metody dostępu.

Uzyskiwanie dostępu do właściwości przy użyciu składni właściwości zamiast bezpośredniego wywoływania metod dostępu (CS0571). Metody dostępu właściwości kompilują się do specjalnych metod o nazwach takich jak get_PropertyName i set_PropertyName, ale należy wywołać te metody za pomocą składni właściwości (obj.Property i obj.Property = value). Takie podejście utrzymuje właściwą semantykę i umożliwia kompilatorowi przeprowadzenie niezbędnych testów. Ta sama zasada dotyczy operatorów, które kompiluje się do metod takich jak op_Increment , ale powinny być wywoływane przy użyciu składni operatora (++obj) zamiast wywołań metod.

Użyj prawidłowej składni metody dostępu właściwości z nawiasami klamrowymi lub ciałami wyrażeń (CS1043). Metody dostępu do właściwości muszą być zgodne z regułami składni języka C#: jednostki dostępu muszą być ujęte w nawiasy klamrowe { }, metody dostępu wyrażeniowego muszą używać składni =>, a właściwości implementowane automatycznie muszą kończyć się średnikiem po liście akcesorów. Kompilator oczekuje pełnej implementacji akcesora lub średnika wskazującego automatycznie implementowany akcesor.

Aby uzyskać więcej informacji, zobacz Właściwości, Dziedziczenie i Używanie właściwości.

Właściwości zaimplementowane automatycznie

• CS0840: "Nazwa właściwości" musi zadeklarować ciało, ponieważ nie jest oznaczona jako 'abstract' ani 'extern'. Automatycznie zaimplementowane właściwości muszą definiować zarówno akcesory get, jak i set.
• CS1014: Oczekiwano akcesora get lub set

Aby poprawić błędy właściwości implementowanych automatycznie, zastosuj jedną z następujących zmian na podstawie określonej diagnostyki:

Dodaj zarówno elementy dostępu get i set do deklaracji właściwości (CS0840). Właściwości zaimplementowane automatycznie wymagają, aby kompilator wygenerował pole zapasowe, a kompilator może to zrobić tylko wtedy, gdy istnieją oba metody dostępu, aby upewnić się, że magazyn może być zarówno odczytywany, jak i zapisywany. Jeśli potrzebujesz właściwości implementowanej automatycznie tylko do odczytu, dołącz akcesor set i oznacz go jako private, aby ograniczyć dostęp do zapisu, jednocześnie umożliwiając kompilatorowi generowanie pola zapasowego. Alternatywnie, jeśli właściwość jest zadeklarowana jako abstract lub extern, usuń ciała akcesorów całkowicie, ponieważ modyfikatory wskazują, że implementacja jest dostarczana w innym miejscu. W przypadku właściwości partial, można podzielić deklarację i implementację pomiędzy deklaracje typów częściowych.

Upewnij się, że deklaracja właściwości zawiera tylko prawidłowe słowa kluczowe metod dostępu get i set (CS1014). Składnia właściwości umożliwia tylko deklaracje metod dostępu, a nie dowolne instrukcje lub deklaracje składowe w treści właściwości. Jeśli potrzebujesz dodatkowej logiki, zaimplementuj właściwość z jawnymi elementami dostępu zawierającymi kod. Jeśli próbujesz zadeklarować pola lub metody, przenieś te deklaracje poza właściwość do jednostki klasy lub struktury, w której dozwolone są deklaracje składowe.

Aby uzyskać więcej informacji, zobacz Właściwości i właściwości zaimplementowane automatycznie.

Właściwości oparte na polach

• CS9258: W tej wersji języka słowo kluczowe "field" wiąże się z syntetyzowanym polem zapasowym dla właściwości. Aby uniknąć generowania zsyntetyzowanego pola zapasowego i odwołać się do istniejącego elementu członkowskiego, zamiast tego użyj "this.field" lub "@field".
• CS9263: Właściwość częściowa nie może mieć inicjatora zarówno definicji, jak i implementacji.
• CS9264: Nienullowalna właściwość musi zawierać wartość inną niż null przy wychodzeniu z konstruktora. Rozważ dodanie modyfikatora 'wymagane', zadeklarowanie właściwości jako nullable, lub dodanie atrybutów "[field: MaybeNull, AllowNull]".
• CS9266: Jeden akcesor właściwości powinien używać "field", ponieważ drugi akcesorium używa go.
• CS9273: W tej wersji językowej "field" jest słowem kluczowym w metodzie dostępu do właściwości. Zmień nazwę zmiennej lub użyj identyfikatora "@field".

Aby poprawić błędy właściwości wspieranych polami, zastosuj jedną z następujących zmian na podstawie określonej diagnozy:

Zmień nazwę dowolnej zmiennej o nazwie field na inny identyfikator lub użyj @field składni ucieczki, aby odwołać się do zmiennej (CS9258, CS9273). Ta korekta jest niezbędna, ponieważ field jest kontekstowym słowem kluczowym w akcesorach właściwości w języku C# 13 i nowszych wersjach, gdzie odwołuje się do pola wspierającego syntetyzowanego przez kompilator. Jeśli chcesz uzyskać dostęp do istniejącego elementu członkowskiego o nazwie field zamiast zsyntetyzowanego pola zapasowego, użyj this.field , aby dookreślić odwołanie.

Usuń inicjator z częściowej definicji właściwości lub implementacji, zachowując tylko jeden element (CS9263). Ta korekta jest wymagana, ponieważ zezwolenie na inicjatory w obu lokalizacjach prowadziłoby do niejasności co do tego, która wartość powinna zostać użyta i może prowadzić do zainicjowania pola pomocniczego dwa razy z potencjalnie różnymi wartościami.

[field: MaybeNull, AllowNull] Dodaj atrybuty do deklaracji właściwości, aby wskazać, że pole zapasowe powinno być traktowane jako dopuszczające wartość null (CS9264). Ta korekta dostosowuje oczekiwania dotyczące możliwości przypisania wartości null między typem właściwości a polu wspierającym generowanym przez kompilator, rozwiązując niezgodność, w której właściwość jest zadeklarowana jako nieprzyjmująca wartości null, ale użycie słowa kluczowego field sugeruje, że może to być wartość null. Alternatywnie zmień typ właściwości na nullable, dodaj modyfikator required aby zapewnić inicjalizację lub zainicjalizuj właściwość w konstruktorze.

Konsekwentnie należy stosować słowo kluczowe field w obu akcesorach lub stosować jawne pole pomocnicze w obu akcesorach (CS9266). Ta korekta zapobiega potencjalnym usterce, gdy jeden element dostępu modyfikuje pole kopii zapasowej syntetyzowane przez kompilator, podczas gdy inne metody dostępu modyfikują inną lokalizację przechowywania, co prowadzi do niespójnego zachowania właściwości.

Aby uzyskać więcej informacji, zobacz pole kluczowe i właściwości częściowe.

Właściwości tylko do odczytu

• CS0200: Nie można przypisać do właściwości lub indeksatora "właściwość" — ponieważ jest tylko do odczytu
• CS8341: Właściwości wystąpienia automatycznie implementowane w strukturach tylko do odczytu muszą być readonly
• CS8657: Statyczny członek nie może być oznaczony jako „readonly”
• CS8658: Automatycznie zaimplementowany akcesor 'set' nie może być oznaczony jako 'readonly'
• CS8659: Właściwość implementowana automatycznie nie może być oznaczona jako "readonly", ponieważ ma ona metodę dostępu "set"
• CS8660: Nie można określić modyfikatorów "readonly" dla właściwości i jej metody dostępu
• CS8661: Nie można określić modyfikatorów "readonly" dla obu akcesorów właściwości
• CS8664: „readonly” może być używany tylko w przypadku akcesorów, jeśli właściwość ma zarówno metodę get, jak i set

Aby poprawić błędy właściwości tylko do odczytu, zastosuj jedną z następujących zmian w oparciu o określoną diagnozę:

Dodaj set lub init metodę dostępu do właściwości, aby można było ją zapisywać (CS0200). Ta korekta jest niezbędna, ponieważ właściwości bez zestawów metod dostępu są tylko do odczytu i mogą być przypisane tylko w konstruktorze lub inicjatorze pola deklarowanego typu. Jeśli chcesz ustawić właściwość podczas inicjowania jego obiektu, ale aby była niezmienialna później, użyj init akcesora zamiast set akcesora. Jeśli właściwość powinna pozostać tylko do odczytu, przenieś przypisanie do konstruktora, w którym jest dozwolone inicjowanie, lub ponownie sprawdź, czy przypisanie jest konieczne w ogóle.

Oznacz automatycznie implementowane właściwości wystąpienia jako readonly podczas deklarowania ich wewnątrz readonly struct (CS8341). Ta poprawka wymusza zasadę niezmienności dla struktury, zapewniając, że wszyscy członkowie instancji przestrzegają gwarancji readonly. Jeśli właściwość musi być modyfikowalna, usuń modyfikator readonly z deklaracji struktury lub zaimplementuj właściwość przy użyciu jawnego pola pomocniczego oraz ciał akcesorów, które nie modyfikują stanu wystąpienia.

readonly Usuń modyfikator z deklaracji właściwości statycznych lub metod dostępu (CS8657). Ta korekta jest wymagana, ponieważ modyfikator readonly ma zastosowanie tylko do elementów członkowskich instancji struktur, aby wskazać, że nie zmieniają one stanu instancji, a statyczne elementy członkowskie nie mają stanu instancji do ochrony. Jeśli potrzebujesz statycznej właściwości tylko do odczytu, po prostu pomiń akcesor set zamiast stosować modyfikator readonly.

Usuń modyfikator readonly z automatycznie zaimplementowanych akcesorów set lub zastosuj go tylko do akcesora get (CS8658). Ta korekta jest niezbędna, ponieważ set metody dostępu z natury modyfikują stan, który jest sprzeczny z celem readonly modyfikatora, który gwarantuje brak modyfikacji stanu wystąpienia. Jeśli potrzebujesz właściwości, którą można ustawić podczas inicjowania, ale później jest tylko do odczytu, użyj akcesora init zamiast akcesora set.

readonly Usuń ten modyfikator z deklaracji właściwości, gdy właściwość ma akcesor set (CS8659). Poprawka ta jest wymagana, ponieważ właściwości z set akcesorami mogą modyfikować stan instancji, co narusza readonly gwarancję. Jeśli potrzebujesz ustawienia wyłącznie podczas inicjalizacji, zastąp akcesor set akcesorem init lub całkowicie usuń akcesor set, aby właściwość była naprawdę tylko do odczytu.

Umieść modyfikator readonly na deklaracji właściwości lub na poszczególnych akcesorach, ale nie na obu (CS8660, CS8661). Ta korekta uniemożliwia nadmiarowe deklaracje modyfikatora, które mogą powodować zamieszanie dotyczące tego, który modyfikator ma pierwszeństwo. Jeśli chcesz oznaczyć określone akcesory jako readonly, usuń modyfikator z deklaracji właściwości i dodaj go tylko do akcesorów. Alternatywnie, jeśli wszystkie metody dostępu powinny mieć readonly, ustaw samą właściwość zamiast poszczególnych metod dostępowych.

Upewnij się, że zarówno akcesory get, jak i set są obecne podczas zaznaczania poszczególnych akcesoriów jako readonly (CS8664). Ta korekta jest konieczna, ponieważ readonly modyfikator poszczególnych metod dostępu rozróżnia metody dostępu modyfikujące stan i te, które nie, co ma sens tylko wtedy, gdy istnieją oba typy akcesoriów. Jeśli właściwość ma tylko get akcesor, oznacz całą właściwość jako readonly zamiast get akcesora.

Aby uzyskać więcej informacji, zobacz readonly instance members, init słowo kluczowe i Właściwości.

Inicjatory właściwości

• CS8050: Tylko właściwości zaimplementowane automatycznie lub właściwości używające słowa kluczowego "field" mogą mieć inicjatory
• CS8051: Właściwości implementowane automatycznie muszą mieć akcesory 'get'
• CS8053: Właściwości wystąpienia w interfejsach nie mogą mieć inicjatorów

Aby poprawić błędy inicjatora właściwości, zastosuj jedną z następujących zmian na podstawie określonej diagnostyki:

Przekonwertuj właściwość, aby używać składni automatycznie implementowanej, usuwając ciała akcesorów i pozwalając kompilatorowi wygenerować pole zapasowe (CS8050). Ta poprawka jest wymagana, ponieważ tylko właściwości z zarządzanym przez kompilator przechowywaniem mogą mieć inicjalizatory, zapewniając, że inicjowanie ma miejsce przed uruchomieniem jakiejkolwiek logiki dostępowej. Alternatywnie, zmodyfikuj implementacje akcesorów, aby użyć słowa kluczowego field w celu uzyskania dostępu do pola pomocniczego syntetyzowanego przez kompilator. Takie podejście umożliwia użycie inicjalizatora przy zachowaniu niestandardowej logiki dostępu. Jeśli żadna z metod nie jest odpowiednia, usuń inicjator i przypisz wartość w konstruktorze, gdzie masz pełną kontrolę nad sekwencją inicjowania.

Dodaj akcesor get do automatycznie implementowanej właściwości, aby umożliwić odczytywanie zainicjowanej wartości (CS8051). Ta korekta jest wymagana, ponieważ inicjatory ustawiają wartość, która musi być możliwa do odczytu, a właściwość tylko do zapisu narusza to podstawowe oczekiwanie inicjacji właściwości. Jeśli naprawdę potrzebujesz właściwości tylko do zapisu, zaimplementuj jawnie metody dostępu z polem zapasowym i przypisz pole bezpośrednio w konstruktorze zamiast używać inicjatora właściwości.

Usuń inicjator z deklaracji właściwości interfejsu (CS8053). Ta korekta jest niezbędna, ponieważ interfejsy definiują kontrakty na potrzeby implementowania typów, zamiast dostarczać konkretne implementacje z wartościami początkowymi. Jeśli musisz podać wartości domyślne, zaimplementuj właściwość w klasie, która implementuje interfejs, lub użyj domyślnych metod interfejsu (dostępnych w języku C# 8.0 i nowszych), aby podać domyślną implementację.

Aby uzyskać więcej informacji, zobacz Właściwości, Właściwości zaimplementowane automatycznie i słowo kluczowe pola.

Wymagani członkowie

• CS9029: Typy i aliasy nie mogą mieć nazwy "required".
• CS9030: Element członkowski musi być wymagany, ponieważ zastępuje wymagany element członkowski.
• CS9031: Wymagany element członkowski nie może być ukryty przez pochodny element członkowski.
• CS9032: Wymagany członek nie może mieć niższej widoczności ani mieć ustawiającego o niższej widoczności niż typ, który go zawiera.
• CS9033: Nie używaj "System.Runtime.CompilerServices.RequiredMemberAttribute'. Zamiast tego użyj słowa kluczowego "required" dla wymaganych pól i właściwości.
• CS9034: Wymagany członek musi być możliwy do ustawienia.
• CS9035: Wymagany członek musi być ustawiony w inicjatorze obiektu lub konstruktorze dla atrybutu.
• CS9036: Wymagany element członkowski "memberName" musi mieć przypisaną wartość, nie może użyć zagnieżdżonego elementu członkowskiego lub inicjatora kolekcji.
• CS9037: Lista wymaganych członków jest źle sformułowana i nie można jej zinterpretować.
• CS9038: Lista wymaganych elementów członkowskich dla typu podstawowego jest źle sformułowana i nie można jej interpretować. Aby użyć tego konstruktora, zastosuj atrybut "SetsRequiredMembers".
• CS9039: Ten konstruktor musi dodać element "SetsRequiredMembers", ponieważ odwołuje się do konstruktora, który ma ten atrybut.
• CS9040: Typ nie może spełnić ograniczenia "new()" dla parametru w typie ogólnym lub metodzie, ponieważ ma wymagane elementy członkowskie.
• CS9042: Wymagany członek nie powinien być oznaczony jako "ObsoleteAttribute", chyba że typ zawierający jest przestarzały lub wszystkie konstruktory są przestarzałe.
• CS9045: Wymagani członkowie nie są dozwoleni na najwyższym poziomie skryptu lub przesyłania.

Aby poprawić błędy dotyczące wymaganego elementu, zastosuj jedną z następujących zmian zgodnie z konkretną diagnozą.

Unikaj używania required jako nazwy typu lub aliasu (CS9029). Ta korekta jest niezbędna, ponieważ required jest kontekstowym słowem kluczowym w języku C# 11 i nowszym, a użycie go jako nazwy typu powoduje niejednoznaczność w kodzie, w którym może pojawić się słowo kluczowe.

Upewnij się, że pochodne elementy członkowskie utrzymują required modyfikator podczas zastępowania wymaganych elementów członkowskich (CS9030). Ta korekta wymusza kontrakt ustanowiony przez klasę bazową, gwarantując, że wszystkie typy pochodne zachowują te same wymagania inicjowania. Unikaj ukrywania wymaganych członków członkami niewymaganymi w klasach pochodnych (CS9031), ponieważ takie działanie narusza kontrakt inicjowania, którego użytkownicy oczekują dla typu bazowego.

Ustaw wymagane elementy członkowskie co najmniej tak widoczne, jak ich typ zawierający, i upewnij się, że zestawy właściwości są również wystarczająco widoczne (CS9032). Ta korekta zapobiega sytuacjom, w których typ jest publicznie dostępny, ale jego wymagane elementy członkowskie nie mogą być inicjowane ze wszystkich kontekstów, w których typ jest konstruowany.

required Użyj słowa kluczowego zamiast ręcznego stosowania RequiredMemberAttribute (CS9033). Ta korekta gwarantuje, że kompilator generuje poprawne metadane i wymusza wszystkie wymagane reguły składowe, których aplikacja atrybutów ręcznych może nie wykonywać poprawnie.

Upewnij się, że wymagane elementy członkowskie mają ustawione metody dostępu lub są w inny sposób konfigurowalne (CS9034). Ta korekta jest niezbędna, ponieważ wymagane elementy członkowskie muszą zostać zainicjowane podczas tworzenia obiektu, co wymaga dostępu do zapisu. Podczas tworzenia wystąpień zainicjuj wymagane elementy członkowskie bezpośrednio w inicjatorach obiektów (CS9035, CS9036). Należy przypisać wartość do każdego wymaganego członka, zamiast używać zagnieżdżonych inicjalizatorów członkowskich lub inicjalizatorów kolekcji, ponieważ sam wymagany członek musi być ustawiony przed uzyskaniem dostępu do jego właściwości.

SetsRequiredMembers Zastosuj atrybut konstruktorom, które inicjują wszystkie wymagane elementy członkowskie w swoich ciałach (CS9038, CS9039). Ta korekta informuje kompilator, że konstruktor spełnia wymagany kontrakt członkowski, umożliwiając tworzenie obiektów bez inicjatorów obiektów. Jeśli konstruktor tworzy łańcuchy do innego konstruktora z elementem SetsRequiredMembers, musi również mieć atrybut .

Unikaj używania wymaganych członków w typach, które muszą spełniać new() ograniczenie (CS9040), ponieważ konstruktor bez parametrów nie może zagwarantować inicjalizacji wymaganych członków bez inicjalizatora obiektu. Nie oznaczaj wymaganych członków jako przestarzałych, chyba że typ, który je zawiera, lub wszystkie konstruktory są przestarzałe (CS9042), aby uniknąć sytuacji, w których członkowie są wymagani, ale ich użycie jest zniechęcane. Wymagane elementy członkowskie nie są dozwolone w instrukcjach najwyższego poziomu ani kontekstach skryptu (CS9045), ponieważ te konteksty nie obsługują składni inicjowania obiektów potrzebnej do ustawienia wymaganych elementów członkowskich.

Aby uzyskać więcej informacji, zobacz artykuł referencyjny wymaganego modyfikatora oraz przewodnik po inicjowaniu obiektów i kolekcji.

Właściwości zwracające referencje

• CS8145: Właściwości zaimplementowane automatycznie nie mogą być zwracane przez odwołanie
• CS8147: Właściwości zwracane przez odwołanie nie mogą mieć ustawionych metod dostępu

Aby poprawić błędy właściwości zwracanych ref, zastosuj jedną z następujących zmian w oparciu o określoną diagnostykę:

Zaimplementuj właściwość jawnie przy użyciu pola zapasowego i użyj słowa kluczowego ref w wyrażeniu zwracającym akcesora get (CS8145). Ta korekta jest niezbędna, ponieważ automatycznie zaimplementowane właściwości generują prywatne pole zapasowe, którymi kompilator zarządza wewnętrznie. Zwrócenie odwołania do pola prywatnego spowoduje uwidocznienie wewnętrznego przechowywania, do którego wywołujący nie mogą uzyskiwać bezpośredniego dostępu. Aby utworzyć właściwość zwracaną przez odwołanie, zadeklaruj jawne pole i zwróć je ze składnią => ref backingField . Alternatywnie, jeśli nie musisz zwracać odwołania, aby umożliwić bezpośrednią modyfikację pamięci, usuń modyfikator ref z deklaracji właściwości.

Usuń akcesor set z właściwości zwracającej ref (CS8147). Poprawka ta jest wymagana, ponieważ właściwość zwracająca odwołanie już zapewnia zarówno odczyt, jak i zapis poprzez zwrócone odwołanie. Wywołujący mogą bezpośrednio modyfikować wartość poprzez odwołanie, bez potrzeby używania osobnej metody ustawiającej. Dołączenie metody dostępu set spowodowałoby utworzenie dwóch różnych mechanizmów modyfikowania tego samego magazynu, co jest zbędne i może prowadzić do nieporozumień co do tego, którą ścieżkę modyfikacji należałoby wybrać.

Aby uzyskać więcej informacji, zobacz zwroty ref i lokalne zmienne ref i Właściwości.