Тестовое развертывание VSTS и недопустимая культура сборки

Question

У меня есть DLL, которую я тестирую, которая ссылается на DLL, которая, как мне кажется, является недопустимым значением для AssemblyCulture. Значение равно «Нейтральный» (обратите внимание на прописную букву «N»), в то время как проверяемая DLL и каждая другая DLL в моем проекте имеют значение «нейтрально» (потому что они указывают AssemblyCulture("")).

Когда я пытаюсь развернуть DLL, которая связывает с проблемной DLL, я получаю эту ошибку в VSTS:

Failed to queue test run '...': Culture is not supported.
Parameter name: name
Neutral is an invalid culture identifier.

<Exception>System.Globalization.CultureNotFoundException: Culture is not supported. Parameter name: name
Neutral is an invalid culture identifier.
   at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
   at System.Globalization.CultureInfo..ctor(String name)
   at System.Reflection.RuntimeAssembly.GetReferencedAssemblies(RuntimeAssembly assembly)
   at System.Reflection.RuntimeAssembly.GetReferencedAssemblies()
   at Microsoft.VisualStudio.TestTools.Utility.AssemblyLoadWorker.ProcessChildren(Assembly assembly)
   at Microsoft.VisualStudio.TestTools.Utility.AssemblyLoadWorker.GetDependentAssemblies(String path)
   at Microsoft.VisualStudio.TestTools.Utility.AssemblyLoadWorker.GetDependentAssemblies(String path)
   at Microsoft.VisualStudio.TestTools.Utility.AssemblyLoadStrategy.GetDependentAssemblies(String path)
   at Microsoft.VisualStudio.TestTools.Utility.AssemblyHelper.GetDependentAssemblies(String path, DependentAssemblyOptions options, String configFile)
   at Microsoft.VisualStudio.TestTools.TestManagement.DeploymentManager.GetDependencies(String master, String configFile, TestRunConfiguration runConfig, DeploymentItemOrigin dependencyOrigin, List`1 dependencyDeploymentItems, Dictionary`2 missingDependentAssemblies)
   at Microsoft.VisualStudio.TestTools.TestManagement.DeploymentManager.DoDeployment(TestRun run, FileCopyService fileCopyService)
   at Microsoft.VisualStudio.TestTools.TestManagement.ControllerProxy.SetupTestRun(TestRun run, Boolean isNewTestRun, FileCopyService fileCopyService, DeploymentManager deploymentManager)
   at Microsoft.VisualStudio.TestTools.TestManagement.ControllerProxy.SetupRunAndListener(TestRun run, FileCopyService fileCopyService, DeploymentManager deploymentManager)
   at Microsoft.VisualStudio.TestTools.TestManagement.ControllerProxy.QueueTestRunWorker(Object state)</Exception>

Даже если я не буду ссылаться на DLL (в моем тесте оболочки VSTS или в тесте NUnit), как только я добавлю его в свой файл GenericTest (я упаковываю тесты NUnit), я получу это исключение .

У нас нет источника проблемы DLL, и он также подписан кодом, поэтому я не могу решить эту проблему путем перекомпиляции.

Есть ли способ пропустить развертывание зависимостей DLL DeploymentItem, исправить или отключить проверку культуры или обойти это запутанным способом (возможно, каким-то образом встроить сборку)? Есть ли способ переопределить значение для культуры, кроме взлома DLL (и удаления подписи кода, чтобы хак работал)? Может с внешним манифестом?

Любое правильное решение должно работать без странных изменений в рабочем коде. Мы не можем развернуть взломанную DLL, например. Это также должно позволить инструментарию DLL быть покрытым кодом.

Дополнительное примечание: я получаю предупреждение компоновщика при компиляции тестируемой DLL, которая ссылается на проблемную DLL, но это не сломало ничего, кроме VSTS, и отправлено несколько версий.

Answer 1

Я обнаружил, что если я занимаюсь инструментарием (что было целью меня даже беспокоиться об интеграции с NUnit VS), то мне удается избежать этих проблем. Не уверен, какая именно комбинация настроек сработала, но я использую следующие настройки:

• Контрольно-измерительные приборы на месте
• Тестовый проект MSTest зависит только от тестового проекта NUnit
• Общий тест развертывает тест NUnit (из выходной папки бина MSTest), тестовый файл NUnit app.config (из выходной папки бина тестового NUnit) и проблемную DLL. Остальные зависимости, включая тестируемую DLL, развертываются с помощью покрытия кода.

Если вам не нужны инструменты, я нашел этот обходной путь:

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

Запись файла из потока ресурсов сборки на диск

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

Answer 2

Я был бы признателен за альтернативу этому, но я нашел решение, которое работает для меня.

• Скомпилируйте код тестируемого проекта в DLL модульного теста вместо ссылки на встроеннуюDLL
• Взломайте проблемную DLL, чтобы удалить подпись кода, и измените «Нейтральный» на «нейтральный» (вручную изменил двоичный файл).
• Проверьте в проблемной DLL каталог проекта модульного теста.Не перезаписывайте рабочую версию
• Свяжите проект модульного теста с этой DLL вместо исходной проблемы DLL

Это не связано с изменениями в производственном коде, но требует дублирования усилий,Чтобы добавить / удалить исходные файлы из тестируемого проекта, вы также должны изменить проект модульного теста и добавить / удалить ссылку на эти файлы.Однако он не дублирует код, поскольку вместо дублирования исходного файла мы используем ссылку.

Редактировать : В какой-то момент это сработало, но я полностьюпотерял, как это работает, сейчас.Проблема с этим решением заключается в том, что у меня сборка в смешанном режиме, поэтому я не могу сделать правильный взлом, чтобы complete удалил настройку культуры.Явно установленное значение «нейтральный» работает только в некоторых местах.

См. Мой другой ответ для моих последних обходных путей.Они должны работать во всех случаях, хотя они также запутаны.