那么受ArchUnit启发的NetArchTest呢？
示例：

// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("NetArchTest.SampleLibrary.Presentation")
    .ShouldNot()
    .HaveDependencyOn("NetArchTest.SampleLibrary.Data")
    .GetResult()
    .IsSuccessful;

// Classes in the "data" namespace should implement IRepository
result = Types.InCurrentDomain()
    .That().HaveDependencyOn("System.Data")
    .And().ResideInNamespace(("ArchTest"))
    .Should().ResideInNamespace(("NetArchTest.SampleLibrary.Data"))
    .GetResult()
    .IsSuccessful;

此项目允许您创建在. Net代码库中强制执行类设计、命名和依赖项约定的测试。这些测试可与任何单元测试框架一起使用，并可合并到生成管道中。

**恐怕这是不可能的。**我们试图借助属性来实现这一点，但没有成功。您可能需要参考我的past post on SO。

你能做的最好的事情就是用**NDepend**检查你的程序集。NDepend显示你项目中程序集的依赖关系图，你可以立即跟踪违规行为并采取相应的措施。

（来源：ndepend.com）

自从我提出这个问题以来，已经有3年了。我必须说，尽管这里有很多精彩的答案，但我还是尝试过探索这个问题。到目前为止，我学到的一些教训是--

• 通过查看使用者可以发现更多的代码味道（如果有单元测试的话，单元测试是最好的地方）。
• 构造函数中参数的数量直接表示依赖项的数量。依赖项太多=〉类做得太多。
• 类中的（公共）方法数
• 单元测试的设置几乎总是会给予这一点
• 代码会随着时间的推移而恶化，除非有一个集中的努力来清除技术债务和重构。这是真实的，无论语言。
• 工具只能在一定程度上有所帮助，但工具和测试的结合往往能对各种气味给予足够的线索，及时捕捉它们需要一点经验，特别是要理解每种气味的意义和影响。

你想用软件解决一个人的问题吗？准备好迎接痛苦的世界吧！
解决问题的方法是确保你有与人合作的方法，你不会以这类问题结束......结对编程/回顾。当人们第一次进入项目时对其进行引导，等等。
话虽如此，你可以编写工具来分析软件并寻找常见问题。但人们相当有创造力，可以找到各种奇怪的做事方式。

一旦一切都按照你的满意度锁定了，新的要求就会到来，你必须突破它的侧面。
考虑到程序员可以通过反射访问所有私有成员，在.NET的编程级别上强制这样的严格性几乎是不可能的。
做你自己，支持和安排定期的代码评审，提供教育和实施适当的培训。而且，正如你所说，当你不能针对它编写单元测试时，它会很快变得明显。