Насколько я понимаю, вы использовали XCopy для копирования вывода сборки во внешнюю папку, чтобы зависимые решения могли использовать вывод в качестве ссылок на сборки. Вы правильно поняли, что использовать события после сборки и XCopy неправильно, так как это начинает причинять вам боль. У нас аналогичная цель в наших API-решениях, и я постараюсь описать, что мы делаем с нашими, но помним, что серебряной пули не существует, и иногда все еще требуются компромиссы.
Структура проекта
Структура проекта - это не структура в Visual Studio, а то, как вы организуете источник, библиотеку и другие внешние элементы, необходимые для проекта, этот шаблон может быть применен к большинству языков. Структура проекта должна быть чистой, легкой для понимания и согласованной между всеми проектами. Я использую структуру, совместимую с рядом проектов с открытым исходным кодом, и обычно состоит из следующих элементов.
- root
|-- bin
|-- build
|-- lib
|-- src
|-- tools
- root - Корень должен содержать как можно меньше элементов.
- bin - Бин - это то место, куда должны выходить сборки. Это, вероятно, уместно только тогда, когда у вас есть несколько выходов, если у вас есть только один выход, такой как веб-проект, он может оставаться там, где он есть. Я не нашел причин использовать подпапку для отладки и выпуска сборки.
- build - Содержит файлы сборки, такие как сценарии MSBuild или NAnt для построения исходного кода, выполнения тестов, покрытия кода, анализа кода, документации и т. Д.
- lib - Содержит все сторонние библиотеки, внешние или внутренние, от которых зависит вывод проекта. Я обычно использую подпапки для каждой библиотеки, но я не уверен, действительно ли мне это нужно.
- src - Содержит все файлы, необходимые для открытия проекта, редактирования, сборки и запуска в выбранной вами IDE. Постарайтесь, чтобы структура здесь была как можно более плоской, нет смысла пытаться сделать ее слишком сложной, поскольку другие разработчики вряд ли будут столь же методичными, как вы, и у вас будут проекты в неправильных папках. Самое большее, что я делаю, - это создаю папку для тестов для всех тестов, но даже это на самом деле не требуется.
- tools - содержит все приложения, сборки, внешние файлы, от которых зависит сборка, но источник не должен зависеть ни от одного из них, поскольку его зависимости находятся в библиотеках.
Пути к файлам
Все пути к файлам в проекте должны быть относительными. Как только вы начнете использовать абсолютные пути к файлам, как в примере, вы начнете чувствовать боль. Проблемы возникнут на машинах разработки, на которых разработчик размещает свой источник на другом диске, или на сервере сборки, где гораздо сложнее определить, откуда запускается проект.
Общее правило: проект должен быть автономным. В идеальном мире не должно быть никаких зависимостей ни от чего, кроме корневой папки. Иногда это сложно, особенно в устаревших проектах или там, где у вас есть требования к com, реестру или сервису, но если немного подумать и доработать, большинство из них можно смягчить. В конечном счете, вы хотите иметь возможность сделать проект максимально простым для запуска проекта на заданной машине.
Построить вывод
Когда я делаю проект API, выходные данные проектов помещаются в папку bin, о которой я упоминал выше. Вы сделали это с помощью XCopy во время события после сборки. Это, конечно, неправильно, так как будет делать то, что вы хотите, но с Visual Studio есть лучший способ. Если вы перейдете в раздел сборки свойства проекта, вы можете изменить расположение вывода. Не забудьте выбрать все конфигурации сборки перед ее изменением.
Ссылка на сборки из внешних проектов
Одна из причин разделения API на его решение on и ссылки на выходные данные в виде ссылок на сборки вместо ссылок на проекты заключается в том, что либо решение стало слишком большим, либо вам необходимо ссылаться на них из нескольких решений. Как указано выше, проект не должен зависеть ни от чего, кроме корня проекта. Поэтому вы не должны зависеть от вывода внешнего проекта и, следовательно, зависеть от A. проекта, присутствующего на компьютере разработчика, и B. находящегося в правильном месте.
Есть несколько способов преодолеть это:
- Пусть проект API будет подпроектом внутри основных проектов с использованием чего-то вроде субмодулей Git или внешних элементов SVN. Это работает в некоторой степени, но есть некоторые меры предосторожности, которые вам нужно будет предпринять, в Интернете есть множество знаний.
- Добавьте сборки в папку lib зависимых проектов и относитесь к ним как к сторонним сборкам, что и есть на самом деле.
Второй шаг - мой привилегированный root, это можно сделать автоматически на сервере сборки или вручную, скопировав выходные данные сервера сборки в проект локально. Все зависит от того, хотите ли вы иметь постоянную интеграцию или периодическую интеграцию.