您是否为所有扩展方法使用全局的catchall命名空间，还是将扩展方法放在与它们扩展的类相同的命名空间中？
或者您是否使用其他方法，如应用程序或特定于库的命名空间？
我问，因为我需要扩展System.Security.Principal.IIdentity，并且将扩展方法放在System.Security.Principal命名空间中似乎有意义，但我从未见过这样做过。
答案 0 :(得分：12)
将扩展名放在与它们扩展的类相同的名称空间中。这样，当您使用该类时，您可以使用扩展名。
此外，微软说这是关于扩展方法的：
一般情况下，我们建议你 谨慎地实施扩展方法 只有当你必须。每当 可能的，必须扩展的客户端代码 现有类型应该通过 创建一个派生自的新类型 现有的类型。
有关扩展方法的详细信息，请参阅the MSDN page有关扩展方法的内容。
答案 1 :(得分：9)
如果它们是整个解决方案中使用的扩展方法（例如超过60％的类），我将它们放在解决方案的基本命名空间中（因为它们将自动导入到父命名空间中，不导入公共每次都是。）
在此类别中，例如：
.IsNullOrEmpty(this string value)和.HasValue(this string value)
但是，如果它们非常具体且很少使用，我会将它们放在BaseNamepace.Extensions命名空间中，这样它们就必须手动导入，并且不会在intellisense中显示混乱的东西。
答案 2 :(得分：8)
我建议将所有扩展方法放在一个命名空间中（顺便说一句，这也是微软通过将它们放在'System.Linq'命名空间内的单个类'Extensions'中对Linq所做的事情）。
由于Visual Studio没有提供有关如何查找要使用的扩展方法的线索，因此只需记住一个命名空间即可减少混淆。
答案 3 :(得分：1)
我赞同user276695的答案，这似乎是最简单的解决方案。但是我发现了一个更好的解决方案：根本没有名称空间。您可以将带有扩展方法的静态类放在文件的根目录下，而不必在其周围包装任何名称空间声明。然后，扩展方法将可用，而无需导入/使用任何命名空间。†
我有点担心被命名空间纳粹分子投票。但我觉得有必要支持一个稍微不正统的立场。至少在我的工作（IT）中，我发现大多数自定义工具在没有命名空间的情况下更容易维护，并且将所有内容放在一个巨大的匿名命名空间中。我确信还有其他编程领域，这也不行。但是，参与＆amp;在不同的情况下，我只想指出你实际上可以声明没有命名空间的类，甚至是带有扩展方法的类 - 对于那些也能更好地找到一个巨大的匿名命名空间的人来说。
†您还可以保存一级缩进。 :-)即使有3台巨型显示器，我也一直在寻找节省屏幕空间的方法。
答案 4 :(得分：0)
我的做法是将扩展名放在一个名称空间中，该名称空间不同于我正在扩展的源名称空间。
通常，我通过在我正在扩展的命名空间前面添加命名空间路径的“公司名称”部分来创建一个命名空间，然后用“.Extensions”后缀它
例如，如果我正在扩展（没有充分理由）::System.Text.StringBuilder因为它是密封的，那么我会将我的扩展名放在命名空间::CodeCharm.System.Text.Extensions中。
当我进行扩展时，这是一个经验法则，我怀疑我可以在其他解决方案中重复使用这些扩展。
答案 5 :(得分：0)
如果将它们放在比当前更高的命名空间中，它们将自动显示。
因此，如果你有以下项目的命名空间：
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<input type="text" id="stock">
<div id="stockprice"></div>然后直接在：
声明您的扩展程序AdventureWorksInc.Web
AdventureWorksInc.Logic
AdventureWorksInc.DataAccess
只要您在AdventureWorksInc的任何子名称空间中编写代码而不需要using语句，就会显示此扩展方法。
然而，上述扩展显示了可能的缺点。由于它在字符串上运行，它现在将显示为所有字符串的扩展方法，包括那些不是HTML的字符串。这实际上不是命名空间范围的问题，而只是滥用扩展方法。这应该是一个需要标准参数的常规静态，因此调用是显式的。
通常设计良好的具有适当类型参数的扩展方法不会显示在永远不会应用的类型上。