-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.
–
umlcatOct 27 '14 at 17:38

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.

+1 for providing a clear and realistic reason to why it's a bad idea.
–
StatementMar 12 '11 at 19:52

5

This is the main reason namespaces were invented, right?
–
StatementMar 12 '11 at 19:53

8

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)
–
Konrad MorawskiMar 18 '14 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).

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.
–
BobsonMay 21 '14 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.