Решение VS 2010 в зависимости от другого решения

Question

У меня есть 2 решения (скажем, Master Framework M и Slave Project S). М используется многими решениями типа S. В процессе сборки я собираю все библиотеки DLL из M, а затем использую их в S. Во время работы я бы хотел более быстрый цикл, в котором я мог бы легко изменить M и сразу же использовать в S.

Все проблемы, о которых вы, возможно, знаете, связаны с тем, как вы ссылаетесь на библиотеки или проекты в файле csproj.

Если вы хотите связать DLL, вы должны сделать что-то вроде этого

<Reference>
  <HintPath>..\lib\$(Platform)\$(Configuration)\M.Example.dll</HintPath>
</Reference>

Если вы хотите связать проект (даже из другого решения), вы должны сделать это следующим образом

<ProjectReference Include="..\path to project in other solution\M.Example.csproj">
  <Project>{2009D1C4-E18F-6CF8-8AA4-B53A1B2F1009}</Project>
  <Name>M.Example</Name>
</ProjectReference>

И это написано прямо в файле проекта C # (csproj)! Таким образом, вы не можете использовать проект или DLL для разных целей в одном файле

Я не хочу поддерживать 2 файла csproj, один из которых ссылается на все библиотеки DLL для процесса сборки, а другой - со ссылками на проекты для целей разработки и CI.

У меня были две основные идеи: 1) Оставьте 2 различных решения и работайте в M, затем создайте и работайте в S, ссылаясь только на DLL и используя собственный проект ввода (только в разработке), который копирует DLL, созданную в M, в каталог lib S, чтобы S мог использовать их без поиск вне корня S или ссылки на другие проекты.

2) Используйте подобное условие

<Reference Condition='$(BUILDING)!=""'>
  <HintPath>..\lib\$(Platform)\$(Configuration)\M.Example.dll</HintPath>
</Reference>

<ProjectReference Condition='$(BUILDING)==""' Include="..\path to project in other solution\M.Example.csproj">
  <Project>{2009D1C4-E18F-6CF8-8AA4-B53A1B2F1009}</Project>
  <Name>M.Example</Name>
</ProjectReference>

Где BUILDING определяется только в официальном процессе сборки.

Я хотел бы сделать это намного проще и, возможно, умнее

Answer 1

Я бы обозначил первое решение:

В вашем решении M используйте События PostBuild , чтобы скопировать последние двоичные файлы сборки в каком-то месте.И S-проекты используют эти двоичные файлы, ссылаясь на них как библиотеки DLL в проекте.

Таким образом, когда вы перестраиваете M один раз, все S-проекты будут ссылаться на последнюю версию M.

Answer 2

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

Обычно вы хотите генерировать Мастер (M) каждый раз, когда вы меняете его. Представьте, что вы изменили M, чтобы у него была новая функция для S1, и все работает отлично. Некоторое время спустя вы пытаетесь скомпилировать S2 и получить исключение на основе изменений в M, которые вы сделали для S1.

Чтобы избежать этой проблемы, вы обычно используете номера версий, чтобы убедиться, что p.e. S1 работает с версией 1.0 M и S2 работает с версией 1.1 M. Конечно, вы хотите, чтобы ваш главный проект всегда был совместим со всеми версиями, но это может быть сложно поддерживать, и вы будете рады, если изменение затормозит не более одного ведомого проецировать время.

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

UPDATE:
Кроме того, я нашел эту статью, которая очень хорошо объясняет управление решениями:
http://msdn.microsoft.com/en-us/library/ee817674.aspx