Develop Reference

overriding an interface method not marked as virtual

I'm writing a log4net appender. They have an AppenderSkeleton class which implements IAppender:
public abstract class AppenderSkeleton : IBulkAppender,
IAppender, IOptionHandler
They way the AppenderSkeleton class works is they implement the DoAppend() method of IAppender and do a bunch of work for you, like calling the filter chain, and then call an abstract method called Append(). While this is reasonable, I would like to execute some of my code before the filters run. I could implement the IAppender interface myself but at first I figured I would just try to override DoAppend() in my derived class, do my stuff, and then call base.DoAppend(). It was at this point where I noticed the AppenderSkeleton didn't mark DoAppend() as virtual since I got a compiler error indicating I couldn't override the method since it wasn't marked virtual.
I then had my class derive from IAppender and explicitly implemented the IAppender.DoAppend() method. I was surprised that the code compiled without issues. Below is my DoAppend() method:
void IAppender.DoAppend(LoggingEvent evnt)
{
.
.
.
base.DoAppend(evnt);
}
I haven't tried running it yet but wondering if someone might now what the runtime will end up doing with this implementation?
Thanks,
Nick

#Rob's answer is right - which method (base or derived) is called would depend on how you invoked it. That would make it rather fragile code.
What I'd recommend is to use composition and not inheritance. Don't make your class inherit from AppenderSkeleton, make it contain an instance of AppenderSkeleton and use its methods where you choose to.
Visual Studio even has a quick "Implement interface through private variable" option if you declare a private variable that implements one of the interfaces your class also implements. It quickly generates a proxy pattern for your class, calling the corresponding methods on the private member.

If someone has not marked his method as virtual, then there is no way to override this. The only option is to implement your own IAppender.
Also, note that you do not override interface methods, you implement them.
However, you even do not need to override this method.
According to documentation, DoAppend
performs threshold checks and invokes filters before delegating actual logging to the subclasses specific Append method.
You don't need to override DoAppend method, since it describes the generic algorithm.
It is sort of Template method.
You need to override Append method which is abstract:
protected override void Append(LogginEvent loggingEvent)
{
// Your actions here
}

How to override or hide add in an ObservableCollection?

I want to override Add(MyType t) for a class derived from ObservableCollection<MyType>. However I cannot override Add. Why?
I therefore added AddIem(MyType t)and use that function instead, which works fine. But I want to prevent someone erroneously using Add so I implemented Add (throwing an exception). But that doesn't hide the Add method of the ObservableCollection. Any idea why and how I could achieve my goal?

Keep your ObservableCollection private, and expose the items with a public ReadOnlyObservableCollection which reflects the items in the private collection.
If you need to expose a specialized AddItem method to other classes, you could make it a member of your viewmodel class, or you could subclass ReadOnlyObservableCollection and put it there. Call it MostlyReadOnlyObservableCollection.

How does ObservableCollection<T>.Add work?

I was trying to implement a specialized collection that works like ObservableCollection to encapsulate some more mechanisms in it, to do that i also let my collection inherit from Collection and i also implement the same interfaces.
I just do not get though how one actually implements the whole collection-changed-logic, for example Collection<T>.Add is not being overridden (it is not even marked as virtual), so how does the ObservableCollection fire the CollectionChanged event if items were added using that method?

To answer your specific question, Collection<T>.Add calls the InsertItem virtual method (after checking that the collection is not read-only). ObservableCollection<T> indeed overrides this method to do the insert and raise the relevant change notifications.

It does so by calling InsertItem which is overridden and can be seen upon decompilation
protected override void InsertItem(int index, T item)
{
this.CheckReentrancy();
base.InsertItem(index, item);
this.OnPropertyChanged("Count");
this.OnPropertyChanged("Item[]");
this.OnCollectionChanged(NotifyCollectionChangedAction.Add, item, index);
}

Remember, the key is not in overriding the base Collection methods, it's in the fact that you will be implementing the ICollection interface. And frankly, rather than inheriting from a Collection class, I would suggest instead creating an adapter class that takes a ICollection in the constructor and your methods will just delegate to the inner collection and raise the appropriate events.

How to know when to call base method or override methods in observable collection

i have some questions when watching this tutorial.
i wonder when i overwrite methods, how do i know if i need to call the base method?
public CustomerCollection(IEnumerable<Customer> customers, OMSEntities context) : base(customers)
also why do i need to do
protected override void InsertItem(int index, Customer cust)
{
this.context.AddToCustomers(cust);
base.InsertItem(index, cust);
}
protected override void RemoveItem(int index)
{
this.context.DeleteObject(this[index]);
base.RemoveItem(index);
}
what does the 2 lines in each method do? and why the need for such similar method. if i overwrite methods for delete and add why not update too?

You call the base method when you're method is just additional functionality decorating what the base method does, you don't call the base method when you are replacing it's functionality wholesale.
And if you don't know what the base method does, you wouldn't be overriding it, so in knowing what it does and why you're overriding it, you should be able to make this decision in accordance.

For the first part of your question if you do not add a :base(parameter) to the end of a constructor it will actually put a :base() there for you behind the scenes. if there is no base() you will get a compile exception. you need a chain of constructors all the way down to object(). adding that :base(parameter) is just a way of choosing a different constructor other than the default one.
For the second part. It is a good rule of thumb that if you are overriding a method to provide some kind of additional functionality you should call the base method instead too (so you get its functionality), if you are trying to replace the functionality instead of add to it you do not need to call the base(as you are replacing it :) ).

Should I call the base class implementation when overriding a method in C# for ASP.NET?

I understand overriding a method/function redefines its implementation in the derived class from its implementation in the base class.
Now what confuses me, is if I override a class in ASP.NET such as CreateChildControls() (I picked it randomly for no particular reason), VS2008 auto generates:
protected override void CreateChildControls()
{
base.CreateChildControls();
}
Good enough, the default implementation just calls the base class' CreateChildControls().
So if I want to run some code, since I do not know how base.CreateChildControls(), should I do this:
protected override void CreateChildControls()
{
/*My Code Here*/
base.CreateChildControls();
}
or, ignore what base.CreateChildControls() altogether and just do
protected override void CreateChildControls()
{
/*My Code Here*/
}

That's up to you. Generally, you want to call the base class method because it might do a lot of stuff you're not privy to (especially in a class you don't control .. get it? Control.) But, if you are very confident you don't need (or want) the base class "stuff" to happen, you can remove the call.

It's simply a question of whether you want to entirely replace the behavior or add behavior.
For something like CreateChildControls, you will probably retain the call to the base class.

it depends on what you want to do. If you want the base.CreateChildControls() method to be called and then you want to perform some custom action before or after the method is called, then you can do so.
If you want to have complete control of what is happening when CreateChildControls is called, then you can simply ignore calling it altogether.
The fact that it's in there by default is just a bit of guidance for you.

It depends if you want to replace or complete the base implementation... in most cases you should call the base implementation (and you definitely should do it in the case of the CreateChildItems method...)

You might want to take a look at the template method pattern. While you can't do anything about the way the library classes are implemented, it might help you ensure the code you write is easy to use correctly.