Как мне управлять ссылками на элементы развертывания, которые могут быть либо при установке x86, либо при установке x64 для проекта на основе MSTest?

Question

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

Из-за размера установки и других факторов проверка в этой папке установки в системе контроля версий для совместного использования членами группы просто невозможна.

Путь установки для папки: / Program Files / InternalTool / или / Program Files (x86) / InternalTool / , в зависимости от установленной среды. Я хочу настроить мой файл .testrunconfig таким образом, чтобы, когда человек получает последнюю версию решения, ему не нужно было беспокоиться о исправлениях пути к общему внутреннему набору библиотек.

Есть ли способ сделать это беспрепятственно для всех вовлеченных членов, и если да, то как можно это сделать?

Ограничения следующие:

• не могу проверить в общем наборе
• общий набор не имеет переопределения для пути установки

Возможно ли это, или я прошу слишком много?

Answer 1

Это было на самом деле намного проще, чем я ожидал.

Несмотря на то, что пользовательский интерфейс не поддерживает многие вещи с помощью локального файла конфигурации запуска теста, я смог установить путь с помощью стандартного% ProgramFiles%.

• В системах x86 это разрешает в большинстве систем C: \ Program Files \.
• В системах x64 это разрешает в большинстве систем C: \ Program Files \.

Но! Если вызывающий является 32-разрядным, а не 64-разрядным или не настроен на MSIL,% ProgramFiles% будет преобразован в C: \ Program Files (x86) \. Поскольку нет 64-битного mstest, разрешение должно происходить без проблем. Например, это извлечено из моего файла LocalTestRun.testrunconfig, а затем правильно очищено:

  <Deployment>
    <DeploymentItem filename="%ProgramFiles%\InternalSuite\" />
  </Deployment>

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

Надеюсь, это поможет кому-то еще!

Answer 2

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

В некоторых случаях мы автоматизируем это в пакетном задании, которое получает последнюю версию.