I'm sorry, my first reply was definitely too short; Unfortunately I didn't
find any good article on the subject; So, here's a short list of things I
that came to my mind right now; In general
- You may safely change default values of data members
- You may safely change all private/internal fields of a class/struct
- You may usually add properties or methods to an existing class or struct
(this only hurts the client if it derives a class from that class, and
happens to add a property/method with the same signature)
- You may usually add data members and events to a class or struct, unless
you use binary serialization in your clients (the binary layout changes with
new data members)
- Removing, renaming or changing the type/signature of public/protected
properties/data members/events/methods can cause clients to crash (however
unlike C++ you'll get something like a "MethodNotFoundException", and no
memory will be overwritten) if (and only if) the client uses that member
- Removing an interface or changing the base class may hurt clients, if the
client casts to that class/interface
- Changing static constants/enums causes clients to break (didn't think of
that before your post)

Of course this list isn't complete, and there are may still be some cases
where even these rules don't work (e.g. if the client tries to invoke a
non-existing method using late-binding; If you add that method, the client
will behave differently). But I hope that this at least gives you a rough
sketch of what is done at compile-time, and what is done at run-time.

In general, if you expect an assembly to change often, using interfaces for
communication is not a bad idea.

Niki