What breaks a .net binary (dll) interface

Question

Consider two .net dlls. The first, "application.dll" contains the main business logic and data access code. The second, "webservice.dll" consists mostly of WebMethods that link to objects and methods with application.dll for the purpose of providing webservice calls to existing code.

What changes (e.g. add new classes, add a new field or method to an existing class etc) can and can't be made to application.dll without requiring a recompile of webservice.dll?

Answer 1

Most things will be fine; some things that will break it:

• Removing* types that are used (unless you are using type-forwarding)
• Removing* methods that are used (including constructor)
• Changing the signature of methods (that are used)
• Changing public fields to properties (that are used)
• Changing serialization internals if serialization is used
• Adding a method to an interface, where the second dll has a type that implements that interface
• Adding an abstract method to a base-class that is inherited in the second dll
• Almost anything internal if hacky reflection is (ab)used
• Adding constraints to a generic type/method
• Marking a type as sealed when it was inherited in the second dll
• Adding a field to a struct if the caller uses memberwise initialization rather than constructor initialization

(removing includes changing the accessibility to something non-public)

Answer 2

Technically, the name will break it (name and version and key token in the case of strong named assembiles). Otherwise, the framework will try to load and use the DLL, and this will work more or less fine until it hits a different type or method signature, a missing type etc.. But be aware that re-using names is going straight back to DLL hell (or the problems thereof).

I suggest reading more about assembly versioning to get an idea how to solve such issues.

Answer 3

you can make any changes to application.dll without requiring to recompile of webservice.dll as long as you are not calling the new classes,functions [added in application.dll]. if you want to consume any of your application.dll changes in webservice.dll then you have to recompile the webservice.dll

ofcourse, if you change the signature or access level of any of the methods or properties in application.dll that are used by websrvice.dll, it will break your code in webservice.