據你所知,從共享exe文件運行C#應用程序是否有問題?這是來自客戶的要求其20個客戶端在共享路徑上運行相同的exe文件的請求。
第一次測試沒有顯示問題,但長期不知道。我個人不喜歡這樣,不要認爲這個框架是在開發時考慮到這一點的,但是它們可以在需要時快速升級exe文件。
任何要阻止這一點?從單個共享exe文件運行dotnet應用程序
感謝
Sav的
據你所知,從共享exe文件運行C#應用程序是否有問題?這是來自客戶的要求其20個客戶端在共享路徑上運行相同的exe文件的請求。
第一次測試沒有顯示問題,但長期不知道。我個人不喜歡這樣,不要認爲這個框架是在開發時考慮到這一點的,但是它們可以在需要時快速升級exe文件。
任何要阻止這一點?從單個共享exe文件運行dotnet應用程序
感謝
Sav的
我們目前運行的軟件內部設計。這運行中央SQL數據庫。每臺計算機都安裝有一個批處理程序,該程序通過Windows啓動並從中央服務器下載當前程序文件。 .exe因此運行在個人計算機上,而不是從服務器上運行。至少在我們的案例中,這被發現是最有效的方法。
首先考慮的是部署問題。在.NET 3.5 SP1之前,默認情況下這是不允許的,因爲發貨的安全策略以不太可信的方式處理網絡位置。 .NET 3.5 SP1和更高版本,this is no longer the case。當然,如果您在此之前正在使用框架版本,那麼您可以使用caspol至modify this security policy來允許這樣做。此外,一些更新版本的Windows may have additional security policies outside of .NET可能會阻止從遠程位置執行。
第二個考慮因素是確保應用程序的設計方式能夠了解其環境,而不是假設環境與本地計算機相關(如果預期環境相對於本地計算機)(這可能會影響外部資源的解決方案並且根據情況,可能導致資源爭奪或用戶覆蓋彼此的數據)。
三是可用性。如果託管該可執行文件的服務器變得不可用(意外斷電,崩潰,遇到網絡問題,重命名等),該怎麼辦?這可以接受嗎?可執行文件有多大?如果它很大,可能會增加網絡流量,並且無論如何都會導致可執行文件啓動緩慢,因爲它是通過網絡調用的。
我想對於微不足道的應用來說,這些問題可能是微不足道的。但是,在客戶端計算機上安裝和更新這些應用程序的方式有很多種,例如ClickOnce deployment。
@Saverio - 你的問題不清楚。 「共享exe文件」究竟是什麼意思? –
在任何情況下,exe文件仍然會作爲每個用戶計算機上的進程運行。您可能會遇到併發問題,因爲所有用戶都將共享該exe指向的任何資源。 – ryadavilli