ClickOnce應用程序不是通過Process.Start（「x.abc」）啓動的，並且* .abc與ClickOnce應用程序關聯

Question

我已經成功開發並部署了註冊關聯文件擴展名的ClickOnce應用程序，例如*.abc。當我點擊名爲x.abc的文件時，或者如果從命令提示符鍵入x.abc，ClickOnce應用程序將啓動，並且可以通過專用API檢索文件。我還可以通過編程用下面的代碼啓動應用程序：

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

一切正常，在我的Windows Vista的鑽頭箱。但是，如果我嘗試在Windows 7（也是64  位）上執行完全相同的操作，則會出現一個非常奇怪的問題。這裏是我觀察到的：

1. 手動啓動x.abc通過雙擊它從資源管理器工程。
2. 手動啓動x.abc從命令提示符起作用。
3. Process.Start("x.abc")不啓動應用程序;但是，返回的過程對象顯示沒有錯誤，並且ClickOnce應用程序立即退出。但即使在ClickOnce應用程序的最初階段，也不會達到Trace。
4. 陌生人，但Process.Start("x.bat")與文件x.bat包含單行x.abc也不啓動ClickOnce應用程序！相同的x.bat從資源管理器開始工作（當然）。

試圖分析ProcMon會發生什麼並不是很有用，因爲從我的角度來看，啓動應用程序的ClickOnce過程非常難以遵循。我觀察到rundll32開始工作，但沒有任何失敗的證據。

正在做Process.Start的程序是一個完全沒有任何花哨的完全信任控制檯應用程序。

我無法看到在Windows 7上如何處理ClickOnce應用程序以及爲什麼Process.Start與從Explorer啓動文件不同。值得一提的是，使用Start方法的更高級版本與ProcessStartInfo並且設置UseShellExecute到true也沒有幫助。

從cmd開始Process.Start然後嘗試啓動x.abc顯示完全相同的問題。如果我將環境設置與手動啓動的cmd進行比較，我會看到ProgramFiles的定義差異（第一個指向C:\Program Files (x86)，而第二個指向C:\Program Files）。從我的.NET應用程序啓動的應用程序在32位仿真層（SysWoW64）上啓動。

通過啓動32位版本的命令提示符（即%windir%\SysWoW64\cmd.exe），然後在提示符處輸入x.abc，我能夠重現x.abc的啓動失敗。我還發現了一個醜陋的解決方法，即通過啓動%windir%\Sysnative\cmd.exe /C x.abc而不是x.abc從32位環境啓動64位命令提示符。

但我寧願使用乾淨的方式來做到這一點（或者有一位微軟代表告訴我這確實是Windows 7和/或ClickOncce的一個問題，而且它很快就會被修復）。

Answer 1

我想出了一個基於.BAT的解決方案，它很容易實現。假設您想要啓動與*.abc文件關聯的ClickOnce應用程序，那麼您只需在同一文件夾中放置一個具有相同名稱但*.bat擴展名的文件，然後執行該批處理文件即可。下面是批處理腳本：

if exist "%windir%\sysnative\cmd.exe" goto :mode64bit 

rem For a file named "C:\foo\xyz.bat", this will generate the corresponding 
rem "C:\foo\xyz.abc" file, built as the concatenation of the drive (%~d0), 
rem the folder (%~p0) and the file name (%~n0), plus ".abc": 

"%~d0%~p0%~n0.abc" 
goto :end 

:mode64bit 

rem When running in a 32-bit emulation environment on a real 64-bit system, 
rem start the 64-bit version of CMD.EXE, and make if start the ".abc" file 
rem for us: 

C:\Windows\sysnative\cmd.exe /c "%~d0%~p0%~n0.xgen" 

:end 

這可以直接在*.abc文件的調用來實現，但有時一個批處理文件，有助於在轉型...

Answer 2

只能啓動系統範圍的擴展程序，如.bat甚至.txt，但它不能始終通過擴展啓動正確的程序。

相反試試這個API或類似的替代在.NET：

FindExecutable：shell32.dll中別名 ：「FindExecutableA」/ 「FindExecutableW」返回類型：INT參數： ·lpFile指向以NULL結尾的字符串的指針指定一個 文件名。這可以是一個文檔或 可執行文件。 ·lpDirectory指向空終止字符串的指針，指定 默認目錄。 ·lpResult指向緩衝區的指針，當 函數返回時接收文件名。該文件名是 以NULL結尾的字符串，指定在lpFile參數中指定的文件 上運行「打開」 關聯時啓動的 可執行文件。

這將返回一個整數大於零，如果成功，char值將包含一個null-terminated string指向一個啓動該文件擴展名 可執行文件，那麼你可以使用它像這樣

System.Diagnostics.Process.Start ("program.exe $:\path\x.abc"); 

代替program.exe，您將使用API​​函數的結果，並且您將使用與命令行一樣用空格分隔的文件路徑。

至於應用程序失敗，它可能表明程序需要管理權限才能正常運行。 cmd已經獲得了管理權限，所以它可以讓子應用程序繼承它，但不是Windows API。 createprocess允許您使用LPSECURITY屬性，這有助於以正確的權限啓動該程序。

Answer 3

它看起來像你已經建立你的應用程序使用'x32'作爲目標平臺，這使得Process.Start產卵x32位進程。據我猜測，Windows 7分別爲32位和64位應用程序存儲文件關聯。

如果您沒有COM或非託管32位依賴項，您可以嘗試構建「任意」目標平臺而不是「x32」的應用程序。

我調查了一些進一步的，發現的ClickOnce安裝程序創建的任何相關文件擴展名以下開放動詞（GUID每個應用程序唯一的）：

rundll32.exe dfshim.dll, ShOpenVerbExtension {dce01888-35e8-4df3-af35-cd971f520d8d} %1 

使用Process Monitor，我發現，32位版本失敗打開HKCU\Software\Classes\Wow6432Node\CLSID\{dce01888-35e8-4df3-af35-cd971f520d8d}註冊表項。 （64位版本成功打開它在HKCU\Software\Classes\CLSID\{dce01888-35e8-4df3-af35-cd971f520d8d}。）

所以對我來說這確實是一個ClickOnce錯誤。如果我是你，我會用那個骯髒的%WinDir%\system32\cmd.exe /C test.abc解決方法。 （這似乎工作 - 嘗試從x32任務管理器。）

我已將此問題添加到 Microsoft Connect （更新2013-02-13：該鏈接已爛）。

Answer 4

您是否嘗試過使用ShellExecute（）; API？

 [DllImport("Shell32.dll",CharSet=CharSet.Auto)] 
    public static extern IntPtr ShellExecute(
     IntPtr hwnd, 
     string lpVerb, 
     string lpFile, 
     string lpParameters, 
     string lpDirectory, 
     int nShowCmd); 

ShellExecute(this.Handle,"open","x.abc","","",3); 

你也可以試試Shell（）;功能是框架的一部分