The big offender there, I think, is that it doesn’t behave like an instance method. If you call an instance method on a null reference, you get a NullReferenceException. If you start having things that look like instance methods but that violate that — i.e., things that you can call on a null reference, or that are even meant to be called on a null reference — then you’re increasing complexity. People working with your code need to remember that much more, and think that much harder about every line of code they write. It violates the principle of least surprise. So make sure you’ve got a really compelling reason to do it.

It looks like I didn’t put this in my notes, but part of the motivation for not putting extension methods on System.Object was that it would be problematic in VB.NET. In VB, when you have a variable declared as Object, all calls on that variable are late-bound. Late-bound won’t call an extension method. So if you use VB.NET at all, System.Object extension methods are a bad idea.

If you only use C#, I wouldn’t see a big problem with putting extension methods on System.Object, if it was done thoughtfully. I sure as heck wouldn’t want my grid vendor to do it, but I wouldn’t mind doing them internally, and it’d be fine if my test framework did it. In fact, I’d love to see an RSpec-style assertion framework for .NET.

this error message appears to me
svn: Can’t connect to host ‘localhost’: No connection could be made because the
target machine actively refused it.

i tried to add a port to allow connecting to it.but the same result appears
i tried to search for this problem solving but nothing helped out
thanks in advance

Do you have pointers to an article explaining *why* it’s wrong to violate those guidelines? Ok, I grok the one about namespaces, but I don’t understand the reason for the other two - I am actually using that IsNull() extension method.

The real question is, why aren’t you following your prescription?