Visual Studio 2008, MSBuild: «замена» проектов

Question

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

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

Я не очень хорошо знаю VS / MSBuild, но готов учиться всему, что нужно. Является ли это возможным? Я ищу идеи ... Мы используем Subversion, и приветствуются решения, включающие некоторые взломы внутри VCS.

Answer 1

Создайте еще одну конфигурацию сборки для вашего проекта. Таким образом, у вас будет как минимум 2 конфигурации сборки, например Debug_SpecialNeeds and Debug.

Answer 2

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

Answer 3

Более глубокая проблема, которую я вижу здесь, заключается в том, что вашей библиотеке «требуется специальная среда для сборки», особенно потому, что она зависит от «большого количества внешних библиотек и инструментов». Я бы посоветовал вам НЕ идти по пути создания фиктивной библиотеки, а вместо этого сосредоточиться на том, чтобы правильно построить библиотеку без специальной среды. Вы можете достичь этого, включив все эти зависимости в систему управления версиями вместе с вашим проектом, и ссылаться на эти зависимости через относительные пути внутри вашей рабочей копии. В моих средах сборки я стараюсь максимально избегать статических зависимостей среды (в идеале ограничиваясь только самой платформой .NET).

Чтобы получить зависимости в систему контроля версий, вы можете либо проверить их непосредственно в самом проекте, либо проверить их в другом месте, а затем «ссылаться» на них в своем проекте через svn: external определения. В моей среде у меня есть отдельный репозиторий «bin», используемый только для такого рода зависимостей библиотек сторонних производителей, и тогда многие зависимые проекты могут извлекать их через внешние компоненты.

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

Answer 4

Для обсуждения я предполагаю, что у вас есть каталог проекта, содержащий файл вашего решения, файл проекта "RealLibrary \ RealLibrary.csproj" (ваша "настоящая" библиотека с зависимостями) и "MockLibrary \ MockLibrary.csproj". "file (ваша" фиктивная "библиотека с пустыми реализациями).

Если я правильно понимаю, вы хотите легко «поменять» MockLibrary на RealLibrary в своем решении, и наоборот.

Самый простой / хакерский способ сделать это, предполагая, что ваше решение (и зависимые проекты) настроены на поиск проекта "RealLibrary.csproj", - это переименовать каталог "RealLibrary" (не важно, к чему) и переименуйте каталог «MockLibrary» в «RealLibrary» и переименуйте «MockLibrary.csproj» в «RealLibrary.csproj». Это эффективно «обманет» ваше решение и зависимые проекты при загрузке «фиктивной библиотеки», даже если они ссылаются на «реальную библиотеку».

Несколько более сложное (и, возможно, более чистое) решение состоит в том, чтобы фактически изменить ваши файлы "sln" и "csproj", чтобы они ссылались на "MockLibrary.csproj" вместо "RealLibrary.csproj". В файле «sln» вам нужно изменить путь к проекту в разделе вверху:

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}"
EndProject

Вам необходимо изменить этот путь "RealLibrary \ RealLibrary.csproj" на "MockLibrary \ MockLibrary.csproj". Если вам нужна полнота, вы также можете изменить имя (или, возможно, просто использовать общее имя, например «Библиотека», для имени).

Аналогично, в зависимых файлах csproj вам нужно найти все экземпляры узла «ProjectReference», где вы ссылаетесь на «RealLibrary.csproj», и изменить путь. Эти разделы выглядят так:

<ProjectReference Include="..\RealLibrary\RealLibrary.csproj">
  <Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project>
  <Name>RealLibrary</Name>
</ProjectReference>

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