Что нарушает двоичный интерфейс .net (dll)

Question

Рассмотрим две библиотеки dll .net.Первый, "application.dll" содержит основную бизнес-логику и код доступа к данным.Второй, "webservice.dll" в основном состоит из инфраструктуры, которые ссылаются на предметы и методы с применением.DLL для предоставления веб-службы вызовов в существующий код.

Какие изменения (например,добавлять новые классы, добавлять новое поле или метод к существующему классу и т.д.) Может и не может быть сделано в приложении.dll без необходимости перекомпиляции webservice.dll?

Answer 1

Большинство вещей будет в порядке;некоторые вещи, которые его сломают:

• Удаление * используемых типов (если только вы не используете перенаправление типов)
• Удаление * используемых методов (включая конструктор)
• Изменение сигнатуры методов (которые используются)
• Изменение общедоступных полей на свойства (которые используются)
• Изменение внутренних компонентов сериализации, если используется сериализация
• Добавление метода к интерфейсу, где вторая библиотека dll имеет тип, реализующий этот интерфейс
• Добавление абстрактного метода к базовому классу, который наследуется во второй библиотеке dll
• Почти все внутреннее, если используется хакерское отражение (ab)
• Добавление ограничений к универсальному типу / методу
• Маркировка типа как sealed когда он был унаследован во второй библиотеке dll
• Добавление поля в struct если вызывающий объект использует инициализацию по элементам, а не инициализацию конструктора

(удаление включает в себя изменение доступности чего-либо непубличного)

Answer 2

Технически, имя нарушит его (имя, версия и токен ключа в случае сборок со строгим именем).В противном случае фреймворк будет попробуй загрузить и использовать библиотеку DLL, и это будет работать более или менее нормально, пока не попадет в другой тип или сигнатуру метода, отсутствующий тип и т.д..Но имейте в виду, что повторное использование имен ведет прямиком обратно в ад DLL (или к связанным с ним проблемам).

Я предлагаю подробнее ознакомиться с управление версиями сборок чтобы получить представление о том, как решать подобные проблемы.

Answer 3

вы можете вносить любые изменения в application.dll, не требуя перекомпиляции webservice.dll, пока вы не вызываете новые классы, функции [добавлены в application.dll].если вы хотите использовать какое-либо из ваших приложений.dll изменяется в webservice.dll, тогда вам нужно перекомпилировать webservice.dll

конечно, если вы измените подпись или уровень доступа любого из методов или свойств в application.dll, которые используются websrvice.dll, это нарушит работу вашего кода в webservice.