#1:
Of course you can
write a destructor in abstract class. It makes perfect sense, because the destructor is inherited be a derived class and will be actually called during its destruction. You cannot literally use it without creating and instantiating non-abstract class somewhere down the hierarchy, because you cannot instantiate an abstract class. Now, writing destructors in .NET makes little sense because of its managed memory and
Garbage Collector (GC). This is somewhat non-trivial aspect. GC marks all objects which cannot be accessed from currently running code and eventually destructs them and reclaim their memory, but it does not guarantee anything about the moment of time when it happens. With .NET, there is no much work for destructors. I would recommend not using unless you know what are your doing really well.
#2:
The question is asked many times. I want to show old Answers, because they are interesting, as well as discussion. I already gave my Answer, but see for others as well.
Please see the discussion on how to decide on use of interfaces vs. abstract classes:
How to decide to choose Abstract class or an Interface[
^].
Also, one fundamental difference is that interfaces allows for multiple inheritance, in contrast to classes (abstract or not). This is called
weak form of multiple inheritance and cause serious design implications.
—SA