C# 一个允许受保护和内部保护的工具？

这是问题的后续行动

我有一个安全敏感类

a

和一个使用它的包装器层次结构（类

B

和

ChildOfB

）

B

必须初始化

A

的实例，并允许

ChildOfB

使用它。

A

的实例应仅可供

B

和

ChildOfB

访问，该实例暴露于其他程序集，不能是内部的

代码示例：

// ************* Library assembly *************
internal class A {}

public abstract class B
{
    // compiler error: Inconsistent accessibility: property type 
    // 'Library.A' is less accessible than property 'Library.B.Property'    
    protected A Property { get; private set; }
}

public sealed class ChildOfB : B
{
    public ChildOfB()
    {
        Console.WriteLine(Property);
    }
}


// ************* in some other assembly *************
var wrapper = new ChildOfB();

据我所知，用普通的C语言是不可能做到的。

---

我同意使用外部工具的解决方案，该工具可以在编译后修改dll（例如，基于某些属性）。例如，在我的代码中，属性将是

内部

而不是

受保护

，编译后，此工具可能会更改CLR类型定义以包含缺少的标志（结果应具有族和程序集访问修饰符）。如果此工具能够确保更改属性的访问修饰符不会破坏初始dll中的任何代码，那就太好了。

如果这只是为了防止意外错误，而不是为了安全，您可以使用静态分析器来强制执行此规则。将可见性设置为

internal

，当这些类以您不喜欢的方式使用时，让分析器发出警告/错误。

因为C#7.2有一个构造

private protected

（）来执行此任务。

protected

和

internal

是可访问性修饰符。他们绝对与安全无关。我添加了

安全敏感部分，只是为了避免人们建议“公开一切，不要麻烦”，这完全是误导。工具有什么用？任何想打电话的人都不会使用这个工具。查看[InternalsVisibleTo]属性和StackTrace类。我宁愿使用一个静态分析器来检查该类是否在程序集中的其他地方使用，并将可见性保持在
internal
。但就我个人而言，我认为与
internal
相比，收益并不大。在某种程度上，你需要依靠程序员不去做愚蠢的事情。@AlexeyPolyakov，又名DarkWalker:也许你需要合并你的帐户？