Udało mi się opracować i wdrożyć aplikację ClickOnce, która rejestruje powiązane rozszerzenie pliku, na przykład*.abc. Kiedy klikam plik o nazwiex.abc lub jeśli piszęx.abc z wiersza polecenia uruchamia się aplikacja ClickOnce i mogę pobrać plik za pośrednictwem dedykowanego interfejsu API. Mogę również uruchomić aplikację programowo za pomocą następującego kodu:

System.Diagnostics.Process.Start ("x.abc");

Wszystko działa dobrze na moim 64-bitowym pudełku z Windows Vista.

Jeśli jednak spróbuję zrobić dokładnie to samo na Windows 7 (także 64-bitowym), mam bardzo dziwny problem. Oto, co obserwuję:

Ręczny początekx.abc poprzez dwukrotne kliknięcie go w Eksploratorze.Ręczny początekx.abc z wiersza poleceń działa.Process.Start("x.abc") nie uruchamia aplikacji; jednak zwrócony obiekt procesu pokazuje, że nie wystąpił błąd i że aplikacja ClickOnce w jakiś sposób zakończyła działanie. Ale nawetTrace na samym początku aplikacji ClickOnce nigdy nie jest osiągnięta.Nieznajomy jeszczeProcess.Start("x.bat") z plikiemx.bat zawierające pojedynczą linięx.abc nie uruchamia również aplikacji ClickOnce! Podobniex.bat rozpoczęty z Eksploratora (oczywiście).

Próbuję analizować, co się dziejeProcMon nie był bardzo pomocny, ponieważ z mojego punktu widzenia proces uruchamiania aplikacji ClickOnce jest bardzo trudny. Obserwujęrundll32 dostanie się do pracy, ale nie ma dowodów na niepowodzenie.

Program, który robiProcess.Start jest pełną zaufaną aplikacją konsolową, która nie ma nic szczególnego.

Nie widzę, co zmieniło się w odniesieniu do sposobu obsługi aplikacji ClickOnce w systemie Windows 7 i dlaczegoProcess.Start nie zrobiłby dokładnie tego samego, co uruchomienie pliku z Eksploratora. Warto wspomnieć, że przy użyciu bardziej zaawansowanych wersjiStart metoda zProcessStartInfo i ustawienieUseShellExecute dotrue też nie pomógł.

Startowycmd zProcess.Start a następnie próbuje uruchomićx.abc pokazuje dokładnie ten sam problem. Jeśli porównuję ustawienia środowiska zcmd uruchamiany ręcznie, widzę różnice w sposobieProgramFiles jest zdefiniowany (pierwszy wskazuje naC:\Program Files (x86) podczas gdy drugi wskazujeC:\Program Files). Aplikacje uruchomione z mojej aplikacji .NET są uruchamiane w 32-bitowej warstwie emulacji (SysWoW64).

Udało mi się odtworzyć awarię uruchomieniax.abc uruchamiając 32-bitową wersję wiersza polecenia (czyli%windir%\SysWoW64\cmd.exe) a następnie wpisującx.abc w wierszu polecenia. Odkryłem też brzydkie obejście, polegające na uruchomieniu 64-bitowego wiersza polecenia ze środowiska 32-bitowego przez uruchomienie%windir%\Sysnative\cmd.exe /C x.abc zamiastx.abc.

Ale wolę to zrobić w czysty sposób (lub poprosić przedstawiciela Microsoftu, aby powiedział mi, że jest to rzeczywiście problem z Windows 7 i / lub ClickOncce i że zostanie to naprawione wkrótce).