Как автоматически увеличить версию сборки, если в коде есть изменения?

Question

существует ли способ автоматического увеличения номера версии сборки, если сборка изменилась после выполнения сборки решения?

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

Заранее спасибо.

РЕДАКТИРОВАТЬ: я хочу автоматически увеличивать номер версии сборок, в которых я меняю код каждый раз, когда выполняю «Build Solution», чтобы избежать его изменения вручную. Таким образом, я могу быть уверен, что 2 сборки с одинаковой версией ВСЕГДА имеют одинаковый код.

Answer 1

Да, вы можете получить автоматическое увеличение версии, используя * в атрибуте [AssemblyVersion]. К сожалению, это редко правильно. Что Microsoft должна была сделать, так это предоставить [AssemblyFileVersion] такую ​​возможность. Они не.

[AssemblyVersion] - это очень важный атрибут, используемый CLR для проверки того, что загруженная сборка совместима со сборкой, которая использовалась при компиляции кода. «Совместимый» означает: сборка будет работать корректно с клиентским кодом, в исходный код сборки не было внесено никаких изменений, которые могли бы помешать правильной работе сборки, если клиент не был перекомпилирован. Используя это определение, обновление исправления ошибки очень совместимо. Обновление, которое реорганизовало внутреннюю реализацию классов в сборке, также может быть очень совместимым. Изменения в общедоступных классах или членах, скорее всего, будут несовместимы. Хотя JIT-компилятор очень хорошо обнаруживает, когда изменения были совершенно несовместимыми (например, удаление ранее открытого участника).

Использование * в атрибуте по существу означает: он всегда несовместим. Даже если вы вообще не изменили код, после повторной сборки сборка будет несовместима. Это довольно бесполезно в большинстве случаев, кроме случаев, когда вы всегда собираете сборку вместе с ее клиентским кодом. И перераспределить их вместе. Это работает, но тогда понятие наличия номера версии становится совершенно бесполезным.

Короче говоря: IMO, вы должны сами управлять версией сборки. Измените его, когда вы сделаете критическое изменение в общедоступном интерфейсе сборки. Это, безусловно, подход, который использует Microsoft. Сборки .NET 2.0 по-прежнему помечены как версия 2.0.0.0 в .NET 3.5 SP1 framework. Хотя они на самом деле не совместимы, WaitHandle.WaitOne (int) был добавлен позже. В противном случае они проделали звездную работу по поддержанию совместимости в течение последних 5 лет, это было бы нелегко.

Обратите внимание, что ничего из этого не относится к [AssemblyFileVersion], автоматическое увеличение его для каждой сборки очень уместно.

Answer 2

Если вы хотите автоматически увеличивать число, которое обновляется каждый раз, когда выполняется компиляция, вы можете использовать VersionUpdater из события перед сборкой. Это имеет преимущество в большем контроле, чем механизм нумерации по умолчанию, описанный в MSDN.

Answer 3

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

Если сборка вообще не изменилась, она не будет перекомпилирована (если вы не используете команду «rebuild all»)

Так что в моих проектах внутри AssemblyInfo.cs каждого проекта у меня есть эта строка:

[assembly: AssemblyVersion("1.0.*")]

И это вызывает у меня разные номера версий для моих сборок.