Что нарушает бинарный интерфейс .net (dll) - PullRequest
4 голосов
/ 30 апреля 2009

Рассмотрим два .net dll. Первый «application.dll» содержит основную бизнес-логику и код доступа к данным. Второй, «webservice.dll» состоит в основном из WebMethods, которые связываются с объектами и методами с помощью application.dll с целью обеспечения вызовов веб-сервиса для существующего кода.

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

Ответы [ 3 ]

3 голосов
/ 30 апреля 2009

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

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

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

1 голос
/ 30 апреля 2009

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

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

0 голосов
/ 30 апреля 2009

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

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

...