Работа с зависимостями в большом проекте ... Возможно ли надежно изменить порядок сборки, не используя зависимости проекта в C # / VS2008? - PullRequest
0 голосов
/ 03 декабря 2009

У меня есть устаревший проект в VS2008, который мы собираемся начать рефакторинг для лучшей компонентизации. Ссылки между 150 проектами в решении являются грязными, поэтому в качестве отправной точки я пытаюсь, по крайней мере, добраться до того момента, когда несколько проектов используют двоичные ссылки на другие проекты, в то время как другие используют ссылки на проекты. (Из соображений времени сборки)

Чтобы проиллюстрировать, учитывая проекты A, B и C, я хотел бы видеть ...

A ссылки C.dll

B ссылки C.csproj

Теперь проблема в том, что мне нужно убедиться, что C.csproj собирается до A.csproj. Я знаю, что могу управлять порядком сборки, используя зависимости проекта, но это, кажется, вызывает именно то поведение, которого я пытаюсь избежать ... сборка A всегда вызывает сборку C. Я уверен, что могу напрямую подключиться к файлам proj или sln, чтобы собрать вещи в нужном мне порядке, но я также уверен, что это будет перезаписано в короткие сроки благодаря автоматической магии VS.

Есть ли какой-нибудь способ надежно контролировать этот порядок, или я здесь упускаю что-то очевидное?

Спасибо ...

Ответы [ 2 ]

1 голос
/ 03 декабря 2009

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

Затем используйте процесс сборки для построения решений в правильном порядке, начиная с наименее зависимых пакетов.

По моей оценке, с точки зрения SCM Решение == Пакет UML == Модуль слияния (все решения создают модуль слияния)

1 голос
/ 03 декабря 2009

Вы можете создавать собственные файлы msbuild вместо того, чтобы полагаться на файлы .csproj и .sln, так что, в зависимости от выбранной цели, он будет создавать только определенные сборки. Это потребовало бы изучения msbuild, если вы еще этого не знаете.

...