c# - 在系统命名空间内创建 .net 系统库扩展的陷阱

Question

在我工作过的所有公司中，我最终都拥护一组核心库，这些库的作用只不过是增强和扩展 .net 库。通常我的命名空间以我们公司名称开头，但子命名空间反射(reflect)了 System 命名空间。

Foo.IO;
Foo.Web

What I plan to do is take this one step further and replace the company namespace with the system namespace so that you only have to have the one using statement and thus have a better enhancement to the core library.

namespace System.IO
{
    public static class StreamExtensions
    {
        ...
    }
}

实际问题

现在我知道这是可能的，微软在他们自己的库中做到了这一点，并且我已经在其他第三方库中看到了它，但我想知道的是这样做的长期影响是什么(如果有的话)作为 .net 更高版本中的类名冲突？有没有人这样做过，并且不得不处理一个复杂的问题，这破坏了添加程序集引用的简单性？

更新

不幸的是，这已经变成了一场关于你是否应该这样做的争论，这可能属于程序员的责任。不雅还有一个SO question它确实问了这个问题，但这不是问题的重点。

我想知道是否会出现某种情况，导致编译错误或奇怪的行为。唯一出现的两个论点是。

1. 微软向一个对象添加了一个与库中扩展方法的签名相匹配的方法，但这是一个静音点，因为它对于扩展方法所在的命名空间没有影响，就像对象上的实现一样优先。

2. 其他人在他们的第三方库中做了同样的事情，我们有名称冲突。这更有可能发生，而且我们已经必须处理第三方库 ILMerge 其他库到其程序集中的情况。

需要明确的是，这是一个独立的库，供内部使用，不可供外部使用，并且可以通过扩展方法扩展现有的系统库。

Answer 1

我建议不要这样做。 System 命名空间是 .NET Framework 命名空间，如果您想从该命名空间自定义类，请在代码中明确说明。

这意味着使自定义类成为您自定义命名空间的一部分。

不要把事情搞乱。