Несколько важных путей для .NET Process - PullRequest
6 голосов
/ 24 июня 2011

В проекте, над которым я сейчас работаю, я запускаю внешний процесс. Однако внешний процесс представляет собой EXE-файл сложной программы, которая загружает информацию о текущем пользователе из пользовательской папки. Ярлык на рабочем столе для программы решает проблему, устанавливая параметр «Target:» равным X:\exepath\prgm.exe и устанавливая параметр «Start In» для пути пользователя, X:\exepath\users\username.

Я сейчас запускаю процесс так:

Process p = new Process();
p.StartInfo = new ProcessStartInfo( "X:\exepath\prgm.exe" );
p.StartInfo.WorkingDirectory = "X:\exepath\users\username";
p.Start();
while (!p.HasExited) { }

Однако, когда процесс запускается, запускаемая им программа в конечном итоге ищет все ресурсы в WorkingDirectory вместо того, чтобы извлекать пользовательский контент из этой папки и весь другой контент из каталога, в котором находится EXE. Это предполагает, что Working Directory и системный ярлык «Start In:» ведут себя по-разному.

Есть ли способ имитировать такое поведение с помощью процесса C #? В качестве альтернативы, можно ли создать ярлык в C #, который я мог бы затем начать с моего вызова процесса?

Пожалуйста, дайте мне знать, будет ли полезна дополнительная информация.

РЕДАКТИРОВАТЬ -

После еще нескольких проб и ошибок я решил использовать WSH, чтобы создать ярлык и запустить его. WSH использует имя WorkingDirectory для значения параметра «Start In:». Это ведет себя идентично под капотом как выполнение процесса в моем коде выше. Я все еще получаю сообщение об ошибке.

Ответы [ 2 ]

1 голос
/ 28 июня 2011

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

Код, который я разместил в OP, был примером кода, чтобы проиллюстрировать проблему.В моем реальном проекте я извлекал ExePath и UserPath из разделов реестра.Проект представляет собой инструмент выбора, позволяющий переключаться между несколькими установленными версиями стороннего программного обеспечения, и считывает / редактирует эти ключи реестра для выполнения своей работы.

Когда я писал код, который пишет в реестре я использовал DirectoryInfo.FullPath, который возвратил "X:\ExePath" вместо "X:\ExePath\".Это сделало программу неспособной найти нужные ей файлы из папки ExePath, ища X: \ ExePathsettings.inf "вместо" X: \ ExePath \ settings.inf ". Я вставил конечные косые черты в свой код и в существующий реестри все работает просто отлично.

Извлеченный урок: всегда проверяйте значения пути очень, очень тщательно.

1 голос
/ 24 июня 2011

Разница, вероятно, связана с использованием процесса Shell для выполнения: http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.useshellexecute.aspx

Свойство WorkingDirectory ведет себя иначе, когда UseShellExecute имеет значение true, чем когда UseShellExecute имеет значение false.Когда значение UseShellExecute равно true, свойство WorkingDirectory указывает расположение исполняемого файла.Если WorkingDirectory - пустая строка, то в текущем каталоге содержится исполняемый файл.

Если для UseShellExecute задано значение false, свойство WorkingDirectory не используется для поиска исполняемого файла.Вместо этого он используется запущенным процессом и имеет значение только в контексте нового процесса.

Я подозреваю, что если для p.StartInfo.UseShellExecute задано значение false, он может вести себя так, как вы хотите.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...