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