.NET: что касается AssemblyVersion, что определяет бинарную совместимость?

Question

Какие изменения в сборке со строгим именем требуют изменения в AssemblyVersionAttribute? Очевидно, что изменение общедоступного API таким образом, чтобы клиент мог внести изменения в код, требует увеличения AssemblyVersion. Но как насчет изменений в общедоступном API, которые не требуют изменений кода в клиенте? Например:

• добавление публичного класса или интерфейса?
• добавление публичного члена в публичный класс или интерфейс? (РЕДАКТИРОВАТЬ: drscroogemcduck правильно указывает ниже, что добавление элемента к интерфейсу приведет ко всем разработчикам.
• увеличение видимости члена класса?

Должна быть полная документация об этом где-то в MSDN (или, зная MS, в личном блоге MSSE). Но я просто не могу его найти. Пожалуйста, помогите!

Answer 1

В ответ на щедрость Мартина:

Лучшим справочником по бинарной совместимости является сообщество Wiki.

Определенное руководство по изменениям API в .NET

Answer 2

Это довольно просто ... до тех пор, пока типы остаются неизменными (в их общедоступном или защищенном макете) и сигнатуры методов не изменяются (добавление методов или типов в порядке), JIT должен иметь возможность связывать DLL просто отлично.

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

Answer 3

Microsoft добавляет новые методы / классы в библиотеки .NET в выпусках пакетов обновления без изменения AssemblyVersion (по-прежнему 2.0.0.0 / 3.0.0.0) Microsoft только изменяет AssemblyFileVersion. Например, в .NET 2.0 SP1 была добавлена ​​структура DateTimeOffset.

Следует ли нам рекомендовать эту практику, потому что Microsoft делает это? Это сбивает с толку.

Answer 4

добавление методов в интерфейс не должно быть хорошо, потому что старые провайдеры не будут реализовывать новые методы.