Fehler und Warnungen im Zusammenhang mit Eigenschaftendeklarationen

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

• CS0200: Eigenschaft oder Indexer 'property' kann nicht zugewiesen werden, da sie schreibgeschützt ist.
• CS0545: 'function' : kann nicht außer Kraft gesetzt werden, da 'property' keinen überschreibbaren Get-Accessor hat.
• CS0571: 'Funktion': Der Operator oder Accessor kann nicht explizit aufgerufen werden
• CS0840: "Eigenschaftsname" muss einen Text 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
• 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.
• 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 Eigenschaften in Readonlystrukturen müssen readonly sein.
• CS8657: Statisches Element kann nicht als "readonly" gekennzeichnet werden.
• CS8658: Der automatisch implementierte Accessor "set" kann nicht als "readonly" gekennzeichnet werden.
• CS8659: Die automatisch implementierte Eigenschaft 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 als auch für den Accessor angegeben werden.
• CS8661: Der Modifizierer "readonly" kann nicht für beide Accessoren einer Eigenschaft angegeben werden.
• CS8664: "readonly" kann nur für Accessoren verwendet werden, wenn die Eigenschaft sowohl abgerufen als auch festgelegt wurde.
• CS9029: Typen und Aliase können nicht als "erforderlich" bezeichnet werden.
• CS9030: Das Mitglied muss als erforderlich gekennzeichnet werden, weil es ein erforderliches Mitglied überschreibt.
• CS9031: Erforderliches Element kann nicht durch abgeleitetes Element ausgeblendet 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: Erforderliches Element muss festgelegt werden.
• 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 ist falsch formatiert und kann nicht interpretiert werden.
• CS9038: Die Liste der erforderlichen Member für den Basistyp 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 Member sind auf oberster Ebene eines Skripts oder einer Einsendung 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: Die nicht-nullbare Eigenschaft muss beim Verlassen des Konstruktors einen Nicht-Nullwert enthalten. Erwägen Sie das Hinzufügen des Modifikators "required", die Deklaration der Eigenschaft als nullable oder das Hinzufügen von "[field: MaybeNull, AllowNull]"-Attributen.
• CS9266: Ein Accessor der 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.

Syntax des Eigenschaftsaccessors

