MSTest: разумный способ развертывания элементов из общего каталога?

Недавно я потерял несколько волосков, пытаясь справиться с DeploymentItem.

У нас есть несколько общих каталогов для собственных dll, и многие тесты зависят от них.

Для проектов C++ мы используем propertypages, где эти пути определены. Они даже могут быть импортированы в проект C#, а также с некоторым ручным редактированием (так как они являются файлами MSBuild). До сих пор я не могу понять, как использовать их в тестах.

К сожалению, DeploymentItemAttribute не может использовать свойства на листе, но он может использовать переменные окружения. Я надеялся избежать необходимости заставлять всех определять глобальные переменные среды...

Я видел различные предложения по сети, но на самом деле не нашел простого решения.

У кого-нибудь есть хороший подход к этому ?

2 2
mstest deploymentitem

2 ответа:

Ответ Андерса-хорошее решение, но в моем случае:

  1. мне не нравится идея хранения двоичных файлов в дереве исходных текстов
  2. многие библиотеки DLL не имеют определенных версий, и они регулярно обновляются. основа.

Каким-то образом я пришел к такому решению:

Во-первых, я включил в тестовый проект страницу свойств global VC++. Это должно быть сделано вручную, добавив эту директиву под тегом <Project> сверху .csproj:

<Import Project="$(UserProfile)\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props" />

I теперь получил доступ к свойствам / макросам, которые определяют пути dll в моей среде C++.

Я тогда

  1. добавлена новая подпапка в тестовом проекте, скажем "NativeDlls"
  2. добавил необходимые библиотеки DLL в виде ссылок в папку Nativedls
  3. ссылки являются абсолютными, но могут быть заменены макросами из таблица свойств, включенная выше:

<Content Include="$(MyLibLocation)\GDAL18BIN\gdal18.dll">

<Link>NativeDlls\mylib.dll</Link>

<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>

</Content>

Библиотеки DLL затем готовы к развертывание: 

[TestMethod]
[DeploymentItem(@"NativeDlls")]
public void TestSomeStuff()
{
}

И, как упоминает Андерс: оставшаяся работа состоит в том, чтобы установить условия debug/release и 32/64.

2

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

Если вы можете переместить зависимости в исходное дерево (например, $svnroot / trunk / dependencies), то вы можете использовать тестовое развертывание только с относительными путями. Он будет работать под TeamCity, а также на любой машине разработчика.

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

EDIT: переместил комментарий об управлении бинарными зависимостями сюда

Для csprojs у меня просто есть dll-ссылка в проектах на dll:s в каталоге lib под деревом исходных текстов (т. е. ссылка на ..\lib\log4net.файл DLL). Если вы хотите ссылаться на отдельные библиотеки для отдельных сборок, например, разные для x86 / 64 или Debug / Release, то VS не поддерживает их, но MsBuild и файл csproj поддерживают, поэтому вы можете добавлять условные ссылки, но вам нужно отредактировать csproj с помощью рука, чтобы включить, например, зависимость x86 только если платформа x86 и так далее.

1