Fehler und Warnungen im Zusammenhang mit Eigenschaftendeklarationen

Sie können auf die folgenden Fehler im Zusammenhang mit Eigenschaftendeklarationen stoßen:

• CS0200: Eigenschaft oder Indexer des Typs „Eigenschaft“ kann nichts zugewiesen werden, da schreibgeschützt
• CS0273: Der Zugriffsmodifizierer des Accessor „Accessor“ muss restriktiver sein als die Eigenschaft oder der Indexer „Eigenschaft“
• CS0274: Es können keine Zugriffsmodifizierer für beide Accessoren der Eigenschaft oder des Indexers „Eigenschaft“ angegeben werden
• CS0275: "accessor": Barrierefreiheitsmodifizierer werden möglicherweise nicht für Accessoren in einer Schnittstelle verwendet.
• CS0276: „Eigenschaft“: Zugriffsmodifizierer für Accessoren können nur verwendet werden, wenn die Eigenschaft oder der Indexer sowohl einen Get- als auch einen Set-Accessor hat
• CS0442: 'property': Abstrakte Eigenschaften können keine privaten Accessoren haben
• CS0544: 'property': kann nicht außer Kraft gesetzt werden, weil 'member' keine Eigenschaft ist.
• CS0545: 'function' : kann nicht außer Kraft gesetzt werden, da 'property' keinen überschreibbaren Get-Accessor hat.
• CS0546: „Accessor“: Kann nicht überschrieben werden, weil „Eigenschaft“ keinen überschreibbaren Set-Accessor hat
• CS0547: 'property': Eigenschaft oder Indexer darf keinen ungültigen Typ aufweisen
• CS0548: '„Eigenschaft“: Die Eigenschaft oder der Indexer muss mindestens einen Accessor haben
• CS0571: 'Funktion': Der Operator oder Accessor kann nicht explizit aufgerufen werden
• CS0610: Feld oder Eigenschaft darf nicht vom Typ 'Type' sein.
• CS0840: „Eigenschaftsname“ muss einen Textkörper deklarieren, da er nicht als abstrakt oder extern gekennzeichnet ist. Automatisch implementierte Eigenschaften müssen sowohl Get- als auch Set-Accessoren definieren.
• CS1014: Ein Get- oder Set-Accessor wird erwartet
• CS1043: { oder ; erwartet
• CS1715: „Typ“: Der Typ muss „Ty“ sein, um mit dem überschriebenen Element „Mitglied“ übereinzustimmen.
• CS8050: Nur automatisch implementierte Eigenschaften oder Eigenschaften, die das Schlüsselwort "Field" verwenden, können Initialisierer haben.
• CS8051: Automatisch implementierte Eigenschaften müssen Über Accessoren verfügen.
• CS8053: Instanzeigenschaften in Schnittstellen können keine Initialisierer haben.
• CS8080: Automatisch implementierte Eigenschaften müssen alle Accessoren der überschriebenen Eigenschaft überschreiben.
• CS8145: Automatisch implementierte Eigenschaften können nicht durch Verweis zurückgegeben werden.
• CS8147: Eigenschaften, die durch Verweis zurückgegeben werden, können keine Set-Accessoren haben.
• CS8341: Automatisch implementierte Instanzeigenschaften in schreibgeschützten Strukturen müssen schreibgeschützt sein.
• CS8657: Statisches Mitglied 'member' kann nicht als readonly gekennzeichnet werden.
• CS8658: Der automatisch implementierte Accessor "set" "accessor" kann nicht als "readonly" gekennzeichnet werden.
• CS8659: Die automatisch implementierte Eigenschaft "Property" kann nicht als "readonly" gekennzeichnet werden, da sie über einen "set"-Accessor verfügt.
• CS8660: „Readonly“-Modifizierer können nicht sowohl für die Eigenschaft oder den Indexer „Eigenschaft“ als auch deren Accessor angegeben werden. Entfernen Sie einen davon.
• CS8661: Sie können den „readonly“-Modifizierer nicht für beide Zugriffsmethoden der Eigenschaft oder des Indexers „Eigenschaft“ übernehmen. Setzen Sie stattdessen den ‚readonly‘-Modifizierer direkt auf die Eigenschaft.
• CS8664: „Eigenschaft: „readonly“ kann nur für Accessoren verwendet werden, wenn die Eigenschaft oder der Indexer sowohl über einen Get- als auch einen Set-Accessor verfügt
• CS8852: Init-only-Eigenschaft oder Indexer 'property' kann nur in einem Objektinitialisierer oder auf „this“ oder „base“ in einem Instanzkonstruktor oder einem ‚init‘-Accessor zugewiesen werden.
• CS8853: „Mitglied“ muss durch Initialisierung nur mit dem überschriebenen Mitglied „Mitglied“ übereinstimmen.
• CS8855: Accessoren „Accessor“ und „Accessor“ sollten entweder beide init-only sein oder keiner von beiden.
• CS8856: Der Accessor "init" ist für statische Member ungültig.
• CS8903: "init"-Accessoren können nicht als "readonly" gekennzeichnet werden. Markieren Sie stattdessen die "Eigenschaft" als readonly.
• CS9029: Typen und Aliase können nicht als "erforderlich" bezeichnet werden.
• CS9030: „Mitglied“ muss erforderlich sein, da es das erforderliche Mitglied „Mitglied“ überschreibt.
• CS9031: Erforderliches Mitglied „Mitglied“ kann nicht durch „Mitglied“ verdeckt werden.
• CS9032: Erforderliches Element kann nicht weniger sichtbar sein oder einen Setter weniger sichtbar als der enthaltende Typ aufweisen.
• CS9033: Verwenden Sie nicht "System.Runtime.CompilerServices.RequiredMemberAttribute'. Verwenden Sie stattdessen das Schlüsselwort "required" für erforderliche Felder und Eigenschaften.
• CS9034: Das erforderliche Mitglied muss festlegbar sein.
• CS9035: Erforderlicher Member muss im Objektinitialisierer oder Attributkonstruktor festgelegt werden.
• CS9036: Erforderliches Element "memberName" muss einem Wert zugewiesen werden, es kann kein geschachteltes Element oder ein Sammlungsinitialisierer verwendet werden.
• CS9037: Die Liste der erforderlichen Member für "type" ist falsch formatiert und kann nicht interpretiert werden.
• CS9038: Die Liste der erforderlichen Member für den Basistyp "Typ" ist falsch formatiert und kann nicht interpretiert werden. Um diesen Konstruktor zu verwenden, wenden Sie das Attribut 'SetsRequiredMembers' an.
• CS9039: Dieser Konstruktor muss 'SetsRequiredMembers' hinzufügen, da er mit einem Konstruktor, der dieses Attribut aufweist, verkettet ist.
• CS9040: Der Typ kann die 'new()'-Einschränkung für den Parameter im generischen Typ oder in der Methode nicht erfüllen, da er erforderliche Mitglieder hat.
• CS9042: Erforderliches Element sollte nicht mit 'ObsoleteAttribute' zugeschrieben werden, es sei denn, der enthaltende Typ ist veraltet, oder alle Konstruktoren sind veraltet.
• CS9045: Erforderliche Mitglieder sind auf der obersten Ebene eines Skripts oder einer Übermittlung nicht zulässig.
• CS9258: In dieser Sprachversion bindet das Schlüsselwort "field" an ein synthetisiertes Sicherungsfeld für die Eigenschaft. Um das Generieren eines synthetisierten Sicherungsfelds zu vermeiden und stattdessen auf das vorhandene Element zu verweisen, verwenden Sie stattdessen "this.field" oder ""@field.
• CS9263: Eine partielle Eigenschaft kann nicht sowohl für die Definition als auch für die Implementierung einen Initialisierer haben.

Die folgenden Warnungen können bei feldgestützten Eigenschaften generiert werden:

• CS9264: Nicht-nullbare Eigenschaft „Eigenschaft“ muss beim Beenden des Konstruktors einen Wert ungleich null enthalten. Erwägen Sie, den „erforderlichen“ Modifizierer hinzuzufügen und die Eigenschaft als nullbar zu deklarieren oder den Fall sicher zu behandeln, in dem „field“ Null im Accessor „get“ ist.
• CS9266: Der Accessor „Accessor“ der Eigenschaft „Eigenschaft“ sollte „field“ verwenden, da der andere Accessor es verwendet.
• CS9273: In dieser Sprachversion ist "field" ein Schlüsselwort innerhalb eines Eigenschaftsaccessors. Benennen Sie die Variable um, oder verwenden Sie stattdessen den Bezeichner "@field".

In den folgenden Abschnitten werden die Ursachen und Abhilfemaßnahmen für diese Fehler und Warnungen erläutert.

Accessorenzugänglichkeit

• CS0273: Der Zugriffsmodifizierer des Accessor „Accessor“ muss restriktiver sein als die Eigenschaft oder der Indexer „Eigenschaft“
• CS0274: Es können keine Zugriffsmodifizierer für beide Accessoren der Eigenschaft oder des Indexers „Eigenschaft“ angegeben werden
• CS0275: "accessor": Barrierefreiheitsmodifizierer werden möglicherweise nicht für Accessoren in einer Schnittstelle verwendet.
• CS0276: „Eigenschaft“: Zugriffsmodifizierer für Accessoren können nur verwendet werden, wenn die Eigenschaft oder der Indexer sowohl einen Get- als auch einen Set-Accessor hat
• CS0442: 'property': Abstrakte Eigenschaften können keine privaten Accessoren haben

Diese Fehler setzen die Regeln für Zugriffsmodifizierer bei Eigenschafts- und Indexer-Accessoren durch. Die vollständigen Regeln finden Sie unter Einschränkung der Accessor-Zugänglichkeit und Accessors in der C#-Spezifikation. Um diese Fehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

• Verwenden Sie einen Zugriffsmodifizierer, der restriktiver ist als die deklarierte Sichtbarkeit der Eigenschaft (CS0273). Zum Beispiel kann eine internal Eigenschaft über einen private Set-Accessor verfügen, aber nicht über einen public. Die Zugänglichkeit des Accessors muss eine echte Teilmenge der Zugänglichkeit der Eigenschaft sein.
• Wenden Sie einen Zugriffsmodifizierer nur auf einen der beiden Accessoren (CS0274) an. Die Eigenschaftsdeklaration selbst richtet die Standardzugänglichkeit für beide Accessoren ein, und nur ein Accessor kann sich von dieser Standardeinstellung unterscheiden. Setzen Sie den Zugriffsmodifizierer auf die Zugriffsmethoden, die eingeschränkten Zugriff benötigen.
• Entfernen Sie Zugriffsmodifizierer aus Accessoren in Schnittstelleneigenschaftsdeklarationen (CS0275). Schnittstellenmitglieder definieren einen öffentlichen Vertrag, und Zugriffsmodifizierer für einzelne Accessoren sind nicht zulässig. Wenn Sie den Zugriff einschränken müssen, wenden Sie stattdessen die Einschränkung in der implementierenden Klasse an.
• Fügen Sie sowohl einen Accessor get als auch einen set der Eigenschaft hinzu, bevor Sie für einen davon einen Zugriffsmodifizierer (CS0276) übernehmen. Zugriffsmodifizierer für Accessoren unterscheiden die Sichtbarkeit eines Accessors von der anderen, was erfordert, dass beide Accessoren vorhanden sind. Wenn die Eigenschaft nur über einen Accessor verfügt, entfernen Sie den Zugriffsmodifikator von diesem.
• Ändern Sie den Zugriffsmodifizierer für abstrakte Eigenschaftsaccessoren von private auf einen weniger restriktiven Modifizierer (CS0442). Abstrakte Member müssen für abgeleitete Klassen zugänglich sein, damit diese Klassen Implementierungen bereitstellen können. Verwenden Sie protected, internaloder protected internal anstelle von private.

Weitere Informationen finden Sie unter Einschränken der Zugänglichkeit von Accessoren und Eigenschaften.

Syntax der Eigenschaftsdeklaration

• CS0547: „Eigenschaft“: Die Eigenschaft oder der Indexer dürfen nicht den Typ void haben
• CS0548: „Eigenschaft“: Die Eigenschaft oder der Indexer muss mindestens einen Accessor haben.
• CS0571: 'Function': Nicht explizit den Operator oder Accessor aufrufen
• CS0610: Feld oder Eigenschaft darf nicht vom Typ 'Type' sein.
• CS0840: „Eigenschaftsname“ muss einen Textkörper deklarieren, da er nicht als abstrakt oder extern gekennzeichnet ist. Automatisch implementierte Eigenschaften müssen sowohl Get- als auch Set-Accessoren definieren.
• CS1014: Es wird ein Get- oder Set-Accessor erwartet
• CS1043: { oder ; erwartet

Diese Fehler erzwingen die strukturellen Anforderungen von Eigenschaften- und Indexerdeklarationen. Die vollständigen Regeln finden Sie im Abschnitt"Eigenschaften" der C#-Spezifikation. Um diese Fehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

• Ändern Sie den Eigenschaftstyp von void zu einem gültigen Typ wie CS0547. Eigenschaften und Indexer stellen Ausdrücke dar und void ist kein gültiger Ausdruckstyp. Wählen Sie den entsprechenden Typ für die Daten aus, die die Eigenschaft darstellt.
• Fügen Sie mindestens einen Accessor (get, setoder init) zur Eigenschaftsdeklaration (CS0548) hinzu. Eine Eigenschaft ohne Accessoren hat keine Möglichkeit, dessen Wert zu lesen oder zu schreiben. Schließen Sie einen get-Accessor, einen set-Accessor oder beide init-Accessoren ein.
• Greifen Sie auf Eigenschaften mithilfe der Eigenschaftssyntax zu, anstatt Accessormethoden direkt aufzurufen (CS0571). Eigenschaftenaccessoren kompilieren zu Methoden namens get_PropertyName und set_PropertyName, rufen diese Methoden jedoch über die Eigenschaftssyntax (obj.Property und obj.Property = value) auf. Das gleiche Prinzip gilt für Operatoren. Verwenden Sie operatorsyntax (++obj) anstelle von Aufrufen von Methoden wie op_Increment.
• Ändern Sie den Feld- oder Eigenschaftentyp von einem eingeschränkten Typ in einen zulässigen Typ (CS0610). Bestimmte Typen wie TypedReference und ArgIterator können nicht als Felder oder Eigenschaften verwendet werden. Diese Typen können weiterhin als Methodenparameter oder lokale Variablen verwendet werden.
• Deklarieren Sie für eine schreibgeschützte Eigenschaft eine automatisch implementierte Eigenschaft get-only. Fügen Sie andernfalls sowohl get als auch set zu automatisch implementierten Eigenschaftsdeklarationen hinzu, oder stellen Sie explizite Accessor-Textkörper (CS0840) bereit. Verwenden Sie für eine Eigenschaft, die eine benutzerdefinierte Logik benötigt, das Schlüsselwort field, das in C# 13 hinzugefügt wurde, um auf das vom Compiler synthetisierte Sicherungsfeld in Ihrem Accessortextkörper zuzugreifen. Entfernen Sie für die Eigenschaften abstract oder extern die Accessortextkörper, da die Implementierung woanders bereitgestellt wird. Teilen Sie die Deklaration und Implementierung für partial Eigenschaften auf teilweise Typdeklarationen.
• Stellen Sie sicher, dass der Eigenschaftskörper nur gültige Accessor-Schlüsselwörter enthält – get, set oder init (CS1014). Eigenschaftstextkörper können keine beliebige Anweisungen oder Mitgliederdeklarationen enthalten. Verschieben Sie Felder und Methoden vom Eigenschafts- in den Klassen- oder Strukturtextkörper.
• Verwenden Sie die richtige Syntax für Eigenschaftsaccessoren mit geschweiften Klammern oder AusdrucksTextkörper (CS1043). Accessortextkörper müssen geschweifte Klammern { } verwenden, AusdrucksTextkörper-Accessoren müssen die Syntax => verwenden und automatisch implementierte Eigenschaften müssen mit einem Semikolon nach dem Accessor-Token enden.

Weitere Informationen finden Sie unter Eigenschaften, automatischimplementierte Eigenschaften und Verwenden von Eigenschaften.

Eigenschaftsüberschreibungen

• CS0544: „Eigenschaft“: Kann nicht überschrieben werden, da „Mitglied“ keine Eigenschaft ist
• CS0545: „Funktion“: Kann nicht überschreiben werden, weil „Eigenschaft“ keinen überschreibbaren Get-Accessor hat.
• CS0546: „Accessor“: Kann nicht überschreiben werden, weil „Eigenschaf“ keinen überschreibbaren Set-Accessor hat
• CS1715: „Typ“: Der Typ muss „Ty“ sein, um mit dem überschriebenen Element „Mitglied“ übereinzustimmen
• CS8080: Automatisch implementierte Eigenschaften müssen alle Accessoren der überschriebenen Eigenschaft überschreiben.

Diese Fehler setzen die Regeln für das Überschreiben von Eigenschaften in abgeleiteten Klassen durch. Die vollständigen Regeln finden Sie unter Vererbung und im Abschnitt Virtuell, Versiegelt, Außerkraftsetzung und Abstrakte Accessoren der C#-Spezifikation. Um diese Fehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

• Stellen Sie sicher, dass das Element, das Sie überschreiben, eine Eigenschaft ist, kein Feld oder eine Methode (CS0544). Das override-Schlüsselwort bei einer Eigenschaft kann nur auf eine virtual-, abstract- oder override-Eigenschaft in einer Basisklasse abzielen. Verwenden Sie das Schlüsselwort new anstelle von override, um ein Mitglied ohne Eigenschaft mit einer Eigenschaft zu überschreiben.
• Überschreiben Sie nur die Accessoren, die in der Deklaration der Basisklasse vorhanden sind (CS0545, CS0546). Sie können keinen Eigenschaftsaccessor überschreiben, der in der Basisklasse nicht vorhanden oder zugänglich ist, da keine virtuelle Methode zum Überschreiben vorhanden ist. Wenn die Basisklasseneigenschaft nur über einen get Accessor verfügt, können Sie keinen set Accessor durch eine Überschreibung hinzufügen. Fügen Sie der Basisklasse entweder den fehlenden Accessor hinzu und markieren Sie ihn mit virtual, oder verwenden Sie new, um die Basisklasseneigenschaft mit einer neuen Eigenschaftsdefinition auszublenden.
• Stimmen Sie den Typ der überschriebenen Eigenschaft mit dem Typ des überschriebenen Elements (CS1715) ab. Schreibgeschützte Eigenschaften (get-only) unterstützen kovariante Rückgabetypen ab C# 9, sodass die Überschreibung einen stärker abgeleiteten Typ zurückgeben kann. Eigenschaften mit einem set oder init accessor erfordern jedoch eine genaue Typ-Übereinstimmung, da der Setter Werte des deklarierten Typs akzeptiert. Wenn Sie einen anderen Typ für eine Eigenschaft mit einem Setter benötigen, ändern Sie den Eigenschaftstyp in der abgeleiteten Klasse entsprechend der Basisklassendeklaration, oder entfernen Sie den Setter, und verwenden Sie stattdessen einen kovarianten Rückgabetyp.
• Schließen Sie alle Accessoren aus der Basiseigenschaft ein, wenn sie mit einer automatisch implementierten Eigenschaft (CS8080) überschrieben werden. Automatisch implementierte Eigenschaften generieren sowohl Speicher- als auch Accessorimplementierungen, sodass sie alle Accessoren außer Kraft setzen müssen, die in der Basisklasse vorhanden sind. Wenn die Basiseigenschaft sowohl get als auch set hat, muss die automatisch implementierte Außerkraftsetzung ebenfalls über beide verfügen. Um nur bestimmte Accessoren zu überschrieben, implementieren Sie die Eigenschaft mit expliziten Accessor-Textkörpern und einem expliziten Sicherungsfeld, anstatt die automatische Implementierung zu verwenden.

Weitere Informationen finden Sie unter Vererbung, Eigenschaften und Verwenden von Eigenschaften.

Feldgestützte Eigenschaften

• CS9258: In dieser Sprachversion bindet das Schlüsselwort "field" an ein synthetisiertes Sicherungsfeld für die Eigenschaft. Um das Generieren eines synthetisierten Sicherungsfelds zu vermeiden und stattdessen auf das vorhandene Element zu verweisen, verwenden Sie stattdessen "this.field" oder ""@field.
• CS9263: Eine partielle Eigenschaft kann nicht sowohl für die Definition als auch für die Implementierung einen Initialisierer haben.
• CS9264: Die nicht-nullbare Eigenschaft 'property' muss beim Verlassen des Konstruktors einen nicht-null-Wert enthalten. Erwägen Sie, den 'required'-Modifizierer hinzuzufügen oder die Eigenschaft als nullable zu deklarieren oder den Fall, dass 'field' im Accessor 'get' null ist, sicher zu handhaben.
• CS9266: Der Accessor „Accessor“ der Eigenschaft „Eigenschaft“ sollte „field“ verwenden, da der andere Accessor es verwendet.
• CS9273: In dieser Sprachversion ist "field" ein Schlüsselwort innerhalb eines Eigenschaftsaccessors. Benennen Sie die Variable um, oder verwenden Sie stattdessen den Bezeichner "@field".

Um Fehler bei Eigenschaften, die durch Felder gesichert sind, zu korrigieren, wenden Sie basierend auf der spezifischen Diagnose eine der folgenden Änderungen an:

• Benennen Sie jede Variable mit dem Namen field in einen anderen Bezeichner um, oder verwenden Sie die @field-Escape-Syntax, um auf Ihre Variable (CS9258, CS9273) zu verweisen. Diese Korrektur ist erforderlich, da field ein kontextabhängiges Schlüsselwort innerhalb von Eigenschaftsaccessoren in C# 13 und höher ist, wobei es sich auf das vom Compiler erzeugte Sicherungsfeld bezieht. Wenn Sie auf ein vorhandenes Mitglied mit dem Namen field zugreifen möchten, das anstelle des synthetisierten Sicherungsfelds benannt ist, qualifizieren Sie es mit this.field, um den Verweis zu disambiguieren.
• Entfernen Sie den Initialisierer aus der partiellen Eigenschaftsdefinition oder der Implementierung, wobei nur eine (CS9263) beibehalten wird. Diese Korrektur ist erforderlich, da das Zulassen von Initialisierern an beiden Stellen zu Mehrdeutigkeiten führen könnte, welcher Wert verwendet werden soll, und könnte dazu führen, dass das Hintergrundfeld zweimal mit potenziell unterschiedlichen Werten initialisiert wird.
• Fügen Sie der Eigenschaftsdeklaration das [field: MaybeNull, AllowNull] Attribut hinzu, um anzugeben, dass das Sicherungsfeld als nullable behandelt werden soll (CS9264). Diese Korrektur richtet die Erwartungen an die Nullierbarkeit zwischen dem Eigenschaftentyp und dem vom Compiler synthetisierten Sicherungsfeld aus, indem sie den Konflikt auflöst, dass die Eigenschaft als nicht-nullbar deklariert wird, obwohl die Verwendung des field-Schlüsselworts darauf hindeutet, dass sie null sein könnte. Alternativ können Sie den Eigenschaftstyp in Nullwerte ändern, den required Modifizierer hinzufügen, um die Initialisierung sicherzustellen oder die Eigenschaft im Konstruktor zu initialisieren.
• Verwenden Sie entweder das field-Schlüsselwort konsistent in beiden Accessoren oder verwenden Sie ein explizites Sicherungsfeld in beiden Accessoren (CS9266). Diese Korrektur verhindert potenzielle Fehler, bei denen ein Accessor das compilersynthetisierte Sicherungsfeld ändert, während der andere Accessor einen anderen Speicherort ändert, was zu einem inkonsistenten Eigenschaftenverhalten führt.

Weitere Informationen finden Sie unter Feldschlüsselwort und Partielle Eigenschaften.

Readonly-Eigenschaften

• CS0200: Einer Eigenschaft oder einem Indexer „Eigenschaft“ kann nichts zugewiesen werden, da schreibgeschützt
• CS8341: Automatisch implementierte Instanzeigenschaften in schreibgeschützten Strukturen müssen schreibgeschützt sein.
• CS8657: Statisches Mitglied „Mitglied“ kann nicht als „readonly“ gekennzeichnet werden.
• CS8658: Der automatisch implementierte Accessor "set" "accessor" kann nicht als "readonly" gekennzeichnet werden.
• CS8659: Die automatisch implementierte Eigenschaft "Property" kann nicht als "readonly" gekennzeichnet werden, da sie über einen "set"-Accessor verfügt.
• CS8660: „Readonly“-Modifizierer können nicht sowohl für die Eigenschaft oder den Indexer „Eigenschaft“ als auch deren Accessor angegeben werden. Entfernen Sie einen davon.
• CS8661: Sie können den „readonly“-Modifizierer nicht für beide Zugriffsmethoden der Eigenschaft oder des Indexers „Eigenschaft“ übernehmen. Setzen Sie stattdessen den ‚readonly‘-Modifizierer direkt auf die Eigenschaft.
• CS8664: „Eigenschaft: „readonly“ kann nur für Accessoren verwendet werden, wenn die Eigenschaft oder der Indexer sowohl über einen Get- als auch einen Set-Accessor verfügt

Übernehmen Sie zur Behebung von Fehlern in „Readonly“-Eigenschaften eine der folgenden Änderungen basierend auf der spezifischen Diagnose:

• Fügen Sie der Eigenschaft einen set- oder init-Accessor hinzu, damit die Eigenschaft schreibbar ist (CS0200). Diese Korrektur ist erforderlich, da Eigenschaften ohne Set-Accessoren schreibgeschützt (read-only) sind und nur im Konstruktor oder Feldinitialisierer des deklarierenden Typs zugewiesen werden können. Wenn die Eigenschaft während der Objektinitialisierung festgelegt werden muss, aber anschließend unveränderlich ist, verwenden Sie einen init Accessor anstelle eines set Accessors. Wenn die Eigenschaft read-only bleiben soll, verschieben Sie die Zuweisung in den Konstruktor, wo die Initialisierung erlaubt ist, oder überlegen Sie, ob die Zuweisung überhaupt notwendig ist.
• Markieren Sie automatisch implementierte Instanzeigenschaften als readonly wenn Sie sie innerhalb einer readonly struct (CS8341) deklarieren. Diese Korrektur erzwingt den unveränderlichen Vertrag der enthaltenden Struktur, um sicherzustellen, dass alle Instanzmitglieder die readonly Garantie respektieren. Wenn die Eigenschaft änderbar sein muss, entfernen Sie entweder den readonly Modifizierer aus der Strukturerklärung, oder implementieren Sie die Eigenschaft mit einem expliziten Stützfeld und Accessor-Methoden, ohne den Instanzzustand zu verändern.
• Entfernen Sie den readonly Modifizierer aus statischen Eigenschaften- oder Accessordeklarationen (CS8657). Diese Korrektur ist erforderlich, da der readonly Modifizierer nur für Instanzenmitglieder von Strukturen gilt, um anzugeben, dass sie den Instanzstatus nicht ändern, und statische Mitglieder keinen Instanzstatus haben, der geschützt werden müsste. Wenn Sie eine statische Readonly-Eigenschaft benötigen, lassen Sie einfach den Accessor set weg, anstatt den Modifizierer readonly zu verwenden.
• Entfernen Sie den readonly Modifizierer aus automatisch implementierten set Accessoren, oder wenden Sie ihn nur auf den get Accessor an (CS8658). Diese Korrektur ist erforderlich, da set Accessoren den Zustand von Natur aus verändern, was dem Zweck des readonly Modifikators widerspricht, der garantiert, dass keine Änderung des Instanzzustands erfolgt. Wenn Sie eine Eigenschaft benötigen, die während der Initialisierung festgelegt werden kann, aber danach schreibgeschützt bleibt, verwenden Sie einen init Accessor anstelle eines set Accessors.
• Entfernen Sie den readonly Modifizierer aus der Eigenschaftsdeklaration, wenn die Eigenschaft über einen set Accessor (CS8659) verfügt. Diese Korrektur ist erforderlich, da Eigenschaften mit set Accessoren den Instanzstatus ändern können, der gegen die readonly Garantie verstößt. Wenn Sie nur Einstellungen zum Zeitpunkt der Initialisierung benötigen, ersetzen Sie den Accessor set durch einen Accessor init oder entfernen Sie den Accessor set vollständig, um die Eigenschaft tatsächlich schreibgeschützt zu machen.
• Platzieren Sie den Modifizierer readonly entweder in die Eigenschaftsdeklaration oder in einzelne Accessoren, aber nicht in beide (CS8660, CS8661). Diese Korrektur verhindert redundante Modifiziererdeklarationen, die Verwirrung darüber erzeugen könnten, welche Modifizierer Vorrang haben. Wenn Sie bestimmte Accessoren als readonlykennzeichnen möchten, entfernen Sie den Modifizierer aus der Eigenschaftendeklaration, und platzieren Sie ihn nur auf den Accessoren. Wenn alle Accessoren readonly sein sollen, markieren Sie die Eigenschaft selbst anstelle einzelner Accessoren.
• Stellen Sie sicher, dass sowohl get- als auch set-Accessoren vorhanden sind, wenn Sie einzelne Accessoren als readonly (CS8664) markieren. Diese Korrektur ist erforderlich, da der readonly Modifizierer bei einzelnen Accessoren zwischen solchen unterscheidet, die den Zustand ändern, und solchen, die dies nicht tun, was nur sinnvoll ist, wenn beide Accessortypen existieren. Wenn die Eigenschaft nur über einen get Accessor verfügt, markieren Sie die gesamte Eigenschaft als readonly anstelle des einzelnen Accessors.

Weitere Informationen finden Sie unter readonly instance members, init keyword, and Properties.

Init-only-Eigenschaften

• CS8852: Die Init-only-Eigenschaft oder der Indexer 'property' kann nur in einem Objektinitialisierer oder über 'this' oder 'base' in einem Instanzkonstruktor oder einem 'init'-Accessor zugewiesen werden.
• CS8853: „Mitglied“ muss durch Initialisierung nur mit dem überschriebenen Mitglied „Mitglied“ übereinstimmen
• CS8855: Accessoren „Accessor“ und „Accessor“ sollten entweder beide init-only sein oder keiner von beiden
• CS8856: Der Accessor "init" ist für statische Member ungültig.
• CS8903: „init“-Accessoren können nicht als „readonly“ gekennzeichnet werden. Markieren Sie stattdessen die „Eigenschaft“ als „readonly“.

Diese Fehler setzen die Regeln für den init Accessor durch, der die unveränderliche Objektinitialisierung ermöglicht. Die vollständigen Regeln finden Sie unter init-Schlüsselwort. Um diese Fehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

• Verschieben Sie Zuweisungen zu init-only-Eigenschaften in einen Objektinitialisierer, einen Konstruktor oder einen Accessor init (CS8852). Nur-Init-Eigenschaften können nach Abschluss der Objektkonstruktion nicht zugewiesen werden. Weisen Sie den Wert im Konstruktortext, einem init Accessor oder einem Objektinitialisierungsausdruck (new MyType { Property = value }) zu. Wenn Sie die Eigenschaft nach der Konstruktion zuweisen müssen, ändern Sie den Accessor init zu einem Accessor set.
• Stimmen Sie den Accessor init oder set beim Überschreiben einer Eigenschaft ab (CS8853). Wenn die Basisklasseneigenschaft einen init-Accessor verwendet, muss die überschreibende Eigenschaft ebenfalls init verwenden. Ebenso, wenn die Basis setverwendet, muss die Überschreibung set verwenden. Diese Konsistenz stellt sicher, dass der durch den Basistyp festgelegte Unveränderlichkeitsvertrag in abgeleiteten Typen beibehalten wird.
• Verwenden Sie dieselbe Accessorart (init oder set) für beide Accessoren in einer expliziten Schnittstellenimplementierung (CS8855). Wenn ein Typ explizit zwei Schnittstellen implementiert, die dieselbe Eigenschaft deklarieren, müssen beide Accessorimplementierungen zustimmen: beide verwenden init oder beide verwenden set.
• Entfernen Sie den init Accessor aus statischen Eigenschaftsdeklarationen, oder ändern Sie ihn in einen set Accessor (CS8856). Der init Accessor ist beispielsweise für Initialisierungsmuster konzipiert, die an die Objektkonstruktion gebunden sind, und statische Elemente nehmen nicht an der Objektinitialisierung teil. Verwenden Sie einen set Accessor für veränderbare statische Eigenschaften, oder entfernen Sie den Setter vollständig für nur lesbare statische Eigenschaften.
• Entfernen Sie den readonly Modifizierer aus dem init Accessor (CS8903). Der readonly Modifizierer für ein Strukturmitglied garantiert, dass das Mitglied die Strukturinstanz nicht verändert. Da ein init Accessor dem Instanzstatus zuweist, wird die Struktur inhärent verändert und kann nicht als readonly markiert werden. Um den get Accessor readonlyzu machen, wenden Sie den readonly Modifizierer nur auf den get Accessor an.

Weitere Informationen finden Sie unter "Init"-Schlüsselwort und "Object and Collection Initializers".

Eigenschaftsinitialisierer

• CS8050: Nur automatisch implementierte Eigenschaften oder Eigenschaften, die das Schlüsselwort "Field" verwenden, können Initialisierer haben.
• CS8051: Automatisch implementierte Eigenschaften müssen Über Accessoren verfügen.
• CS8053: Instanzeigenschaften in Schnittstellen können keine Initialisierer haben.

Wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an, um Eigenschaftsinitialisiererfehler zu beheben:

• Konvertieren Sie die Eigenschaft zur Verwendung automatisch implementierter Eigenschaften, indem Sie die Accessoren entfernen und den Compiler das Rückfeld generieren lassen (CS8050). Diese Korrektur ist erforderlich, da nur Eigenschaften mit vom Compiler verwaltetem Speicher Initialisierer aufweisen können, um sicherzustellen, dass die Initialisierung erfolgt, bevor eine Accessorlogik ausgeführt wird. Alternativ können Sie die Accessorimplementierungen ändern, um das field Schlüsselwort für den Zugriff auf das compilersynthetisierte Sicherungsfeld zu verwenden. Dieser Ansatz aktiviert den Initialisierer und behält gleichzeitig die benutzerdefinierte Accessorlogik bei. Wenn keine der beiden Ansätze geeignet ist, entfernen Sie den Initialisierer, und weisen Sie stattdessen den Wert in einem Konstruktor zu, in dem Sie vollzugriff auf die Initialisierungssequenz haben.
• Fügen Sie der automatisch implementierten Eigenschaft einen get Accessor hinzu, um das Lesen des initialisierten Werts (CS8051) zu ermöglichen. Diese Korrektur ist erforderlich, da Initialisierer einen Wert festlegen, der abgerufen werden muss, und eine schreibgeschützte Eigenschaft verstößt gegen diese grundlegende Erwartung der Eigenschaftsinitialisierung. Wenn Sie wirklich eine schreibgeschützte Eigenschaft benötigen, implementieren Sie die Accessoren explizit mit einem Sicherungsfeld, und weisen Sie das Feld direkt in einem Konstruktor zu, anstatt einen Eigenschaftsinitialisierer zu verwenden.
• Entfernen Sie den Initialisierer aus Schnittstelleneigenschaftendeklarationen (CS8053). Diese Korrektur ist erforderlich, da Schnittstellen Verträge für die Implementierung von Typen definieren, anstatt konkrete Implementierungen mit Anfangswerten bereitzustellen. Wenn Sie Standardwerte bereitstellen müssen, implementieren Sie die Eigenschaft in einer Klasse, die die Schnittstelle implementiert, oder verwenden Sie Standardschnittstellenmethoden (verfügbar in C# 8.0 und höher), um eine Standardimplementierung bereitzustellen.

Weitere Informationen finden Sie unter "Eigenschaften", " Auto-Implementierte Eigenschaften" und " Feldschlüsselwort".

Erforderliche Mitglieder

• CS9029: Typen und Aliase können nicht als "erforderlich" bezeichnet werden.
• CS9030: „Mitglied“ muss erforderlich sein, da es das erforderliche Mitglied „Mitglied“ überschreibt
• CS9031: Das erforderliche Element 'member' kann nicht durch 'member' verborgen werden.
• CS9032: Erforderliches Mitglied darf nicht weniger sichtbar sein oder einen Setter haben, der weniger sichtbar ist als der enthaltende Typ.
• CS9033: Verwenden Sie nicht "System.Runtime.CompilerServices.RequiredMemberAttribute'. Verwenden Sie stattdessen das Schlüsselwort "required" für erforderliche Felder und Eigenschaften.
• CS9034: Erforderliche Mitglied muss festlegbar sein.
• CS9035: Erforderliche Mitglied muss im Objektinitialisierer oder Attributkonstruktor festgelegt werden.
• CS9036: Erforderliches Element "memberName" muss einem Wert zugewiesen werden, es kann kein geschachteltes Element oder ein Sammlungsinitialisierer verwendet werden.
• CS9037: Die Liste der erforderlichen Member für "type" ist falsch formatiert und kann nicht interpretiert werden.
• CS9038: Die Liste der erforderlichen Member für den Basistyp "Typ" ist falsch formatiert und kann nicht interpretiert werden. Um diesen Konstruktor zu verwenden, wenden Sie das Attribut 'SetsRequiredMembers' an.
• CS9039: Dieser Konstruktor muss 'SetsRequiredMembers' hinzufügen, da er mit einem Konstruktor, der dieses Attribut aufweist, verkettet ist.
• CS9040: Der Typ kann die Einschränkung 'new()' auf dem Parameter des generischen Typs oder der Methode nicht erfüllen, da er erforderliche Mitglieder besitzt.
• CS9042: Erforderliches Element sollte nicht mit 'ObsoleteAttribute' zugeschrieben werden, es sei denn, der enthaltende Typ ist veraltet, oder alle Konstruktoren sind veraltet.
• CS9045: Erforderliche Mitglieder sind auf der obersten Ebene eines Skripts oder einer Übermittlung nicht zulässig.

Übernehmen Sie zur Behebung von Fehlern im erforderlichen Mitglied eine der folgenden Änderungen basierend auf der spezifischen Diagnose:

• Vermeiden Sie die Verwendung required als Typ- oder Aliasnamen (CS9029). Diese Korrektur ist erforderlich, da es sich um required ein kontextbezogenes Schlüsselwort in C# 11 und höher handelt, und die Verwendung als Typname erzeugt Mehrdeutigkeit im Code, in dem das Schlüsselwort angezeigt werden kann.
• Stellen Sie sicher, dass die abgeleiteten Mitglied den Modifizierer required beibehalten, wenn erforderliche Mitglieder (CS9030) überschrieben werden. Diese Korrektur erzwingt den vertrag, der von der Basisklasse festgelegt wurde und garantiert, dass alle abgeleiteten Typen die gleichen Initialisierungsanforderungen beibehalten. Verdecken Sie möglichst keine erforderlichen Mitglieder mit nicht erforderlichen Mitgliedern in abgeleiteten Klassen (CS9031), da durch diese Aktion der Initialisierungsvertrag unterbrochen wird, den Consumer vom Basistyp erwarten.
• Sorgen Sie dafür, dass erforderliche Mitglieder mindestens genauso sichtbar sind wie deren enthaltenden Typ dar, und stellen Sie sicher, dass Eigenschaftssetter ebenfalls ausreichend sichtbar sind (CS9032). Diese Korrektur verhindert Situationen, in denen ein Typ öffentlich zugänglich ist, aber seine erforderlichen Member können nicht aus allen Kontexten initialisiert werden, in denen der Typ erstellt wird.
• Verwenden Sie das required Schlüsselwort anstelle der manuellen Anwendung von RequiredMemberAttribute (CS9033). Durch diese Korrektur wird sichergestellt, dass der Compiler die richtigen Metadaten generiert und alle erforderlichen Memberregeln erzwingt, die die manuelle Attributanwendung möglicherweise nicht ordnungsgemäß ausführen kann.
• Stellen Sie sicher, dass erforderliche Mitglieder Accessoren festgelegt haben oder anderweitig festgelegt sind (CS9034). Diese Korrektur ist erforderlich, da erforderliche Member während der Objekterstellung initialisiert werden müssen, was Schreibzugriff erfordert. Initialisieren Sie beim Erstellen von Instanzen die erforderlichen Elemente direkt in Objektinitialisierern (CS9035, CS9036). Sie müssen jedem erforderlichen Element einen Wert zuweisen, anstatt geschachtelte Memberinitialisierer oder Sammlungsinitialisierer zu verwenden, da das erforderliche Element selbst vor dem Zugriff auf seine Eigenschaften festgelegt werden muss.
• Übernehmen Sie das Attribut SetsRequiredMembers für Konstruktoren, die alle erforderlichen Mitgliedern in deren Textkörpern initialisieren (CS9038, CS9039). Diese Korrektur informiert den Compiler darüber, dass der Konstruktor den erforderlichen Membervertrag erfüllt und die Objekterstellung ohne Objektinitialisierer ermöglicht. Wenn ein Konstruktor mit SetsRequiredMembers zu einem anderen Konstruktor verkettet wird, muss er auch über das Attribut verfügen.
• Vermeiden Sie die Verwendung erforderlicher Member in Typen, die die new() Einschränkung (CS9040) erfüllen müssen, da der parameterlose Konstruktor die erforderliche Memberinitialisierung ohne Objektinitialisierer nicht garantieren kann. Markieren Sie erforderliche Mitglieder nicht als veraltet, es sei denn, der enthaltene Typ oder alle Konstruktoren sind veraltet (CS9042), um Situationen zu verhindern, in denen Mitglieder zwar erforderlich sind, von deren Verwendung jedoch abgeraten wird. Erforderliche Member sind in Anweisungen oder SkriptkonTextkörpern der obersten Ebene (CS9045) nicht zulässig, da diese KonTextkörper die Objektinitialisierungssyntax nicht unterstützen, die zur Festlegung erforderlicher Mitglieder benötigt wird.

Weitere Informationen finden Sie im Referenzartikel zu den erforderlichen Modifizierern sowie im Leitfaden für Objekt- und Sammlungsinitialisierer .

Ref-Rückgabe-Eigenschaften

• CS8145: Automatisch implementierte Eigenschaften können nicht durch Verweis zurückgegeben werden.
• CS8147: Eigenschaften, die durch Verweis zurückgegeben werden, können keine Set-Accessoren haben.

Übernehmen Sie zur Behebung von Fehlern in Verweis zurückgebenden Eigenschaften eine der folgenden Änderungen basierend auf der spezifischen Diagnose:

• Implementieren Sie die Eigenschaft explizit mit einem Backing Field, und verwenden Sie das ref-Schlüsselwort im get-Rückgabeausdruck des Accessors (CS8145). Diese Korrektur ist erforderlich, da automatisch implementierte Eigenschaften ein privates Sicherungsfeld generieren, das der Compiler intern verwaltet. Das Zurückgeben eines Verweises auf ein privates Feld würde internen Speicher verfügbar machen, auf den Anrufer nicht direkt zugreifen sollten. Um eine ref-Rückgabe-Eigenschaft zu erstellen, deklarieren Sie ein explizites Feld, und geben Sie es mit der => ref backingField-Syntax zurück. Wenn Sie keinen Verweis zurückgeben müssen, um eine direkte Änderung des Speichers zu ermöglichen, entfernen Sie den Modifizierer ref aus der Eigenschaftsdeklaration.
• Entfernen Sie den set Accessor aus ref zurückgebenden Eigenschaften (CS8147). Diese Korrektur ist erforderlich, da eine Verweis zurückgebende Eigenschaft bereits den Lese- und Schreibzugriff über den zurückgegebenen Verweis selbst bietet. Aufrufer können den Wert direkt über den Verweis ändern, ohne dass eine separate Settermethode erforderlich ist. Ein set Zugriffsmodul würde zwei verschiedene Mechanismen zum Ändern desselben Speichers schaffen, was redundant ist und zu Verwirrung darüber führen könnte, welcher Weg zum Ändern verwendet werden sollte.

Weitere Informationen finden Sie unter "Ref Returns" und "ref locals" und "Properties".