• CS0545: 'function' : kann nicht außer Kraft gesetzt werden, da 'property' keinen überschreibbaren Get-Accessor hat.
• CS0571: 'Function': Nicht explizit den Operator oder Accessor aufrufen
• CS1043: { oder ; erwartet

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

Überschreiben Sie nur die Accessoren, die in der Deklaration der Basisklasse (CS0545) vorhanden sind. Sie können keinen Eigenschaftsaccessor außer Kraft setzen, der in der Basisklasse nicht vorhanden oder zugänglich ist, da keine virtuelle Methode zum Überschreiben in der kompilierten IL vorhanden ist. Wenn die Basisklasseneigenschaft nur über einen get Accessor verfügt, entfernen Sie den set Accessor aus Ihrer Überschreibung, oder fügen Sie der Basisklasse den fehlenden Accessor hinzu und markieren Sie Ihn virtual. Verwenden Sie alternativ das new Schlüsselwort, anstatt override die Basisklasseneigenschaft mit einer völlig neuen Eigenschaftsdefinition mit unterschiedlichen Accessoren auszublenden.

Greifen Sie auf Eigenschaften mithilfe der Eigenschaftssyntax zu, anstatt Accessormethoden direkt aufzurufen (CS0571). Eigenschaftenaccessoren kompilieren zu speziellen Methoden mit Namen wie get_PropertyName und set_PropertyName, aber Sie sollten diese Methoden über eigenschaftssyntax (obj.Property und obj.Property = value) aufrufen. Dieser Ansatz behält die richtige Semantik bei und ermöglicht es dem Compiler, erforderliche Prüfungen durchzuführen. Das gleiche Prinzip gilt für Operatoren, die auf Methoden wie op_Increment z. B. kompilieren, aber mithilfe der Operatorsyntax (++obj) anstelle von Methodenaufrufen aufgerufen werden sollten.

Verwenden Sie die richtige Eigenschaftsaccessorsyntax mit geschweiften Klammern oder Ausdruckskörpern (CS1043). Eigenschaftenzugriffe müssen C#-Syntaxregeln befolgen: Accessor-Körper müssen in geschweifte Klammern { } eingeschlossen werden, ausdrucksbasierten Accessoren müssen die => Syntax verwenden und automatisch implementierte Eigenschaften müssen mit einem Semikolon enden, nach der Accessorliste. Der Compiler erwartet entweder eine vollständige Accessorimplementierung oder das Semikolon, das einen automatisch implementierten Accessor angibt.

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

Automatisch implementierte Eigenschaften

• CS0840: "Eigenschaftsname" muss einen Text 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 Erwartet

Um Automatisch implementierte Eigenschaftsfehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

Fügen Sie sowohl get als auch set Accessoren zur Eigenschaftsdeklaration (CS0840) hinzu. Für automatisch implementierte Eigenschaften muss der Compiler ein Sicherungsfeld generieren, und der Compiler kann dies nur tun, wenn beide Accessoren vorhanden sind, um sicherzustellen, dass der Speicher sowohl gelesen als auch geschrieben werden kann. Wenn Sie eine schreibgeschützte, automatisch implementierte Eigenschaft benötigen, fügen Sie einen set Accessor hinzu und machen Sie ihn private, um den Schreibzugriff einzuschränken, während der Compiler weiterhin das Backing-Feld generieren kann. Alternativ, wenn die Eigenschaft als abstract oder extern deklariert wird, entfernen Sie die Accessor-Körper komplett, da diese Modifizierer angeben, dass die Implementierung an anderer Stelle zur Verfügung gestellt wird. Für partial Eigenschaften können Sie die Deklaration und Implementierung über partielle Typdeklarationen aufteilen.

Stellen Sie sicher, dass die Eigenschaftsdeklaration nur gültige Accessorstichwörter get und set (CS1014) enthält. Eigenschaftssyntax ermöglicht nur Accessordeklarationen, nicht beliebige Anweisungen oder Memberdeklarationen innerhalb des Eigenschaftentexts. Wenn Sie zusätzliche Logik benötigen, implementieren Sie die Eigenschaft mit expliziten Accessortexten, die Ihren Code enthalten. Wenn Sie versuchen, Felder oder Methoden zu deklarieren, verschieben Sie diese Deklarationen außerhalb der Eigenschaft in den Klassen- oder Strukturkörper, wo Memberdeklarationen zulässig sind.

Weitere Informationen finden Sie unter "Eigenschaften" und "Automatisch implementierte 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: Nicht-nullbare Eigenschaft muss beim Verlassen des Konstruktors einen Nicht-Null-Wert enthalten. Erwägen Sie, den 'required'-Modifikator hinzuzufügen, die Eigenschaft als Nullable zu deklarieren oder '[field: MaybeNull, AllowNull]'-Attribute hinzuzufügen.
• CS9266: Ein Accessor der 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 Element zugreifen möchten, das anstelle des synthetisierten Sicherungsfelds benannt field ist, qualifizieren Sie es 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: Eigenschaft oder Indexer 'Property' kann nicht zugewiesen werden - sie ist schreibgeschützt.
• CS8341: Automatisch implementierte Instanzeigenschaften in schreibgeschützten Strukturen müssen schreibgeschützt sein.
• CS8657: Statisches Element kann nicht als "readonly" gekennzeichnet werden.
• CS8658: Ein automatisch implementierter "set"-Accessor kann nicht als "readonly" markiert werden.
• CS8659: Die automatisch implementierte Eigenschaft kann nicht als "readonly" gekennzeichnet werden, da sie über einen "set"-Accessor verfügt.
• CS8660: „readonly“-Modifizierer können nicht sowohl für eine Eigenschaft als auch für deren Accessor angegeben werden.
• CS8661: Der Modifizierer "readonly" darf nicht für beide Accessoren einer Eigenschaft angegeben werden.
• CS8664: "readonly" kann nur für Accessoren verwendet werden, wenn die Eigenschaft sowohl get als auch set hat.

Um Schreibeigenschaftenfehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

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 schreibgeschützt 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 schreibgeschützte statische Eigenschaft benötigen, lassen Sie einfach den set Accessor aus, anstatt den readonly Modifizierer 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 zur Initialisierungszeit benötigen, ersetzen Sie den set Accessor durch einen init Accessor, oder entfernen Sie den set Accessor vollständig, um die Eigenschaft tatsächlich schreibgeschützt zu machen.

Platzieren Sie den readonly Modifizierer entweder in der Eigenschaftsdeklaration oder in einzelnen Accessoren, aber nicht in beiden (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 verwendet werden readonlysollen, 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.

Eigenschaftsinitialisierer

• CS8050: Nur automatisch implementierte Eigenschaften oder Eigenschaften, die das Schlüsselwort "Field" verwenden, können Initialisierer haben.
• CS8051: Automatisch implementierte Eigenschaften müssen get-Accessoren haben
• 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, um automatisch implementierte Eigenschaften zu verwenden, 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 definiert werden, da es ein erforderliches Mitglied überschreibt.
• CS9031: Erforderliches Element kann nicht durch abgeleitetes Element ausgeblendet 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: Erforderliches Element muss festgelegt werden.
• 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 Mitglieder ist falsch formatiert und kann nicht interpretiert werden.
• CS9038: Die Liste der erforderlichen Member für den Basistyp 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: Notwendige Mitglieder sind auf der obersten Ebene eines Skripts oder einer Einreichung nicht gestattet.

Um erforderliche Memberfehler zu beheben, wenden Sie eine der folgenden Änderungen basierend auf der spezifischen Diagnose an:

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 Member den required-Modifizierer beibehalten, wenn sie erforderliche Member (CS9030) überschreiben. Diese Korrektur erzwingt den vertrag, der von der Basisklasse festgelegt wurde und garantiert, dass alle abgeleiteten Typen die gleichen Initialisierungsanforderungen beibehalten. Vermeiden Sie das Ausblenden erforderlicher Member mit nicht erforderlichen Membern in abgeleiteten Klassen (CS9031), da durch diese Aktion der Initialisierungsvertrag unterbrochen wird, den Consumer vom Basistyp erwarten.

Stellen Sie erforderliche Member mindestens so sichtbar wie deren enthaltenden Typ dar, und stellen Sie sicher, dass Eigenschaftsseter 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 Member 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.

Wenden Sie das SetsRequiredMembers Attribut auf Konstruktoren an, die alle erforderlichen Member in ihren Kö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 notwendige Member nicht als veraltet, es sei denn, der enthaltene Typ oder alle Konstruktoren sind veraltet (CS9042), um Situationen zu verhindern, in denen Mitglieder notwendig sind, deren Verwendung jedoch abgeraten wird. Erforderliche Member sind in Anweisungen oder Skriptkontexten der obersten Ebene (CS9045) nicht zulässig, da diese Kontexte die Objektinitialisierungssyntax nicht unterstützen, die benötigt wird, um erforderliche Member festzulegen.

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.

Um Fehler bei ref-zurückgebenden Eigenschaften zu korrigieren, wenden Sie eine der folgenden Änderungen entsprechend der spezifischen Diagnose an:

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 ref Modifizierer aus der Eigenschaftsdeklaration.

Entfernen Sie den set Accessor aus ref zurückgebenden Eigenschaften (CS8147). Diese Korrektur ist erforderlich, da eine ref-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".