很久以前，我记得读过Microsoft的一个非常强烈的建议，反对将自己的类添加到框架命名空间中。我一直在寻找它没有成功。
我记得的主要原因是框架的后续版本可能会附带类名冲突。
还有其他原因吗？您是否建议将自己的类添加到框架命名空间中？关于此事是否有现存的官方指导？
尝试存根不再/尚存在的东西时，您希望在不属于您的命名空间中拥有一个类的唯一情况是在您不想更改的代码库中使用。
例如，我编写了一个 HashSet 实现，并将其放置在 System.Collections.Generic 命名空间中，用于在 .NET 3.5 处于测试阶段时面向 .NET 2.0 的应用程序。我知道我们将升级到 .NET 3.5，并在时机成熟时删除了这个类。
这里似乎说得很清楚：
命名约定
.NET Framework 类型使用表示层次结构的点语法命名方案。此技术将相关类型分组到命名空间中，以便可以更轻松地搜索和引用它们。全名的第一部分（直到最右边的点）是命名空间名称。名称的最后一部分是类型名称。例如，
System.Collections.ArrayList表示属于 System.Collections 命名空间的ArrayList类型。System.Collections中的类型可用于操作对象的集合。此命名方案使扩展 .NET Framework 的库开发人员可以轻松地创建类型的分层组，并以一致、信息丰富的方式命名它们。它还允许通过其全名（即，通过其命名空间和类型名称）明确标识类型，从而防止类型名称冲突。预计库开发人员在为其命名空间创建名称时将使用以下准则：
CompanyName.TechnologyName例如，命名空间
Microsoft.Word符合此准则。
"开发类库的设计指南"也带有类似的规则：
命名空间名称的一般格式如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]例如，Microsoft.WindowsMobile.DirectX。
在命名空间名称前面加上公司名称，以防止来自不同公司的命名空间具有相同的名称和前缀。
请在命名空间名称的第二级使用与版本无关的稳定产品名称。
不要使用组织层次结构作为命名空间层次结构中名称的基础，因为公司内的组名称往往是短暂的。
命名空间名称是一个长期且不变的标识符。随着组织的发展，更改不应使命名空间名称过时。
请使用 Pascal 大小写，并使用句点分隔命名空间组件（例如，
Microsoft.Office.PowerPoint）。如果您的品牌采用非传统大小写，则应遵循您的品牌定义的大小写，即使它偏离了正常的命名空间大小写。请考虑在适当的情况下使用复数命名空间名称。例如，使用
System.Collections而不是System.Collection。但是，品牌名称和首字母缩略词是此规则的例外。例如，使用System.IO而不是System.IOs。不要对命名空间和该命名空间中的类型使用相同的名称。例如，不要使用
Debug作为命名空间名称，还要在同一命名空间中提供名为Debug的类。一些编译器要求对此类类型进行完全限定。
和：
核心命名空间是 System.* 命名空间（不包括应用程序和基础结构命名空间）。
System和System.Text是核心命名空间的示例。应尽一切努力避免与核心命名空间中的类型发生名称冲突。不要为类型名称提供与核心命名空间中的任何类型冲突的类型名称。
例如，不要使用
Directory作为类型名称，因为这会与Directory类型冲突。
但是，当然，如果你真的愿意，你可以这样做。
建议使用 Company.Product.Component 作为命名空间。我认为这可能包括在您自己的产品中不使用框架命名空间。请参阅 MSDN：命名空间的名称（开发类库的设计指南).
就我个人而言System我永远不会为我自己的类使用命名空间，就像它们不属于 .NET 框架一样。我也不会在Java中使用java.lang。不过，这只是我个人的看法。
希望有帮助。
干杯，马蒂亚斯