Как заставить автоматические номера версий работать в Visual Studio

Мне было предложено добавить автоматическую нумерацию к сборкам в нашей библиотеке кодов. Я меняю версии с версии 1.0.0.0 на 1.0 по умолчанию. * Вот так:

[сборка: AssemblyVersion ( "1.0. *" )]

Он генерирует число, которое мне бы хотелось.

Однако библиотека кода содержит много сотен DLL, причем многие ссылаются друг на друга. Теперь, когда я компилирую некоторые проекты, они жалуются, что версия DLL, требуемая ссылочным компонентом, неверна, и они не будут строить: (

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

Ошибка, которую я получаю, выглядит следующим образом:

Error   1   CA0058 : The referenced assembly 'Library1, Version=1.0.4146.17993
, Culture=neutral, PublicKeyToken=d9c65edd2096ad48' could not be found. This assembly
is required for analysis and was referenced by:
D:\Work\Source Code\Library\Library2\bin\Release\Library2.dll.

Версия 1.0.4146.17993 неверна - DLL имеет более высокое значение. Библиотеки DLL настроены на "Копировать локальную", потому что требуемое программное обеспечение требует (не спрашивайте, почему). DLL, скопированная локально, - это номер с более высоким номером версии, который мы хотим, чтобы он был.

До сих пор я пытался изменить ссылки, чтобы установить флаг "Специфическая версия" в false, но это не помогло.

Ответ 1

Номера версий, которые генерирует VS при использовании синтаксиса 1.0.*, не обязательно будут последовательно увеличиваться. В документации есть что сказать (выделено мной):

Вы можете указать все значения или вы можете принять номер сборки по умолчанию, номер версии или оба с помощью звездочки(). Например, [сборка: AssemblyVersion ( "2.3.25.1" )] указывает 2 как основную версию, 3 - младшую версию, 25 - номер сборки, а 1 - номер версии. Номер версии, такой как [сборка: AssemblyVersion ( "1.2." )] Указывает 1 как основную версию, 2 как второстепенную версию и принимает номера сборки и ревизии по умолчанию. Номер версии, такой как [сборка: AssemblyVersion ( "1.2.15. *" )] Указывает 1 как основную версию, 2 как младшую версию, 15 в качестве номера сборки и принимает номер версии по умолчанию. Число по умолчанию по умолчанию увеличивается каждый день. Номер версии по умолчанию является случайным.

Если жизненно важно, чтобы вы правильно оценивали версию, я настоятельно рекомендую вам использовать стороннее решение. Добавлена надстройка Build Version Increment.

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

Надстройка надстройки Version Increment дает вам вид мелкомасштабного контроля над тем, что увеличивается, что вам нужно, чтобы получить это право. Это то, что, вероятно, должно быть включено в VS для начала.

Ответ 2

На самом деле это довольно сложный вопрос, и я надеюсь, что кто-то ответит на это подробно для вас, но мои 2 цента после того, как вы получите информацию о сборке под контролем, вы должны посмотреть на использование Nuget для управления вашими зависимостями. Таким образом, когда команда A выпускает v2 сборки X, все, что они делают, помещает ее в репозиторий Nuget (вероятно, сетевой ресурс), а затем вы можете в основном щелкнуть правой кнопкой мыши < обновите внутри своих проектов, которые потребляют библиотеки DLL.

Я бы также рекомендовал посмотреть http://semver.org/ и использовать семантическую версию, если вы не хотите следовать системе, подобной этой ( или создать аналогичный стандарт для вашего магазина), вероятно, не стоит даже пытаться перепрограммировать ваши DLL файлы, которые вы только что дадите себе массивные головные боли. Однако использование Semantic Versioning сделает ваши номера версий действительно ПОСМОТРЯТЬ что-то. И не просто быть тем, кто хотел бы пометить текущую версию.

Ответ 3

Обратите внимание, что номер версии не является случайным. Это время дня сборки. Строка - это номер дня.

См. VisualStudio: перевод версии сборки на дату календаря

Ответ 4

удалите свою ссылку (в проекте, который ее использует), и повторите ее, указав тип ссылки проекта.

PS: Если при добавлении ссылки вы выбираете просмотр и указываете на место, где всегда будет dll, ссылка не будет нарушена!

Ответ 5

   > However, the code library has many hundreds of DLLs,

Если вам хорошо, что все исходные проекты и их сгенерированные dll-ы имеют одинаковый номер версии, вы можете поместить номер версии в один файл, который будет использоваться совместно всеми DLL файлами, как описано в shared AssemblyInfo.cs. Таким образом, вы (или генератор номера версии, который используете) должны обновлять только один файл, если есть новая версия/версия.

Это не отвечает на ваш первоначальный вопрос, но может быть простым workaroud для проблемы зависимости.