Windows和企業營運系統應用程式：沒有更好的選擇

在Windows平台上建立一個新的企業營運系統應用程式從來就不是什麼難題。但是，和以前那樣，對於某類確定的問題只有一個明確的解決方案——這樣的日子已經一去不複返了。在過去的二十年裡，面對大多數問題，我們都有更好的選擇。比如，Visual Basic的快速交付或MFC原生的效能和功能。還有WinForms的速度以及WPF的外觀。當WinForms時代結束的時候，我們將Silverlight作為第二選擇。雖然和WPF相比，它沒那麼強大，但它更容易部署。

而如今，我們雖然有了比以往更大的選擇空間，但是可選擇的方案卻差強人意。比如，雖然WinRT提供了三種開發模型，但沒有一個是適合商務應用程式的。與此同時，WPF加入了Silverlight的陣營，而等待WinForms的只有滅亡。

WinRT：尚未完成準備

是否選擇一款依賴於Windows 8的平台——對於這個問題我不打算在這裡討論，因為最終企業都將會採用Windows 8。我也不打算討論目前WinRT 8所存在的問題，諸如被限制在單一的視窗或沒有裝置整合等等。因為在Build 2013大會上，微軟已經宣布了這些問題將在WinRT 8.1中修複。

我要談的問題比前面的簡單很多，而且要更加初級。坦白地說，部署情境與現實脫節了。WinRT明顯存在有人格分裂（Dissociative Identity Disorder），但在這種情況下，微軟的消費者和企業雙方卻處於僵持狀態。消費者一方要求WinRT在Windows商店保持鎖定狀態，這樣在每個軟體銷售之後，他們都可以獲得一定比率的提成，這類似於蘋果和Google成功的戰略。而與此同時，微軟的企業一方則背負著WinRT的未來，但他們甚至沒有認識到對方已產生的問題。

WinRT應用在企業中的部署

使用者們如果想要將WinRT部署在企業中，必須要滿足三個要求。

第一個要求是，所有的機器都要加入某個域。對於大企業來說，這個要求還算合理的，但對很多小公司甚至一些中等規模的企業來說，根本沒有足夠的資源來維持一組Active Directory伺服器。大多數企業都不是搞技術的，他們只需要少量自訂應用，而非整個IT基礎設施——而我們總是忘記這一點。

另一個問題是，一些公司雖然部署了Active Directory，但沒有必要讓所有機器都加入Active Directory。導致這類問題的原因有很多種，可能不全是合理的，但是依然需要滿足這些公司的需求。

據說，對於未加入域的電腦將會有一個替代方案。2012年4月，Antoine Leblond曾作出承諾，後續將在部落格中發表文章，描述如何通過獲得必要的產品金鑰來做到這一點。但是，迄今為止，這篇文章還未撰寫。

第二個要求是“允許安裝所有受信任的應用”的組策略，這一點對於已加入域的電腦來說十分合理。對於未加入域的電腦，需要使用者手動編輯註冊表，通常我不贊成這種做法。不過，可以通過添加指令碼來實現。

第三個，也是最後一個要求，不太受人歡迎：所有機器必須要信任某個認證，而所有的應用程式都需使用該認證簽名。這意味著需要建立一個自簽名的認證，並手動安裝到每一台機器上，或者花費幾百美元從一個可信的憑證授權單位擷取程式碼簽署認證。

一旦滿足上述所有要求，使用者就可以學習如何調用PowerShell命令來安裝應用程式，但無法使用ClickOnce安裝。使用者甚至不能雙擊批次檔安裝，因為PowerShell預設禁止從Windows資源管理員中運行指令碼。

WinRT應用的更新

Antoine寫道，

對終端使用者而言，沒有標準方式去檢測並擷取這些應用的更新。

在使用了近十年的ClickOnce自動更新之後，我們又回到手動更新工作站的時代。現在，使用者必須再次輸入PowerShell命令。並且與以前不同的是，他們需要在路徑中包含版本號碼。例如，

add-appxpackage \\fileserver\ContosoApp\v1.1\ExpenseApp.appx

Silverlight：廢棄的技術

Silverlight實質上是一種廢棄的技術。不像Adobe Flash，目前連Internet Explorer 10都不能完全支援Silverlight。並且，在基於ARM的電腦上，它根本無法運行。

Silverlight完善嗎？不。

一些現任的和前任的微軟員工爭辯道：Silverlight是“完善的”，它不需要任何改進。我覺得這種說法非常可笑。

雖然Silverlight工具包包含了很多關鍵的使用者控制項，但是自2011年12月以來，我沒有看到任何相關的更新，此外，許多控制項沒有達到產品發布的要求。 更糟的是，Silverlight中仍然沒有一個能用的單元測試架構。雖然在工具包中有一個預覽版本，但它存在一些設計缺陷，使用它將導致測試花費O(n^2)的時間。我們自己進行實驗後發現，儘管每個單元測試在單獨測試時只需要幾毫秒，但是幾千個一起測試就會導致測試過程長達一個多小時。另外一個急需解決的問題就是修改UI——已經通過的測試還顯示出來那就太佔地方了。