我在編寫工廠中多個用戶使用的內部應用程序。對dll的任何更改都需要在用戶計算機上運行安裝程序
這些不同的應用程序可能會引用相同的DLL。 在dll上所做的任何更改都需要爲安裝在其上的所有用戶PC上的所有應用程序運行安裝程序。
有沒有辦法在用戶的個人電腦上部署dll，這樣他們將得到最後的版本，而無需在每臺機器上運行安裝程序？
我可以通過創建一個批處理文件，它將首先將dll複製到安裝的文件夾，然後運行應用程序。但是，我真的不能接受。
不知道這是相關的答案，但我通過使用InstallShield限量版創建安裝
也許你的DLL屬於GAC（見What is the GAC in .NET?），其中給予適當的政策文件，你可以更新所有應用程序使用特定版本（或一系列版本）。這樣你甚至可以讓一些應用程序使用舊版本，如果你做了一個不再向下兼容的更改。
它可能是爭論的語義，但編寫批處理文件，PowerShell腳本或更新包是各種「設置」過程。
如果我排的方式來創建一個安裝我想對他們進行排名：
一個簡單的解決方案可能將該應用程序部署爲點擊一次，用戶必須在每次運行時檢查最新版本（以及它的依賴項）。如果需要更新，Click Once將會毫無疑問地處理它。圍繞Click的問題根據我的經驗，某些域中的安全性非常嚴格，而且沒有多用戶安裝。
如果你走腳本的路線，我會鼓勵PowerShell，它更現代化，並具有更多的靈活性以及更具可讀性。
我提供的最後一個選項，但我認爲直接攻擊你的核心問題。您可以避免使用設置embedding all of the resources directly into the assembly.
您可以創建一個單獨的MSI來安裝該Dll。它已被多個應用程序共享，並且沒有理由不能再有一個只包含該Dll的「共享」設置。然後，您只需在每次更改Dll時部署該安裝（並進行主要升級）。問題在於它必須位於相同的位置，並且所有設置必須使用相同的組件GUID以確保共享的工作正確，並且我不清楚InstallShield LE是否公開這些GUID。避免這種情況的方法是爲Dll創建一個合併模塊，並將其包含在所有設置中，包括僅安裝Dll的設置。
如果它們是由Windows Installer安裝程序安裝的，則以非Windows Inmstaller方式更新Dll是一個壞主意。 Windows知道安裝的版本是什麼以及它們來自哪個MSI以及版本。如果磁盤上的版本與安裝的版本不同，則可能會觸發修復，以請求原始MSI。升級和補丁也會要求原始的MSI文件。如果版本3.0實際上位於磁盤上，但原始MSI安裝了3.2，則傳入的修補程序或升級無法知道文件是否需要在磁盤上進行更新，而無需先進行修復。