Общие атрибуты сборки во время сборки TFS

Я ищу изящное решение - если оно есть - проблемы связывания с файлом общих атрибутов сборки вне проекта и последующей передачи этого проекта в TFS для сборки.

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

Раньше, работая только с моей локальной машиной, я ссылался на несколько из этих «библиотечных» проектов в данном решении, поэтому решение для связанных общих файлов работало хорошо, например <Assembly: AssemblyCompany("My Company")>. Согласованность между этими атрибутами очень важна для именования ключей реестра и т. Д.

Но теперь отправка этих проектов на сервер сборки представляет проблему; связанный файл не существует на сервере, поэтому сборка, естественно, не выполняется.

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

Я новичок в управлении версиями и архитектурах сборки; что делают хорошие люди для решения этой проблемы?


git version-control shared-libraries .net-assembly projects-and-solutions
person InteXX    schedule 26.11.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

При сборке проекта (в текущем репо) должны быть найдены все сборки, на которые ссылается проект.

Поскольку некоторые сборки находятся вне текущего репо (управляются в другом репо / library), и хотя репо библиотеки не имеет отношений с текущим репо, вы пропустите сборки репозитория библиотеки при сборке проекта.

Чтобы получить сборки из репозитория библиотеки, вы должны «добавить связи» между текущим репо и репозиторием библиотеки. Обычно используются два способа: подмодули и поддерево .

Вариант 1: рассматривать репо библиотеки как подмодуль для текущего репо

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

#In local current repo
git submodule add <URL for the library repo>
#change the reference path correspondingly
git add .
git commit -m 'add the library repo as submodule'
git push

Теперь сборка проекта позволяет найти сборки из репозитория библиотеки.

Вариант 2: рассматривать ветку из репозитория библиотеки как поддерево для текущего репо

Предположим, что сборки управляются в master ветви репозитория библиотеки, поэтому вы можете добавить главную ветвь из репозитория библиотеки в текущее репо:

# In local current repo
git subtree add --prefix=library <URL for the library repo> master
# change the reference path correspondingly
git add .
git commit -m 'add library master branch as subtree'
git push

Теперь проект тоже можно построить успешно.

person Marina Liu    schedule 27.11.2017
comment
Спасибо, но это связанные файлы, а не сборки, на которые есть ссылки. Например, у меня есть файл ServiceInfo.vb на два уровня папки выше проекта, который на него ссылается. Локальная сборка включает файл, потому что он существует в том месте, где его ожидает проект. Однако сборка сервера завершается неудачно, потому что связанный файл находится за пределами локального и удаленного репозиториев. Связанного файла нет ни в одном репозитории - он просто находится вне иерархии папок проекта. Ваши предложения все еще актуальны? - person InteXX; 27.11.2017
comment
Также: поддерживает ли пользовательский интерфейс Visual Studio 2017 управление этими концепциями подмодулей и поддеревьев? - person InteXX; 27.11.2017
comment
Да, вы должны добавить репо, в котором находятся исходные файлы. Например, файл ServiceInfo.vb находится в другом репо, вы должны добавить репо как подмодуль / поддерево для текущего репо, в котором находится ваш проект. Чтобы при сборке с помощью VSTS можно было найти связанные файлы. И чтобы добавить подмодуль / поддерево, вы должны вместо этого использовать командную строку. - person Marina Liu; 27.11.2017
comment
Похоже, это не сработает. Проект, который ссылается на файл, ищет его по относительному пути: ..\..\..\ServiceInfo.vb. Поддерево увидит файл в той же локальной папке: .\ServiceInfo.vb. Сборка все равно завершится ошибкой, когда все попадет на сервер. Кроме того, командная строка меня ужасно тормозит. Я надеюсь на автоматическое решение, если это вообще возможно. - person InteXX; 27.11.2017
comment
Убедитесь, что связанные пути верны, или вы можете снова связать файлы в подмодуле / поддереве. Если вы используете подмодуль, выберите подмодули оформления заказа на шаге «Получить источники» в определении сборки VSTS. - person Marina Liu; 27.11.2017
comment
Боюсь, ты меня потеряла, Марина :-) - person InteXX; 27.11.2017
comment
Вы можете попробовать шаг за шагом, на любом этапе есть проблемы, пожалуйста, дайте мне знать :) - person Marina Liu; 27.11.2017
comment
Хорошо, подойдет - спасибо за ваше предложение. Тем временем мне в голову пришла идея. Я мог бы написать небольшое консольное приложение, чтобы проанализировать файл AssemblyInfo.vb, вставить необходимые записи и запустить его как команду предварительной сборки на моем локальном компьютере. Таким образом, я могу рассчитывать на правильную информацию, существующую на локальном компьютере, и, естественно, она пройдет через сборку на TFS. Пока я делаю локальную сборку до первого нажатия, все будет в порядке. Больше никаких связанных файлов. Что вы думаете? - person InteXX; 27.11.2017
comment
Звучит нормально, но я никогда не тестировал этот способ. Вы можете попробовать. - person Marina Liu; 27.11.2017
comment
Я сначала попробую по-твоему. Завтра. - person InteXX; 27.11.2017
comment
Марина, извините, мне нужно было потушить пожары с тех пор, как мы об этом заговорили, так что у меня не было возможности поработать над этим. Насколько вам известно, будет ли эта конструкция требовать, чтобы я переходил в командную строку для каждого цикла фиксации / слияния / синхронизации? Если так, то это наверняка убийца сделки. Я читал это, и мне показалось, что проектирование автомобиля с семью колесами, чтобы иметь возможность повернуть, по крайней мере, в этом случае. ДОЛЖЕН быть более простой способ решить эту простую проблему. T4, вызывающий сценарий PowerShell, начинает выглядеть привлекательно. Ваше мнение? - person InteXX; 21.12.2017
comment
Если технологический контекст допускает упаковку и формальное управление зависимостями, вы обязательно должны пойти по этому пути. Ссылка: medium.com/@porteneuve/mastering-git-submodules-34c65e940407 - person InteXX; 21.12.2017

arrow_upward
0
arrow_downward

Решение оказалось довольно простым.

Вот как:

  1. В каждом проекте удалите все существующие ссылки на ServiceInfo.vb
  2. Вставьте эту команду в событие предварительной сборки каждого проекта
    # P3 #
  3. Соберите каждый проект, чтобы скопировать файл
  4. В каждом проекте ссылка на $(SolutionDir)ServiceInfo.vb

В зависимости от вашего кода сборка на шаге 3 может завершиться ошибкой, потому что не может найти ServiceInfo.vb. Нет проблем, просто создайте его снова после того, как вы создали ссылку на шаге №4.

Это гарантирует, что ServiceInfo.vb будет включен в вашу публикацию Git в TFS и что ваш шаг сборки на сервере будет успешным.

person InteXX    schedule 13.06.2018