There are some cases of classes I wrote and inherits from the framework classes that I believe should be offered to the user of my tools along with the framework classes.
I agree with Kasper here that you should stick to your own namespace in these cases. It's a matter of making clear that your class is a custom implementation.
Following your logic, we would have to put every class in the System namespace since they all derive from object. This rule just doesn't make sense, your decision to use a particular namespace is arbitrary and other people will have different opinions and interpretations.
Stick to your own namespacing, though I would agree if you decided to have part of the namespace refer to the library that's you're basing it on in cases where the underlying third party library is leaked to consumers anyway, e.g.:
namespace Roberto.MyApp.Data.EntityFramework
{
public class RobertosContext : DbContext { /* ... */ }
}
I still expect some developers to disagree with this (as it "leaks" the dependency at least information-wise), but in the case of inheritance (as opposed to composition), a consumer using the derived class will inherently be required to know the base class as well, which means the dependency has already leaked anyway.
If you're using composition, then the above suggestion is invalid. Your composed classes act as a wrapper to ensure that your consumers don't know which library you may or may not be using, so your namespace should be library-agnostic as well.
For example, there are some extension methods I'm implementing that make sense to be available when using a namespace of the framework. I think it's more convenient to not have to add my namespace when the framework's namespace is being used.
Here I disagree with Kasper and agree with you.
Extensions methods exist precisely to behave as if they were part of the extended type. Forcing a separate namespace effectively negates that by requiring consumers to know it's an extension method that needs to be included separately.
Anyone who would be using your extended type would generally already be using that type's namespace and therefore the extension methods would be indistinguishable from the actual class methods, which is the point of extension methods.
Extension methods are just a syntactical rewrite of a static method because you don't want consumers to have to know which arbitrary static class you decided to put this method in. If you use extension methods but then require consumers to know which arbitrary namespace you've put this in, then it's just perpetuating the same issue.
if class B from the framework inherits from A also from the framework and they belong to the same namespace, why should my class C that inherits from A be in a different namespace?
Because there is no inherent grouping between two derived classes.
Take the extreme example: you and I both use Entity Framework. We both derived our context class (RobertosContext, FlatersContext) from EF's DbContext. Should we now be forced to coordinate our namespaces?
The earlier example I gave applies here too: following your logic, we would have to put every class in the System namespace since they all derive from object.
There might be cases where the derived classes belong to the same namespace, but that is not inherently the case just because they inherit from the same object.
Summing up, what are the dos and don'ts when writing code heavily based on someone else's namespace?
At a basic level, stick to your own namespace. You need clarity on which types were created by you.
Extension methods are the exception here because they specifically exist to camouflage themselves as belonging to the object they extend, and taking on the same namespace is part of that.
usingto my custom namespace and that of the library is prone to ambiguous references if the library namespace suddenly adds a type that already exists in my custom namespace.