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);
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.
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.
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)
Mar 18, 2014 at 9:21
Microsoft have created a set of guidelines for namespace conventions.
This link is here: Microsoft Namespace Naming Guidelines.
CompanyName.TechnologyName[.Feature][.Design]
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).
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.
SystemorSystem.CoreorSystem.*are NOT your libraries, no mather how much useful and similar your utility classes are. A<MyCompany>.System.*namespace is a better solution.