Правила обратной совместимости класса С#/исключения изменений

Я работаю над сборкой С# 3.5, которая потребляется многими различными приложениями в среде корпоративного сервера. Я хотел бы добавить некоторые свойства к существующему классу С# (не абстрактно) и поддерживать обратную совместимость с текущими клиентами без перекомпиляции. Его сильно названная сборка 3.5. Существующие клиентские приложения не будут перекомпилированы. Вместо этого мы используем сборки политик издателя для перенаправления существующих клиентов на обновленную версию.

Каковы правила для поддержки обратной совместимости этого типа класса?

Я ищу некоторый набор правил, в которых я могу проверить мои изменения кода.

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

Ответ 1

Лучшей ссылкой является ответ Джастина: Определенное руководство по изменениям API в .NET

@Justin - если вы когда-нибудь опубликуете это как ответ, я дам вам чек.

Ответ 2

Вы должны поддерживать одну и ту же версию сборки (т.е. не увеличивать ее по строкам) - см. AssemblyVersionAttribute в MSDN.

Кроме того, вы можете использовать переадресацию связывания сборок, но это связано с изменениями конфигурационных файлов, которые я не ожидаю быть желательными в вашем случае.

Ответ 3

В его точке ошибка, которую вы получаете, не связана с совместимостью между классами, а скорее с сбоем загрузки - см. Определение манифеста расположенной сборки не соответствует ссылочной ссылке если это помогает.

Добавление свойств/методов в класс exisitng должно быть приемлемым для обратной совместимости. Удаление полей/методов/свойств, изменение класса на структуру, изменение базового класса определенно не является. Изменение констант, значения перечисления опасны.

Ответ 4

Очень хороший ресурс, описывающий всевозможные нерушимые изменения, - https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/breaking-change-rules.md.