在Windows平台上創建一個新的業務線應用程序從來就不是什麼難題。但是，和以前那樣，對於某類確定的問題只有一個明確的解決方案——這樣的日子已經一去不復返了。在過去的二十年裡，面對大多數問題，我們都有更好的選擇。比如，Visual Basic的快速交付或MFC原生的性能和功能。還有WinForms的速度以及WPF的外觀。當WinForms時代結束的時候，我們將Silverlight作為第二選擇。雖然和WPF相比，它沒那麼強大，但它更容易部署。
而如今，我們雖然有了比以往更大的選擇空間，但是可選擇的方案卻差強人意。比如，雖然WinRT提供了三種開發模型，但沒有一個是適合業務應用程序的。與此同時，WPF加入了Silverlight的陣營，而等待WinForms的只有滅亡。
是否選擇一款依賴於Windows 8的平台——對於這個問題我不打算在這裡討論，因為最終企業都將會采用Windows 8。我也不打算討論目前WinRT 8所存在的問題，諸如被限制在單一的窗口或沒有設備集成等等。因為在Build 2013大會上，微軟已經宣布了這些問題將在WinRT 8.1中修復。
我要談的問題比前面的簡單很多，而且要更加初級。坦白地說，部署場景與現實脫節了。WinRT明顯存在有人格分裂（Dissociative Identity Disorder），但在這種情況下，微軟的消費者和企業雙方卻處於僵持狀態。消費者一方要求WinRT在Windows商店保持鎖定狀態，這樣在每個軟件銷售之後，他們都可以獲得一定比率的提成，這類似於蘋果和谷歌成功的戰略。而與此同時，微軟的企業一方則背負著WinRT的未來，但他們甚至沒有認識到對方已產生的問題。
用戶們如果想要將WinRT部署在企業中，必須要滿足三個要求。
第一個要求是，所有的機器都要加入某個域。對於大企業來說，這個要求還算合理的，但對很多小公司甚至一些中等規模的企業來說，根本沒有足夠的資源來維持一組Active Directory服務器。大多數企業都不是搞技術的，他們只需要少量自定義應用，而非整個IT基礎設施——而我們總是忘記這一點。
另一個問題是，一些公司雖然部署了Active Directory，但沒有必要讓所有機器都加入Active Directory。導致這類問題的原因有很多種，可能不全是合理的，但是依然需要滿足這些公司的需求。
據說，對於未加入域的計算機將會有一個替代方案。2012年4月，Antoine Leblond曾作出承諾，後續將在博客中發表文章，描述如何通過獲得必要的產品密鑰來做到這一點。但是，迄今為止，這篇文章還未撰寫。
第二個要求是“允許安裝所有受信任的應用”的組策略，這一點對於已加入域的計算機來說十分合理。對於未加入域的計算機，需要用戶手動編輯注冊表，通常我不贊成這種做法。不過，可以通過添加腳本來實現。
第三個，也是最後一個要求，不太受人歡迎：所有機器必須要信任某個證書，而所有的應用程序都需使用該證書簽名。這意味著需要創建一個自簽名的證書，並手動安裝到每一台機器上，或者花費幾百美元從一個可信的證書頒發機構獲取代碼簽名證書。
一旦滿足上述所有要求，用戶就可以學習如何調用PowerShell命令來安裝應用程序，但無法使用ClickOnce安裝。用戶甚至不能雙擊批處理文件安裝，因為PowerShell默認禁止從Windows資源管理器中運行腳本。
Antoine寫道，
對最終用戶而言，沒有標准方式去檢測並獲取這些應用的更新。
在使用了近十年的ClickOnce自動更新之後，我們又回到手動更新工作站的時代。現在，用戶必須再次輸入PowerShell命令。並且與以前不同的是，他們需要在路徑中包含版本號。例如，
add-appxpackage \\fileserver\ContosoApp\v1.1\ExpenseApp.appx
Silverlight實質上是一種廢棄的技術。不像Adobe Flash，目前連Internet Explorer 10都不能完全支持Silverlight。並且，在基於ARM的計算機上，它根本無法運行。
一些現任的和前任的微軟員工爭辯道：Silverlight是“完善的”，它不需要任何改進。我覺得這種說法非常可笑。
雖然Silverlight工具包包含了很多關鍵的用戶控件，但是自2011年12月以來，我沒有看到任何相關的更新，此外，許多控件沒有達到產品發布的要求。 更糟的是，Silverlight中仍然沒有一個能用的單元測試框架。雖然在工具包中有一個預覽版本，但它存在一些設計缺陷，使用它將導致測試花費O(n^2)的時間。我們自己進行實驗後發現，盡管每個單元測試在單獨測試時只需要幾毫秒，但是幾千個一起測試就會導致測試過程長達一個多小時。另外一個急需解決的問題就是修改UI——已經通過的測試還顯示出來那就太占地方了。
雖然我不想這樣說，但是現在來看，WPF的未來似乎比以往任何時候都黯淡。
WPF很慢，真的很慢。這一點在很大程度上可以歸咎於開發人員做的那些不計後果的事情，比如甚至會加載標簽中上千個不可見的屏幕元素。或者給用戶控件添加過多的效果，我曾見過的一個項目，每個文本框包含9個邊框，並且每個邊框都使用自有的漸變畫筆。
雖然這麼說，微軟仍然可以在WPF渲染管線方面做很多調整。但很明顯，應用於WinRT/XAML的內容已經主動地放棄了移植回WPF或Silverlight的選擇。
自2010年4月之後，我就再沒看到WPF工具包發布新版了。起初看起來，微軟只是暫時擱置WPF，好讓新寵Silverlight可以引起一些關注。但是自那以後，WPF Ribbon工具欄、AutoCompleteBox、 Accordion控件以及WPF未來路線圖中所涉及到的內容，再也沒有進行任何完善工作。
Windows RT版應該部署在一類廉價、低功耗、電池容量高、壽命長的設備上，適用於臨時用戶和大規模的部署。雖然現在它們的價格在下降，但也並不便宜。因為WinRT不能運行“真正的.NET”，所以對於那些使用WPF作為業務線應用的公司來說，就不能選擇WinRT了。
微軟喜歡假裝和蘋果一樣，對遠景規劃的重要公告保密。也就是說，他們可以繼續研發WPF大量的增強功能，只是為了確保對用戶來說是個驚喜。但是別忘了，蘋果是一家硬件公司。如果讀者們投資了一個iPod，當硬件損壞時，投資也就到期了。當硬件真的損壞時，大家會很高興看到蘋果公司推出新一代的產品。
但當用戶使用WPF或Silverlight編寫應用程序時，相當於要對需要使用多年的平台進行投資。那種不確定性一點也不會令人興奮，相反，它是非常恐怖的。事實上，每隔幾年我們就不得不經歷一次這種“投資”，結果是這種“投資”變得越來越習以為常。
更糟糕的是，微軟很少承認自己或者其他人正在放棄某種技術。比如，微軟根本沒有發布過有關WinForms的生命周期的公告。當Silverlight團隊解散，並分配到其他項目中時，微軟也沒有發布任何新聞稿件。還有，沒有人注意到LINQ to SQL的類型化數據集的支持已經取消了。直到它成為已擁有自有競爭框架的ADO.NET團隊的一部分時，我們才意識到一直鐘愛的LINQ to SQL已經被遺棄了。
那麼，WPF怎麼辦？目前，對於Windows用戶來說，WPF仍然是最具生命力的業務線平台。憑借與OS的深度集成、少見的Silverlight問題以及支持ClickOnce的自動更新，在真正進行富客戶端開發時，沒有什麼誰是WPF的對手。但同時也存在一個絕好的機會，機不可失，時不再來。因此對於新應用程序的開發來說，很難就這一點做出客觀的評論。
我堅信，安裝在本地的應用程序可以為用戶提供最佳的體驗。盡管Web建設得越來越好，但對於開發人員而言，它仍然存在很多方面的障礙。因為Web浏覽器攔截了鍵盤快捷鍵，所以如使用F1幫助或F5刷新當前所選視圖這種基本功能，在Web中也都不起作用。在更復雜的情況中，比如多窗口的支持，不管是對用戶還是開發人員來說都是一個很糟糕的體驗。又比如打印多頁的報表，這在Visual Basic1中是支持的，除非你真想生成一個PDF，否則不建議你嘗試。
我想說的是，這項技術是穩定的並且是不斷提升的。它可以在所有Windows機器上運行，從低端的上網本、運行Windows XP的古董級PC，到最新的運行著Windows 8.1預覽版的可翻轉式平板電腦。在充分地努力下，開發者甚至可以讓蘋果、谷歌以及黑莓手機訪問你的應用程序。
當微軟在MVC方面做出了很多具體改進的同時，我們仍然可以看到WebForms在不斷地發展。許多MVC的特性可以移植回WebForms 4.5，或者這些特性本來就適用於兩者。並且，在同一個網站中，可以自由的混合使用MVC和WebForms，這樣，開發者可以只選擇其中一種方式，只不過要以漸進的方式進行。
開發者們不能再無視HTML5，因為它變得越來越流行了。對於中等規模的團隊來說，像TypeScript這種技術的出現使得大規模、單頁Web應用已經成為他們的一個不錯的選擇。或著可以將網站分解成一系列更小、功能更加具體的頁面，這樣會比整體應用更容易處理。
網站的交付時間依然是個關鍵，因為交付網站的時間通常是交付相同功能時間的3到4倍。但因為浏覽器之間的兼容性越來越好，所以這種差異正在逐漸地縮小。
因此——雖然我不想這麼說——但是對於那些正准備開發新業務線應用程序的公司來說，我建議他們應該認真考慮放棄原有的想法，並建立一個內部網站取而代之。
本欄目
