作者｜何愷鐸
編輯｜尾尾
曾經被業界取笑「閉關鎖國」的微軟如今也走向了「改革開放」的道路，Visual Studio 2017的發布，不僅是VS二十周年的大事件，更是微軟技術生態煥然一新的直觀體驗。以前只支持Windows及自家產品的微軟，現在iOS、Android、Mac都支持了。
寫在前面
北京時間2017年3月8日凌晨，Visual Studio 2017如期發布。今年恰逢Visual Studio二十周年，Visual Studio團隊可謂誠意滿滿、不負眾望——VS2017不僅擁有全新的模塊化設計和更強的性能，功能上也是具有頗多看點和干貨，絕非不痛不癢的“年貨式”更新。更重要的意義在于，它折射出了微軟對于業界技術趨勢的最新思考，也展現出了微軟擁抱開發者社區的全新姿態。
大家可能還記得鮑爾默在眾人前高喊"Developers, developers, developers!"的場景，這說明微軟本有著非常重視開發者社區和開發者體驗的傳統。然而前些年，也許是失之于封閉和捆綁，微軟在開發者群體中的影響力走勢低迷。將各技術產品線進行排他性整合的思維最終被證明是不受歡迎的——在這個崇尚開源的互聯網時代，它反而削弱了微軟各大技術平臺的競爭力。
好在新任CEO納德拉執掌公司以來，給微軟帶來了巨大的思維方式的轉變，開放與協作迅速成為了主旋律。 嶄新的公司文化幫助微軟的技術生態跳出了過去的窠臼和局限，并逐漸進入了一種生機盎然的絕佳狀態。本文試圖通過梳理 VS 2017 的諸多特性，從編程語言及其工具體系、移動和云、容器化和DevOps等不同視角來探討Visual Studio乃至整個微軟技術堆疊的基因變化，決議其進化之道。
編程語言及其工具體系
Visual Studio 2017一如既往地為多種編程語言提供了原生支持，如C#、Type/Java、C++、F#、Visual Basic等，也集成了這些語言的最新版本。
C#語言穩步發展，開始支持模式匹配
眾所周知，VS的當家語言是C#。C#現已是一門多范式的主流編程語言，歷久彌新，LINQ、dynamic、async/await等標志性特性使其在世界范圍內擁有眾多擁堆疊。新版Visual Studio按照慣例帶來了全新的C#語言版本C#7，新增了Out變數（Out variables）、元組值型別(Tuples)、參考回傳(Ref locals and returns)、本地函式(local functions)等特性。C#7的演化思路很清晰，是在C#6的基礎上帶來穩健的增量更新，使代碼更為簡練，可讀性和可維護性更強，進一步鞏固C#主流編程語言的地位。
最值得一提的新特性，恐怕要數模式匹配（pattern matching）了。這一標志性的函式式編程范式引入C#后，巧妙地融入了原有的is關鍵詞和switch陳述句，可在諸多場合大幅簡化繁瑣的變數宣告、if陳述句和型別轉換，凸顯業務邏輯本身。
與此同時，我們還能夠看到C#語言團隊的謹慎和克制——因為模式匹配原本計劃做得更加深入，如加入match關鍵詞和型別分解（destructuring）等高級特性，但C#團隊最終選擇了暫時避免激進變化，采用了更溫和更穩健的策略。這樣的一種克制，對于C#這樣具有較重歷史負擔和大量遺留代碼的語言來說，是一種對龐大的用戶群體負責任的態度，也降低了眾多C#開發者學習和升級的門檻。
Roslyn編譯器為C#發展推波助瀾
C#眾多新特性的背后，離不開Roslyn編譯平臺的堅定支撐。歷經數年范訓的Roslyn使用C#實作了一個現代的C#編譯器，現已能完全替代原有的C++實作，真正走向了成熟。任何語言的生命力源于一個開放的、架構良好的、可維護的編譯器code base，開源的Roslyn做到了這一點。像前面提到的模式匹配的型別分解，其實在Roslyn平臺上實作并不困難，甚至已經有了初步的代碼實作。因此，全新出發的Roslyn平臺，是C#后續良好快速發展的保證，我們對C#的未來應當充滿信心。
Roslyn帶來的另一個好處是強大的編譯器API和元資料暴露能力，也在VS2017中得以體現，提高了生產效率。在使用VS2017時不難發現，最常用的查找所有參考（“Find All References”）的結果得到了良好的格式化和語法高亮，還支持更多的展現選項；“Ctrl + .” 的智能提示組合鍵也變得更加強大，覆寫了更多場景，還能幫助開發者遷移代碼到C#7——這些都離不開Roslyn的加持。之前類似的功能可能需要通過第三方商業擴展（如JetBrains的Resharper）才能擁有，而現在相當部分已經在Visual Studio中直接內置了。
頗受好評的Type持續快速迭代，同時支撐了新版Visual Studio中的Java工具體系
Type是微軟近年來的另一個重大投入，由C#之父 Anders Hejlsberg親自掌舵，可以理解為Java語言的一個超集。Type設計和發展的思路緊緊圍繞兩點：一是引入可選的強型別機制，以提供強大的編譯期檢查和智能提示；二是全面擁抱乃至提前實作ECMA標準，使得眾多開發者可以第一時間嘗鮮，不必等待瀏覽器的內置支持，而對標準的遵循也使得開發者的學習成本得以攤薄。
這兩個正確的設計決定讓Type具備了鮮明的強型別生產力特征，同時又能與Java和Node.js的已有社區成果深度兼容。因此，Type一經推出就廣受歡迎，在近年不斷獲得關注和采用。如Angular框架團隊于2015年宣布Angular2放棄自有的At轉而使用Type，堪稱微軟與谷歌開源技術合作的破冰之舉。
毫無疑問，VS2017自然內置了最新的Type 2.2版本。除去在Visual Studio中開發和編輯Type代碼的豐富體驗外，基于Type的核心能力和強型別生態，Visual Studio 2017還全新打造了Java Language Service（原開發代號"Salsa"）來支撐在新版VS中的Java tooling體系。
換句話說，微軟基于Type的能力打造了為Java開發服務的語言基礎設施，類似Roslyn對于C#的基石作用，使得VS中Java相關的智能提示、代碼導航、代碼重構等體驗取得了大幅改進。之所以相關能力可以躍升，基于Type的靜態代碼分析引擎功不可沒，它替換了老舊的主要依賴動態執行獲取資訊的Intellisense引擎 。另外，Java編輯時背景關系中的靜態型別資訊既可以來自Type生態的大量強型別定義（主要由DefinitelyTyped 專案提供），也支持決議社區常見的JSDoc，這是又一個亮點。
Type近期版本還不斷地加強了對JSX語法的原生語言級別支持（JSX自Type 1.6版本開始引入）。從面向React.js進行JSX特性的設計，一直到最近為React Native進行適配和優化——傾聽社區聲音的Type非常接地氣 ，體現了對流行框架的支持和融合。
微軟技術堆疊中的其他語言，也在Visual Studio 2017中得到了更新，如C++、F#和Visual Basic。其中，C++進一步實作了C++14和C++17標準中的特性，并開始支持跨平臺開發；F#發布4.1版本，提出要成為具備最佳效率工具支持的現代函式式編程語言；而Visual Basic則將一定程度停止對C#的簡單克隆，著重發展自己的特色。因篇幅所限，此處就不再展開。
以Visual Studio 2017領軍的VS家族已經完成布局，形成了一個開發生態的矩陣
伴隨著新生的Visual Studio 2017一起陸續走到前臺的同門兄弟，還包括開源、跨平臺、多語言支持的輕量級開發環境Visual Studio Code以及由Xamarin Studio發展而來的Visual Studio for Mac（仍處Preview狀態），它們都已是Visual Studio大家庭里的重要成員。
前面文中提到的C#、Type等語言的新版本和新特性，得益于相應語言基礎設施的開放性和模塊化，也都可以在VSCode和VS for Mac中找到并使用。例如Visual Studio Code中完善的C#支持，是通過一個巧妙的被稱為Omnisharp Server的后臺Http服務行程實作了對代碼結構的實時決議和智能提示，而在Omnisharp背后進行支撐的正是Roslyn。
移動和云
“移動為先，云為先”是微軟的全新戰略，因此Visual Studio 2017對這兩方向的開發支持都進行了巨大的投入，達到了新的高度。
移動開發方面微軟采用了迂回策略，通過C#/Xamarin和Java/Cordova吸引兩大陣營開發者，進軍Android/iOS應用開發
移動方面，去年微軟成功地完成了對Xamarin的收購，終于將Xamarin賴以成名的利用C#撰寫Android、iOS、Mac等平臺原生應用的能力收入囊中，并與微軟產品線進行整合——此舉受到了.Net社區的廣泛歡迎。今天我們看到的Visual Studio 2017已經體現了整合的成果：用戶們不必再額外付費購買昂貴的Xamarin商業套件，新版Visual Studio中已經直接納入了使用C#語言和類別庫生態撰寫Android/iOS應用的能力，大幅降低了使用Xamarin技術的門檻。
并入微軟官方體系之后，Xamarin的生態也許將逐漸迎來真正意義上的繁榮時期。不過對于中國的廣大開發者來說，國內目前Xamarin的聲量還比較小，對國內移動互聯網生態（如認證、分享、支付等）尚無太多的官方支持和兼容考慮，這可能會成為國內公司使用Xamarin進行移動開發的主要障礙。如果微軟和社區在這方面進行積極的合作和推動，解決這樣的“水土不服”問題，相信國內的Xamarin成功案例也將開始涌現。
除Xamarin外，微軟在移動開發還有另一套基于Apache Cordova的解決方案，以吸引Java和Web技術背景的移動開發者。Visual Studio團隊其實多年前就開始構建Visual Studio Tools for Apache Cordova（簡稱TACO），試圖為開發者提供一站式的Cordova開發體驗，幫助解決繁雜的安裝、依賴梳理、環境配置、除錯支持等工具鏈問題——這正是Visual Studio所擅長的。Visual Studio 2017帶來了新版的TACO，在相關體驗上再次上了一個新的臺階，還支持最新版本的Ionic2框架，有興趣的朋友不妨一試。
跨平臺.Net Core走向成熟，成為適合云端的應用構建選擇
云計算方面，日前微軟Azure在公有云領域穩居世界第二，且勢頭不斷攀升，已是微軟整體業績的重要增長引擎。毫無疑問，Visual Studio 2017不遺余力地為開發云端應用程式準備了最新最強的支持。
為云助力的第一要務，是幫助開發者構建適應在云端環境運行的應用程式。.Net Core和Asp.Net Core在此處扮演了重要角色，因為它們具有良好的跨平臺支持，并且能夠比較輕量地連同整個runtime一起打包進行自包含部署（Self-Contained Deployment）。之前.Net Core/Asp.Net Core曾在Visual Studio 2015中試水，并隨著技術思路的調整在VS2015的多次更新中不斷變化。終于，Visual Studio 2017正式將蛻變完全的.Net Core和Asp.Net Core專案作為一等公民。之前因為.Net Core生態處于預覽狀態而擔心穩定性和breaking change的朋友們，現在則可以放心大膽地使用了。
.Net Core和Asp.Net Core的歷史和關系說起來頗為有趣：多年前Asp.Net團隊在微軟內部就以開放和進取著稱，他們在設計下一代的時稱Asp.Net 5的框架時（早期代號為Project K ），雄心勃勃地希望加入自包含部署、即時編譯、跨平臺運行等特性，并在當時.Net的工具鏈和運行時尚不能支持相關需求的情況下，竟自底向上地開發出了一套相對獨立的生態和工具鏈（DNX），事實上領先于.Net Core的范訓。Asp.Net 5的預覽版發布后，在設計和性能上都取得了相當好的反響，聲勢上反倒蓋過了標準.Net Core Tooling，一度造成了略顯尷尬、令人費解的局面。
令人高興的是，經過了一段相當長的過渡時期后，兩個團隊逐漸走向了協調和融合，期間Asp.Net 5重命名為了Asp.Net Core，并最終完全基于.Net Core的CLI進行管理和運行。直到最近Visual Studio 2017發布時，DNX工具鏈的最后標志project.json描述檔案也隨著.Net Core Tools 1.0的正式交付而退出歷史舞臺，進化后的csproj/msbuild體系則再次統一專案模型。這一段軼事其實也折射出了微軟自我革新的歷程，可謂好事多磨，終成善果。
Azure上的PaaS能力不斷推陳出新，Visual Studio幫助大幅降低使用門檻
為云助力的另一角度，是需要為Azure上琳瑯滿目的PaaS特性提供支持和無縫集成，這部分一直由Azure SDK進行支撐。在Visual Studio 2017的Azure套件中，自然包含各種基于PaaS的云端專案模板，為用戶采用Azure的特性提供了一站式解決方案，典型的如WebJob和Service Fabric。而對于需要消費PaaS和各種標準API的應用程式，Visual Studio的Connected Service也能夠幫助開發者迅速地連接和配置這些平臺或服務。此外，Azure SDK所包含的Azure模擬器可以幫助開發者在本機虛擬云端環境，極大地方便了云端應用程式在本地的開發和除錯。
針對大資料處理和計算的PaaS能力是當前公有云廠商爭奪的重點。Azure近來在此領域內動作頻頻，一方面不斷深化與HortonWorks的合作，高頻率地強化和更新HDInsight（基于HDP）；另一方面PaaS化程度更高的Azure Data Lake也已結束了預覽進入GA狀態。Azure Data Lake上的資料分析頗具特色，可使用微軟自研的U-SQL語言結合SQL和C#的特點進行混合編程，給大規模資料處理和查詢帶來了讓人耳目一新的方式，受到.Net生態開發者的歡迎。在Visual Studio 2017中，開發者可以很方便地連接和管理云端的大資料資產，并創建相應生態的應用程式，如U-SQL、Storm、Hive、Pig等。
總結移動和云方面，微軟可謂兼收并蓄，與時俱進。同時，通過充分利用Visual Studio這樣的生產力工具，微軟成功地對各種平臺和不同層面運行環境下的開發單元進行了良好的抽象，給予了開發者多樣化的選擇。
容器化和DevOps
微軟同Docker進行深度合作，融入容器生態圈
容器化和DevOps已成行業熱詞，微軟自然不會錯過相關生態的布局，之前就成功而及時地與Docker達成了深度合作。在這個領域，微軟做了三件看起來非常具有前瞻性的事情，一是與Docker合作催生Windows容器，包括Windows Server Core和Windows Nano Server兩種形式，以方便傳統Windows應用程式向Docker容器遷移；二是著力優化Windows作為Docker宿主的能力和體驗，使得Linux容器能夠通過Docker for Windows穩定輕快地運行于開發人員Windows上，Docker的原生支持也添加進了Windows Server 2016中；三是不失時機地推出了Azure容器服務（Azure Container Service），使得基于容器的大規模應用程式能夠順利地在微軟云中部署生根。
受益于上述策略的不斷落地，在Visual Studio 2017中進行流暢的容器化應用開發可謂水到渠成。我們可以輕松地為相關Project添加Dockerfile打包應用進容器，并在Solution層面使用Docker Compose進行容器編排。筆者曾嘗試在較短時間內建立起若干簡單的Asp.Net Core微服務，并互相組合形成了基于微服務架構的應用程式，然后通過Visual Studio在本機的多個Linux容器上一鍵部署運行。更方便的是，Visual Studio 2017還幫助生成了.Net Core除錯相關的Docker配置，使得除錯模式下運行在Linux容器內的代碼輕松地命中了VS內的預設斷點！這樣的單機多容器“遠程”除錯確乎是一種奇妙的體驗。
Azure容器服務是微軟云的容器解決方案，支持多種編排引擎
前面提到的Azure容器服務，值得再略著一些筆墨。有不少人認為，容器生態的不斷發展對于傳統PaaS形成了強而有力的挑戰，因為細粒度的容器一定程度上可以替代PaaS，同時提供更大的靈活度以及可移植性——很多情況下的確如此。在這一問題上，Azure選擇了兩邊下注，在繼續不斷發展PaaS的同時（比如積極投入Azure Functions這樣的Serverless計算框架），也擁抱容器生態，推出并不斷改進Azure Container Service 。保留不同粒度的抽象，把選擇權留給客戶，的確是最佳方案。目前Azure容器服務已支持Docker Swarm、Mesosphere DC/OS和Kubernetes三大編排引擎，同時底層利用Azure VM Scale Set特性優美地實作了彈性擴容。
VSTS/TFS提供了現代的持續集成能力
真正的DevOps離不開持續集成pipeline的搭建和管理。在大家的印象中，Visual Studio一直有比較好的手動發布支持，可以方便地一鍵部署應用程式至本地或云端。Visual Studio 2017已更進一步，通過與云端Visual Studio Team Service(VSTS)或本地Team Foundation Server(TFS)的深度配合，可徹底將CI/CD的流程串聯并打通，實作自動編譯、測驗、發布和部署。
最新版本的VSTS/TFS不但讓完整的DevOps流程開箱即用，并且從設計理念上充分考慮了開放性，可以在CI/CD pipeline的不同環節使用不同的技術：如使用GitHub的倉庫進行源代碼獲取和編譯觸發，又如支持以Docker為構建和發布的基本單位，再如使用Octopus Deploy進行部署等。此間，Azure也扮演重要角色，既可以提供動態伸縮的Build Agent，又能夠作為應用最終部署的目的地。
DevOps流程中容易忽視的一個痛點在于關系型資料庫schema的版本控制和升級，實踐中往往需要依賴手動撰寫的遷移腳本進行人工操作——這與DevOps的精神是相違背的。為了嘗試解決這一問題，微軟與第三方工具提供商Redgate進行了合作，首次將價值不菲的Redgate Data Tools內置于Visual Studio 2017企業版中。Redgate相關工具的妙處在于，不僅能夠將資料庫schema進行完善的源代碼管理和編譯檢查，更能記錄不同版本的演化細節，并在VSTS的配合下自動地增量更新到CI pipeline的各個資料庫中，包括在審批后到達最終的生產環境。
展望與期待
不知不覺，Visual Studio已經走過20個年頭。 Visual Studio 2017是一個重要的里程碑，同時也是一個新的開始。我們有理由相信VS2017還將不斷升級，把握新的機遇。事實上，微軟已經開始為VS2017準備后續的更新，并緊鑼密鼓地發布了Visual Studio Preview，使得開發者們能夠在正式的Update發布之前就可以率先嘗試即將到來的新特性。
通過Visual Studio Preview我們可以知道，在未來的VS2017 Update1中，全新的Python開發環境將粉墨登場，還會帶來支撐Windows 10 Creator Update新特性的UWP套件更新。之后，還會有針對資料科學和分析類應用程式（Data science and analytical applications）開發的專屬支持。相信這些將來的更新都會廣受歡迎。
針對中國的開發者群體和市場環境，Visual Studio團隊想必也會越來越重視。近期微軟與華為的合作就是一個很棒的成功案例：華為通過使用VS2017進行面向Linux的C++開發，大幅提升了生產效率。 在此，我們也期待Visual Studio未來能夠做得更多更好。其實除了解區域分組件水土不服的問題外，Visual Studio還大可以嘗試與國內的公司、平臺和生態進行更深入的合作。讓我們大膽試想，如果VS能夠支持微信小程式的開發，或是在VS中能夠方便地對接使用阿里云的基礎設施，是不是聽上去就更有傭訓力了呢？
寫在最后
"Any Developer, Any App, Any Platform"，Visual Studio 2017在這樣的新口號下醞釀和誕生。開放而非封閉，合作而非拒絕，兼容而非分裂，這是屬于微軟的改變，這是屬于微軟的進化之道。眾多微軟技術生態愛好者們期待已久的春天，似乎真的要到來了。也許有一天，我們不再需要強調“微軟技術堆疊”，因為它本就是開放技術世界的組成部分，互相融合，難分彼此。
注：本文僅代表作者個人觀點。作者個人與文中所提及商業公司均無利益關系。
作者介紹
何愷鐸，供職于國雙科技(Nasdaq:GSUM)，現任高級技術總監，負責網站與流量分析產品線。曾參與架構和設計了國雙多個面向數字營銷和社交聆聽的大資料解決方案。個人關注的技術領域包括.Net生態系統、云計算、大資料技術堆疊等。
uj5u.com熱心網友回復：
Visual Studio 2017好像是自代Xamarin去年在Visual Studio 2016上安裝Xamarin打算用C#開發安卓的程式，作業忙放下了。過一段打算換VS2017試試
uj5u.com熱心網友回復：
遲到了三個月的頂uj5u.com熱心網友回復：
專家
uj5u.com熱心網友回復：
Xamarin太冷了，連資料都少的可憐，估計遇到問題只能自己解決，或者看英文檔案uj5u.com熱心網友回復：
作為一個作業系統起家的公司，在人手一部智能手機的時代，居然移動作業系統份額0.1%都不到，微軟是該反思了，不過在大局已定之后才搞開源和跨平臺，是不是晚了一點？移動互聯網時代，大部分程式員不可能不開發移動應用，一直跟著微軟跑的程式員因為移動開發不得不轉移到java，一旦轉移成功，微軟被拋棄只是遲早的事情，微軟搞跨平臺，主要目的可能就是為了挽留這些程式員。諾基亞丟掉了智能手機，微軟丟掉了移動作業系統，這兩家犯了重大戰略錯誤的公司最后還想抱團，沒用的。uj5u.com熱心網友回復：
微軟對 Xamarin 的改造堪數“垃圾、失敗”的一個例子。微軟的開發平臺的過去的優勢在于所見即所得，也得益于跨平臺統一的開發體驗，而 Xamarin 中最主要地當然是在安卓和蘋果手機上在開發界面應用時有著至少100個流行的現成的標準還控制元件，同時對于作業系統虛擬層進行監聽和注入操作的能力，可以說 Xamarin 都令人大失所望。轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/30062.html
標籤：Xamarin技術
上一篇：EDI電子資料交換