Могу ли я построить тестовое решение CodedUI с использованием msbuild на другом компьютере?

Question

У меня есть версия VS2015 Enterprice (которая требуется для компиляции проектов CodedUI - исправьте меня, если я ошибаюсь).

Проекты имеют некоторые модульные тесты CodedUI.

1) I может построить решение на моем Dev PC в VS2015 - никаких проблем. 2) I может построить решение на моем компьютере Dev с помощью msbulid.exe solution.sln - без проблем. 3) У меня есть еще один ПК (test pc), где есть NO Visual studio, только встроенные средства разработки и .NET Framework установлены. Когда я пытаюсь построить решение с помощью msbuild.exe - есть ошибки, связанные с Test Tools:

Assertion\Assert_WPF.cs(6,40): error CS0234: The type or namespace name 'UITesting' does not exist in the namespace 'Microsoft.VisualStudio.TestTools' (are you missing an assembly reference?) 

Мой вопрос: можно ли вообще построить решение, которое включает в себя CodedUI (который включается только в Enterprise edition) на тестовой машине, где VS не установлен?

Answer 1

У нас была эта проблема. Это очень common.

При установке VS Enterprise вы также устанавливаете файлы CodedUI .dll в свой глобальный кэш сборок. Это то, что позволяет тестировать пользовательские интерфейсы. Ваш проект на вашей машине-разработчике ссылается на них.

Если вы попытаетесь запустить их в другом месте, они будут искать эти .dll и не найти их.

У вас есть два варианта:

1. Проведите ~ $ 3k на лицензию предприятия на машину вы хотите построить испытания под
2. Создать NuGet пакет (или эквивалентное решение), содержащие необходимые codedUI. DLL. Обновите свой проект, чтобы ссылаться на этот пакет, а не на GAC (обратите внимание, что это довольно сложно). Обеспечьте, чтобы пакет был развернут вместе с вашим решением при построении машины без предприятия.

Вы также можете застрелить codedUI .dlls в GAC вашей другой машины, используя Gacutil, но я не рекомендую это.

Answer 2

Извините за размещение в таком старом вопросе, но вчера я столкнулся с той же проблемой.

Ответы Ryanmans могут быть правильными, но есть и другие способы решения этой проблемы, которые я нашел. Если вы посмотрите внутрь соответствующей .csproj файл, который вы найдете что-то похожее на это:

<Choose> 
<When Condition="'$(VisualStudioVersion)' == '10.0' And '$(IsCodedUITest)' == 'True'"> 
    <ItemGroup> 
    <Reference Include="Microsoft.VisualStudio.QualityTools.CodedUITestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> 
     <Private>False</Private> 
    </Reference> 
    <Reference Include="Microsoft.VisualStudio.TestTools.UITest.Common, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> 
     <Private>False</Private> 
    </Reference> 
    <Reference Include="Microsoft.VisualStudio.TestTools.UITest.Extension, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> 
     <Private>False</Private> 
    </Reference> 
    <Reference Include="Microsoft.VisualStudio.TestTools.UITesting, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> 
     <Private>False</Private> 
    </Reference> 
    </ItemGroup> 
</When> 
</Choose> 

Как вы можете видеть ссылки, которые используются только тогда, когда конкретная визуальные студийная версия используются. Теперь, если вы используете msbuild, вы точно увидите ошибки, которые вы сделали. Потому что ссылки действительно отсутствуют. Обходным путем является присвоение рассматриваемого проекта символу компиляции. (Rightclick -> Свойства). Вы можете не использовать этот символ в качестве параметра в MSBuild команды следующим образом:

/p:DefineConstants="YourSymbolName" /t:Rebuild 

Это устранило ошибки для меня и нашей сборки сервер строит проект просто отлично.