Should I put custom code inside Microsoft's BCL/FCL namespaces?

Question

A .NET programmer is allowed to wrap code inside namespaces and also to use a namespace already defined, even those defined by Microsoft in the Framework or Base Class Library. For example if I were to use System.Windows.Forms to outline this idea:

Reference in assembly System.Windows.Forms.dll

// This is my own C# source code file.

using System.Windows.Forms;

namespace System.Windows.Forms { // In Microsoft's FCL and now in my file.
    /* Define my custom classes and such in here.
     * (I'm kind of playing inside Microsoft's "sandbox" now.)
     */
}

So is this practice okay? What are some good arguments for or against it?

Edit: I'm making this question language agnostic because it applies to any syntax that supports namespaces in .NET.

Update: Because answers ask why: for example, I might want to put custom code into Microsoft's System.Web.UI namespace to add extension methods to the System.Web.UI.Page class to manipulate any Web Form in my ASP.NET project. Arguably I could put those extension methods into a custom namespace and use it instead; however System.Web.UI is already being used in all ASP.NET pages so the extension methods are immediately available to all Web forms without modification -yes, a quick convenience - I don't have to add another C# using to each file. (Anybody have a better example?)

Answer 1

I don't see this too much. Most companies put stuff in their own namespace, e.g. Initech.Windows.Forms.

Having your code inside the namespace of the .NET framework is allowed, but I don't see any good reason to, and it may confuse developers. I don't recommend this.

Answer 2

This would be enormously confusing to anyone attempting to maintain the system later. It also risks breakage when the BCL / FCL are updated.

In a word: Don't!

Answer 3

Don't do it !!!!! ... unless it's a really really really good fits such as if you're hacking the BCL to workaround a weird bug ... but even that is hardly ever the case.

• Namespace clutter -- What if you have to define a helper class, an extra utility...
• Extension methods -- It'll will automatically carry over to anyone using System.Windows.Forms;
• Tooling problems -- I believe it will breaks some 3rd party libraries/tools.
• Reflection -- The Namespace property is of the string type!
• Utter confusion -- Surely this'll pops some "WTF"s during debugging sessions.

---

How to: add another auto-import namespace to an asp.net website:

1. Open up web.config. Or create one at a folder of your choice (such as Project\Views\web.config for a view-related settings)
2. Under the <pages> element, find the <namespaces> element.
3. Add: <add namespace="Your.Namespace.Here" />
4. Builds the project just to be sure.
5. Re-load your ASPX and ASCX pages (that is closing and re-opening them)
6. Try one of your class, it should shows up in intellisense without any <%@ Imports /> now

There you go, no need for a duct tape approach!

Answer 4

Definitely don't do it.

Put it in your own namespace, and add the using statement. Why would you risk confusion - and the possibility of the same type later being defined by Microsoft in a later version of the framework - just to avoid a using directive?

If you put it in a namespace which is the same as the namespace of the page itself, or in some ancestor namespace, you won't even need a separate using directive anyway.

Please, please, for the sake of whoever's going to read the code later on, please don't add to the System namespace.

I would also add that it's a bad idea to create types with the same names as BCL types, even if they're in different namespaces. All of this adds confusion when reading code, which is a thoroughly bad thing.

Answer 5

The concept of opening up a standard namespace and adding your own stuff to it is very well accepted as common practice in other languages and communities. For example, Prototype.js adds useful methods to JavaScript arrays, while Ruby on Rails lets you write things like 4.days.ago (4.score.and.seven.years.ago is coming, I'm told) by opening up the core datetime classes and popping in its own methods.

This practice, however, is not accepted in the C# world. This world is very different from the loosey-dynamicy JavaScript and Rails worlds. So don't do it in C#.