Is it good practice to add new classes to framework namespaces?

A long time ago, I remember reading a quite strong recommendation from Microsoft against adding your own classes to framework namespaces. I've been unsuccessfully searching for it.

The main reason I remember is that a subsequent version of the framework might ship with a class name collision.

Are there any other reasons? Would you ever recommend adding your own classes to a framework开发者_JAVA百科 namespace? Is there any extant official guidance on the matter?

The only case where you want to have a class in a namespace that does not belong to you when you are trying to stub something that no longer/yet exists however is used in a code-base you don't want to change.

For example I have written a HashSet implementation and placed in the System.Collections.Generic namespace for an application that was being targeted to .NET 2.0 when .NET 3.5 was in beta. I knew that we will upgrade to .NET 3.5 and removed this class when the time come.

It seems pretty clearly stated here:

Naming Conventions

.NET Framework types use a dot syntax naming scheme that connotes a hierarchy. This technique groups related types into namespaces so they can be searched and referenced more easily. The first part of the full name — up to the rightmost dot — is the namespace name. The last part of the name is the type name. For example, System.Collections.ArrayList represents the ArrayList type, which belongs to the System.Collections namespace. The types in System.Collections can be used to manipulate collections of objects.

This naming scheme makes it easy for library developers extending the .NET Framework to create hierarchical groups of types and name them in a consistent, informative manner. It also allows types to be unambiguously identified by their full name (that is, by their namespace and type name), which prevents type name collisions. It is expected that library developers will use the following guideline when creating names for their namespaces:

CompanyName.TechnologyName

For example, the namespace Microsoft.Word conforms to this guideline.

And the "Design Guidelines for Developing Class Libraries" carry a similar rule:

The general format for a namespace name is as follows:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

Do use a stable, version-independent product name at the second level of a namespace name.

Do not use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.

The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.

Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint). If your brand employs nontraditional casing, you should follow the casing defined by your brand, even if it deviates from normal namespace casing.

Consider using plural namespace names where appropriate. For example, use System.Collections instead of System.Collection. Brand names and acronyms are exceptions to this rule, however. For example, use System.IO instead of System.IOs.

Do not use the same name for a namespace and a type in that namespace. For example, do not use Debug for a namespace name and also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.

And:

The core namespaces are the System.* namespaces (excluding the application and infrastructure namespaces). System and System.Text are examples of core namespaces. You should make every effort to avoid name collisions with types in the core namespaces.

Do not give types names that would conflict with any type in the core namespaces.

For example, do not use Directory as a type name because this would conflict with the Directory type.

But, of course, you can do it if you really want to.

There is a recommendation to use Company.Product.Component as namespaces. This may include not using Framework namespaces in your own product I think. See MSDN: Names of Namespaces (Design Guidelines for Developing Class Libraries ).

Personally I'd never use System namespace for my own classes, just as they don't belong to the .NET framework. Neither I'd use java.lang in Java. However, this is just my personal opinion.

Hope that helps.

Cheers, Matthias