c# - wix toolset教學




在程序文件下運行.exe時出現System.UnauthorizedAccessException (2)

通過WiX安裝程序,我安裝了我的Windows應用程序,並在 c:\ProgramFiles 使用.exe和必需的dll創建了文件夾。

運行.exe時,我收到 System.UnauthorizedAccessException

如果有任何有用的建議,請告訴我。

請查看以下事件日誌以供參考。

Application: xxxxxxx.exe
Framework Version: v1.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.UnauthorizedAccessException
   at System.IO.__Error.WinIOError(Int32, System.String)
   at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
   at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions, System.String, Boolean, Boolean, Boolean)
   at System.IO.StreamWriter.CreateFile(System.String, Boolean, Boolean)
   at System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding, Int32, Boolean)
   at System.IO.StreamWriter..ctor(System.String, Boolean)
   at System.IO.File.AppendText(System.String)

原因

這看起來像一個簡單的訪問衝突 - 您嘗試獲取對您沒有權限的文件的寫訪問權限 - 在您運行的上下文中 %ProgramFiles% 下的文件對於普通用戶或非高級管理員不可寫) -禁止文件虛擬化,請參閱下面的第 9 節)。

這是一個通用的啟動錯誤檢查列表 - 可能沒用,因為你基本上有一個簡單的訪問衝突(看起來似乎)。 不知道為什麼鏈接的答案被低估了。 我可能搞砸了幾點 - 這只是一個雜亂的清單,旨在激發一些想法。 包括這里以便於檢索。

建議的可能修復

下面列出了一些可用於解決問題,解決問題原因或重新設計事物的方法,以便有效避免問題。 並且有一些方法僅僅是可能的並且很少使用。

以下列表不按優先順序排列 。 事實上,在我看來,第 1 號方法是非常不受歡迎的。 方法 6 可能是有效的,但不是很好(當然比 1 好)。 我可以忍受其他方法( 9 除外), 2 可能是最常用的方法。

1.提升應用程序(管理員權限) :正如其他人建議您可以使用 管理員權限 運行您的應用程序(這些天非常糟糕的做法 - 管理員權限無處不在,城市的關鍵,並使您的應用程序成為黑客目標,並使應用程序更危險,如果它包含口徑錯誤)。 這是一個簡短的操作方法: 如何強制我的.NET應用程序以管理員身份運行?

  • 僅限管理員用戶 :至關重要的是,提升對普通用戶不起作用! (系統將提示他們輸入管理員密碼)。 只有管​​理員才能提升
  • 空白管理員密碼 :如果包裝盒上有空白管理員密碼(在家用PC上很常見),任何用戶都可以將任何二進制設置提升為管理員權限(使用空白密碼帳戶) - 同時登錄到他們自己的受限帳戶(他們顯然也可以使用空白密碼帳戶以管理員身份登錄並啟動任何內容 - 因此安全漏洞已經存在空白密碼,無論高程問題如何 - 但為什麼允許使用空白密碼帳戶進行提升? )。
  • UAC :UAC被禁用後會發生什麼? 標準用戶可能不會被提示輸入密碼,啟動失敗? 我還沒有機會嘗試。
  • 安全性 :在某些情況下,提升的進程似乎能夠啟動其他可以超過原始進程的高級進程(取決於啟動用戶的NT權限)。 瘋狂。

2.用戶配置文件(移動文件) :您可以確定導致訪問衝突的文件(某種設置文件?)並將其移動到用戶在所有情況下都具有常規訪問權限的位置。 通常在用戶配置文件中的某個位置(推薦)。

3.只讀訪問 :通常,您可以使用設置文件的只讀訪問權限。 也許你可以強制執行這種方法嗎? 這一切都取決於您的應用程序的設計。 也許你可以 handle the access denied exception ,然後運行只讀?

4.內部默認值 :作為只讀方法的一種風格,您可能會丟失整個設置文件並依賴內部默認值。 我認為很少有選擇,但可能。

5.在線設置? :有些人喜歡完全消除設置文件(或使它們只讀),然後在啟動時從數據庫中檢索“真實設置”。 這種方法可以帶來巨大的優勢 - 特別是對於企業應用程序 - 設置管理和版本控制,消除用戶配置文件漫遊問題等等(當然還有挑戰 - network issuesfirewallproxy etc... )。

6. ACL權限 :您可以在安裝時對相關文件應用ACL權限,允許常規用戶寫入。 根本不是很棒的設計,但它會起作用 。 當然比運行管理員權限(提升)更好 - 因為你指出了所需的訪問權限,而不只是提升整個過程。 不要只設置對整個文件夾的完全訪問權限 - 只對單個文件打開寫訪問權限。

7. Windows服務 :在某些情況下,可以運行需要提升權限的應用程序部分作為Windows服務。 這不是我經常看到的方法,但可能。 然後,您將該服務安裝為以 LocalSystem 或等效的升級帳戶( 或使用服務帳戶 - 請參閱“ 其他方法 ”部分 - 或 此替代答案 )運行。 也許我也可以提到 scheduled task - 我從未嘗試過為這種情況使用計劃任務。

8.模仿 :我認為您可以冒充具有訪問權限的帳戶來寫入相關位置。 我不使用這種方法,所以我不確定技術細節,方面和挑戰。 只是把它作為一種選擇。

9.虛擬化方法 :剛才提到這一點。 各種形式的虛擬化 - 例如, 您可以啟用的策略允許將文件和註冊表寫入失敗重定向到可寫位置 (更多的是沿著 數據重定向 - 隨之而來的所有混亂 - 這不是解決方案 - 事實上微軟打算在將來的Windows版本中刪除該功能。不確定Windows 10中的狀態。 註冊表虛擬化上的MSDN )。 一般沒有問題解決,但幾個問題沒有得到承認。 總體上肯定會引起混淆,因為人們沒有看到數據寫入的位置,並且數據不是在用戶之間共享 - 而是用戶特定的。 還有像App-V這樣的全面虛擬化/數據流和允許完全訪問的容器。 不是我的專業,而不是我的偏好。

請不要使用此虛擬化或數據重定向廢話(遺留應用程序不會崩潰,不能使用新的應用程序)。 我仍然會添加指向該功能實際工作原理的一些技術細節的鏈接(在此重定向工作之前必須滿足一些先決條件): 在應用程序安裝子文件夾中的Windows資源管理器中看不到log4net日誌文件 recommended to show why this feature should never be used )。

以下鏈接是對每用戶文件部署主題以及如何在包中完成以及一些替代 網絡/數據庫/雲方法 的回答。

它可能是一個涉及的閱讀,但在這裡它 - 它實質上提供了上述可能性的一些排列

一些鏈接


不要試著寫應用程序不應該寫的地方。 使用其他文件夾,例如:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

如果沒有可能的替代方案,我非常懷疑,請使用管理權限運行可執行文件。

https://msdn.microsoft.com/en-us/library/bb756929.aspx





windows-installer