Узнать «битность» текущей ОС в MSBuild

У меня есть сценарий сборки, который должен жестко кодировать путь в исполняемый файл. Путь:

• C: \ Program Files \ Microsoft Visual Studio 9.0 \ SmartDevices \ SDK \ SDKTools \ cabwiz.exe

Это работает нормально, но теперь я работаю на 64-битной ОС (но мой коллега и сервер сборки все еще работает на 32-разрядной версии).

Мне нужен следующий путь:

• C: \ Program Files (x86) \ Microsoft Visual Studio 9.0 \ SmartDevices \ SDK \ SDKTools \ cabwiz.exe

Но используйте обычный путь для других.

Вот как я его настроил: ...

В нашем приложении есть фоновый поток, который порождает процесс через System.Diagnostics.Process :

Process.Start(
    new ProcessStartInfo
    {
        FileName = url,
        UseShellExecute = true
    }
);

Раньше у него вообще не было проблем. Но теперь фоновый поток тихо умирает; он никогда не возвращается из вызова в Process.Start . Блок catch для этого кода, который обрабатывает System.Exception , также не достигается. Даже если я включаю обработку исключений, когда они появляются в отладчике Visual Studio, я не вижу исключений. Странно, процесс порождается просто отлично; браузер по умолчанию для пользователя запускается с ожидаемым URL-адресом.

Точка входа нашего процесса помечена [STAThread] , как рекомендовано.

Что может вызвать молчаливое завершение потока? Есть ли какие-либо методы, которые я могу использовать для отладки чего? происходит ли во время завершения потока?

Обновление:

Похоже, что поток все-таки жив; он просто не возвращается с звонка. Вот его трассировка стека:

• [В режиме ожидания или присоединения]
• System.dll! System.Diagnostics.ShellExecuteHelper.ShellExecuteOnSTAThread () + 0x63 байта
• System.dll! System.Diagnostics.Process.StartWithShellExecuteEx (System.Diagnostics.ProcessStartfo) startInfo) + 0x19d байт
• System.dll! System.Diagnostics.Process.Start () + 0x39 байт
• System.dll! System.Diagnostics.Process.Start (System.Diagnostics.ProcessStartInfo startInfo) + 0x32 байт
• Мой метод

Обновление 2:

Запуск cmd.exe без использования оболочки для выполнения работ в качестве обходного пути. Огромное спасибо! Тем не менее, я все еще хотел бы знать , почему вызов не возвращается.

Обновление 3:

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

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