Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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 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.