Автоматическая версия BizTalk в моем процессе сборки

Question

Во всех моих других приложениях .net мой процесс сборки (смесь nant и настраиваемых задач) автоматически обновляет Assembly AssemblyVersionAttribute AssemblyInfo.cs с текущим номером сборки перед вызовом msbuild, тиснение в номере сборки в номере версии.

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

Прежде всего номера версий aseembly хранятся в файлах btproj, поэтому я сделал некоторые поисковые запросы и нашел www.codeplex.com/biztalk, который выглядел как ответ на мою проблему, но есть более глубокая проблема!

У меня есть проект для моих схем, а другой для моих конвейеров, проект трубопроводов ссылается на мой проект схем, так как у меня есть плоский файл/сборщики. Проблема возникает, когда я обновляю номера версий, так как обновление их даже изнутри visual studio не обновляет ссылки на компоненты конвейера на схемы.

Так что, если я обновляю все номера версий вручную в VS IDE с 1.0.0.0 до 1.1.0.0, сборка завершится неудачно, так как компоненты компоновщика плоских файлов/сборщиков все еще ссылаются на старую версию 1.0.0.0 схем! Они не обновляются автоматически!

Действительно ли это ручной процесс обновления номеров версий проектов BizTalk на страницах свойств, а затем создание проектов и ручное обновление ссылок на них в свойствах всех компонентов конвейера, которые ссылаются на них?

Это означает, что я не могу обработать процесс сборки номера сборки номеров моей версии!

Или существует лучший способ управления номерами версий сборок BizTalk?

Answer 1

Извините, что разочаровал вас, но я был в тупике, какой я должен был сдаться. Я предполагаю, что это можно было бы достичь, но потребовалось бы много изменений как для файлов привязки, так и для других файлов XML (как вы упомянули, и даже больше, если вы опубликовали сервисы и т. Д.).

Возможно, возможно было бы обернуть все эти необходимые изменения на этапе сборки (шаг MSBuild или аналогичный в других структурах сборки) - это будет полезно!

Answer 2

Потрошенный, думал, что это может быть так. Возможно, проекты BizTalk 2009 будут лучше играть при обновлении ссылок при изменении номеров версий.

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

У меня есть стандартная библиотека классов C#, включенная в мой проект (различные вспомогательные функции), которые я могу обновить номер версии во время моего процесса сборки, поэтому я в основном использую эту сборку для версии в целом заявление. Если кто-то хочет знать, какая версия находится в какой-либо среде, проверьте номер версии этой сборки.

Не идеальный, но он работает.

Answer 3

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

Answer 4

Developer- :)

У нас была аналогичная проблема, и мы закончили разработку небольшая утилита, которая будет изменить номер версии во всех проектах т.е. * .csproj (asssemblyinfo.cs) * .btproj соответственно. Помимо этого он будет открывать и изменять файлы * .btp с новой версией схем. Вкратце, все, что вам нужно сделать, это настроить эту утилиту в меню инструментов VS.net и выполнить ее.

Я думаю, его не очень сложно разработать такую ​​утилиту в любом .net lanagauge.

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

Cheers!

Answer 5

Эта проблема возникает, когда вы выполняете сборку интеграции с последними версиями зависимых компонентов в качестве ссылок на файлы (например, здесь).

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

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

Например:

SchemaA, сборка версии 1.0.0.0 PipelineA (с PipelineComponent XMLValidator, например), версии сборки 1.0.0.0

PipelineA имеет ссылку на файл к SUBST диск (скажем, R диск , который отображается в рабочем пространстве D: \ MyComponents) и версии 1.0.0.0 схемы SchemaA следующим образом:

R: \ SchemaA \ 1.0.0.0 \ SchemaA.dll.

Сценарий копирования копирует сборку SchemaA локально на ваш R-диск.

Когда схема A обновляется до версии 1.1.0.0, у вас нет никаких проблем, потому что вы все еще используете версию 1.0.0.0, и у вас есть выбор использовать версию вашей версии 1.1.0.0. Когда вы хотите обновить, вам нужно изменить свой сценарий копирования и заменить ссылку на файл на R: \ SchemaA \ 1.1.0.0 \ SchemaA.dll.