Would it be acceptable for some very generic utilities or classes to be added in the System namespace?

I'm thinking of really basic stuff like a generic EventArgs (EventArgs<T>),

Use case: would be shared in a company's core library (so that it can be recompiled in a new project as-is, without changing the namespace);

  • -1. No, System or System.Core or System.* are NOT your libraries, no mather how much useful and similar your utility classes are. A <MyCompany>.System.* namespace is a better solution.
    – umlcat
    Commented Oct 27, 2014 at 17:38

5 Answers 5


Not acceptable.

Could you? Yes, but System namespace is for framework base stuff. Even Microsoft does not put their own stuff into the System namespace (for example: such as C# compiler APIs or Registry).

System namespace is shared between Microsoft .NET, Mono, and DotGNU.

I would recommend using your company name, and then put the basic stuff in that namespace.

  • 1
    For future readers, DotGNU has been decomissioned since 2012.
    – Pharap
    Commented Mar 1, 2016 at 20:04

No, no, no. What would you do if the next .NET release contains a class with the same name? You are screwed as you would have to go through all of your files that include that class and rename all instances. You never add to a library to which you have no control. The easiest solution is to reverse the company URL. For example, if your company site is fred.com, create your classes in com.fred. It's pretty common to follow this naming convention.

  • 8
    +1 for providing a clear and realistic reason to why it's a bad idea.
    – Statement
    Commented Mar 12, 2011 at 19:52
  • 5
    This is the main reason namespaces were invented, right?
    – Statement
    Commented Mar 12, 2011 at 19:53
  • 11
    The easiest solution is to reverse the company URL. For example, if your company site is fred.com, create your classes in com.fred. It's pretty common to follow this naming convention - in Java world. In .NET it's customary to use CompanyName.TechnologyName[.Feature][.Design] (as @Dal / @rmx pointed out) Commented Mar 18, 2014 at 9:21

Fully correct answers here, but no rule without exception: if you create something like LinqBridge (which is a .NET framework 2.0 replacement for .NET fw 3.5 classes in a 100% compatible way), then usage of the System namespace is mandatory. Or to answer this in a more general way: own usage of the System namespace is only a good idea if you have to port some higher version framework classes to a lower version, because you cannot upgrade your production version to the higher framework (and I guess this is the only valid reason for using this namespace).

  • 3
    I'll agree with this, because it's explicitly invoking the reason @SnoopDougieDoug cited as the best reason not to do so: Future naming conflicts. In this case, you want the conflict so your code will transition seamlessly when you are able to move to the higher version.
    – Bobson
    Commented May 21, 2014 at 21:26

Yes, you can do it. VS might report various false errors, like classes it doesn't find but when compiled everything will work ok. It is generally NOT recommended for already mentioned reasons BUT, I think you can do it in some situations.

In my case I did it for a shared code base which is compiled as libraries for 6 different .net based platforms (.NET basic, Xamarin, Window 8.1, Mac etc, each api having its own small differences). The compiled lib is then used by projects targeting each platform. For the Windows Store 8.1 Apps and Windows Phone 8.1 platforms the System.Collections had a whole bunch of classes missing from it: ArrayList, Hashtable, SortedList etc, all kinds of comparers, enumerables etc etc. While I am aware of the fact that these classes are not recommended and one should use generic alternatives (which are available for the Win 8.1 platforms), it is a HUGE task in our case to make such changes on the shared code, PLUS on the code of the consumer projects of the resulting libraries. Non generic classes are used all over the place, the dev started in 2002. And we are talking about tens of thousands of lines of code now... So in this case, I think it is ok to inject a few missing classes in System namespace.


Many correct answers already. But I want to add another perspective:

Using the System namespace tells the developer to look at MSDN, using the company's namespace tells the developer to look at internal resources for documentation.

It also makes the dependency on the company's library clear, which might be relevant when moving code around between different modules.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.