C# 为什么私有字段可以访问，而私有setter不能从静态方法访问？

下面给出了一个编译器错误：

    private ObservableEventListener Listener { get; private set; }

    public static void Register()
    {
        Log.Listener = new ObservableEventListener();
        Log.Listener.EnableEvents(Log, EventLevel.LogAlways, EventKeywords.None); 
    }

错误26“MyEventSource.Listener.set”访问器的可访问性修饰符的限制性必须大于属性或索引器“MyEventSource.Listener”

但这一切都很好：

    private ObservableEventListener Listener;

    public static void Register()
    {
        Log.Listener = new ObservableEventListener();
        Log.Listener.EnableEvents(Log, EventLevel.LogAlways, EventKeywords.None);

    }

---

支持setter方法似乎更安全？始终存在冗余的代码/警告行。。为什么这是一个错误

归根结底，这里唯一合理的答案是“因为语言设计者指定属性访问器上的可访问性语句必须比属性本身更严格”。这就是为什么这是一个错误的全部原因。他们为什么选择这个。。。好吧，你可以试着阅读注释过的规范，但是。。。嗯

---

我想在

私有

属性上使用

公共

修饰符是毫无意义的，因此限制性更小（更容易访问）显然是毫无意义的；同样具有限制性的是多余的：您添加关键字的目的可能是为了做某事，但这不会产生任何结果-因此可能是一个错误。

您在setter上指定了

private

，这通常很好，但您也将成员设置为

private

private

没有比

private

更严格的限制，这违反了错误中引用的规则，即：

“MyEventSource.Listener.set”的可访问性修饰符 访问器必须比属性或索引器更严格 “MyEventSource.Listener”

---

也许语言设计者应该允许同样的限制，但他们没有，因此编译失败。

与编译相关的问题通常是这样的，答案是因为

第10.7.2节（重点矿山）

• 访问器修饰符必须声明比属性或索引器本身声明的可访问性更严格的可访问性。准确地说：
  • 如果属性或索引器已声明可访问性为public，则访问器修饰符可以是受保护的内部修饰符， 内部的、受保护的或私有的
  • 如果属性或索引器声明了受保护内部的可访问性，则访问器修饰符可以是内部的， 受保护的，或私人的
  • 如果属性或索引器具有内部或受保护的声明可访问性，则访问器修饰符必须是私有的
  • 如果属性或索引器已声明可访问性为private，则不能使用访问器修饰符。

---

在getter或setter上放置access修饰符是为了允许您将其限制在声明整个proeprty之外。因此，获取私有财产，然后尝试将其设置器设置为私有是没有意义的，因为它已经是私有的了

正确使用，公共getter，私有setter：

public ObservableEventListener Listener { get; private set; }
^^ What you want BOTH Get/Setter to be         ^^ but you can make one more restrictive

错：

private ObservableEventListener Listener { get; private set; }
^^ You want BOTH Get/Setter private             ^^ So what does this mean if you already made them private?

---

您已经将

Listener

声明为

private

，因此setter上的

private

是多余的。删除它。您是否在设置

时没有使用“private”（专用）按钮？它已经是一个私有成员了，所以将条件加倍没有任何作用，并且可能会根据给定的错误规则吓坏编译器。好吧，但是为什么它是一个错误呢？始终存在冗余的代码/警告行。。为什么这是一个错误？@BradleyDotNET是的，它应该是一个错误：这里的修饰符必须是“更严格的”。private并不比private更具限制性，因此fails@TMcKeown这很容易解决：
/warnaserror+
-好了：现在他们都同样挑剔；pHeh，您甚至不需要阅读规范。编译器错误说明了这一点。+1用于查找规范的相关部分。+1（如果可以）用于查找规范中列出的确切场景。我选择此错误是因为我同意您的评论！！=）