Xamarin+.NET Standard之同時存在的HttpClient衝突小筆記
團隊試著使用「Xamarin + .NET Standard」的組合來試著開發跨平台應用程試,因為 .NET Standard 是比較新的 PCL(可攜式類別庫),碰到問題解決時,G大和S大能提供的解決方法也比較少,例如,如上圖,在 .NET Standard 裡呼叫 HttpClient 連編譯都有問題,這可不好玩…
團隊試著使用「Xamarin + .NET Standard」的組合來試著開發跨平台應用程試,因為 .NET Standard 是比較新的 PCL(可攜式類別庫),碰到問題解決時,G大和S大能提供的解決方法也比較少,例如,如上圖,在 .NET Standard 裡呼叫 HttpClient 連編譯都有問題,這可不好玩…
使用Visual Studio的人一定使用過新增專案,在新增專案的過程有個步驟一定省略不了,那就是選擇你所需的專案範本,Visual Studio本身準備了非常非常豐富的專案範本,但就是有不夠用的時候,這時有二種處理方式,除了Visual Studio裡已安裝(Installed)範本外,還可以搜尋線上(Online)範本,Installed 範本大約能解決 90% 的開發需求,Online 範本能在提供 5% ~ 8% 特別需求的解決方案(但也是比較通用或一般性),另外的 2% ~ 5% 就是今天想討論的主題,客製化自己或團隊的專案範本。
前一篇 將Xamarin的PCL專案升級轉換為.NET Standard Library 我們將 Xamarin 跨平台裡的 PCL 專案轉換為使用 .NET Standard Library,但這只完成整個 Xamarin 專案的其中一個專案,其實並未算是把整個 Xamarin 專案完全使用 .NET Standard Library 目標,目前這個當下(或許 Visual Studio 2017 會改善),還有許多工作需要人工作業,讓我們一步步來將整個專案完成轉換。
.NET Standard 是微軟在解決 .NET 跨平台時基礎程式庫不一致的問題。而最近剛好在學習 Xamarin 的跨平台開發,就研究了一下如何使用 .NET Standard,結果發現,目前 Visual Studio 2015 還不能直接開 .NET Standard 的專案,需要一些步驟才能使用,這篇讓我們快速瞭解一下 .NET Standard 2.0 還有如何在 Xamarin 專案使用它 。
現在 SSD 價格、容量、速度都已經到了非常親民的程度。而現任 Lenovo 筆電與 SSD 是三年前過時產品,你要知道,SSD 是求速不求命,也就是掛了不只什麼都沒有(一定要備份),過保那麼就直接換一顆吧!
好啦,以上純無聊亂說話,其實是我的空間快用完了,然後又看到 PChome 在特價,手不小心滑了一下,就來趟 SSD to SSD 的升級之旅吧。
近期不知道有何原因,公司與家中筆電都會不時出現風扇提高轉速的聲音,本來不太在意,但高轉速有時持續一整天,而且電腦明顯變慢,開啟[工作管理員]查看,非常明顯,有個 .NET Runtime Optimization Service(mscorsvw.exe) 長時間在使用 CPU。
使用者回報一個剛上內部測試區的網站嚴重破版,但「在開發者電腦正常,在使用者電腦不正常」,唯一差異,開發者是在本機測試,使用者是連上測試區的 IIS 測試。同事快速從 F12 開發者工具發現關鍵字,借此又多瞭解一個 Microsoft Edge / Internet Explorer 預設值與差異。
.NET 開發人員多多少少有機會使用到 SQL Server Management Studio (SSMS),SSMS 預設情況下會保留已連線過的伺服器名稱,在 SQL Server 2012 之前的 SSMS 一直有個毛病,那就是這個【伺服器名稱】不易刪除。這個問題在 SQL Server 2012 之後被修改,只需要你在【伺服器名稱】下拉選單將滑鼠移動過去要刪除的連線資訊,然後接下【Del】即可。
不過現在我碰到的相反需求,當【伺服器名稱】下拉選單越來越長時,有時要找到連線資訊都需要看一會兒,如果連線資訊又很相似時,那現真的考驗眼力與腦力,這對老人家真是不好。找了一下,原來 SSMS 還有本身就有個管理伺服器名稱好物。
最近被通知有個已經忘記的網域將要過期。之前一直想把 kkbruce.tw 轉換至 Azure DNS 上,沒做原因之一是之前 Preview 的 Azure DNS 只能透過 PowerShell 去設定與管理,比用 Vim 去改 Bind 的設定檔還麻煩。剛好利用過期前的網域來玩一下 Azure DNS,不玩還好,走過之後,架設、設定、轉移簡單到極點,對於一個之前管理 DNS 超過十年的人來說,只給 87 分,不能再高了。
以下是實際 kkbruce.tw 轉移 Azure DNS 的案例。
因為不知名原因,電腦 Windows 10 所有原生 App 全部無法使用(如上圖),網路上有放著放著就會自己好的說法,我放了二週,重開了 N 次,還是一樣,只好選擇進行 Re-Install OS。現在重灌 Windows 10 + 安裝 Driver (少數) + Windows 10 App 還原,整體時間和以前相比,時間成本真的是大大減少許多,而且已經還原 5 成以上作業的能力了。現在反而是非 Windows App 的軟體,下載、安裝與設定花的時間多很多。很久以前從 Scott Hanselman 的 Blog 學習到整理軟體清單(我2011年整理)這件事,當時從 Scott Hanselman 的清單挖到不少寶,有些現在還使用。時過境遷,在下載(找)軟體時,突然回想起軟體清單這件事,就順手把目前有在使用的軟體重新整理一下,就當成2016年版軟體(開發)工具清單。
以下同時出現 free, pay 代表有測試版(或免費版)可下載使用,通常是功能限制。沒註明的通常是免費的。
身為一位軟體開發人員,我一直推廣:在個人付擔的起的情況下,不要當一位只願意自己喝星巴克而不願意買軟體的人。絕大部份的軟體都不貴,如果真的對你有幫助,你需要天天喝咖啡,就不能請一下這位寫出好用軟體的人(或公司)嗎?當然,那種數百美金以上的事,就看你怎麼找到痛點來介紹與推廣給公司,絕不是(抱怨)不可能,只是那痛點是否被你找到。
公司有個特別的 D 系統,我們需要透過 ASP.NET Web API 去存取它的 XML Web Service 來提供資源。這個 D 系統本身有個特別的限制,就是存取之前使用者需要先進行頁面 Login,然後才能存取 XML Web Service。Login 頁面很單純,就是一個帳號與密碼的組合,沒有其他特別驗證碼等保護。也就是使用者使用者輸入帳號密碼,而 ASP.NET Web API 透過使用者提供的帳號密碼透過程式方式進行登入,我們開發的 ASP.NET Web API 服務從一開始的 Beta 至 RC,這部分的程式碼都沒什麼問題,直到那令人鬼打牆的關鍵人物(暫稱他苦命的呆伯特好了)出現。
簡單說明一下,此 ASP.NET Web API 服務主要使用者在美國,美國下班台灣上班的黃金交接點,我們私下請呆伯特(美國)幫忙測試此 ASP.NET Web API 服務的同事,但幾星期以來僅呆伯特都一直反應無法 Login 服務,由日誌看出來,他確實是登入失敗。但所有幫忙測試的人員只有呆伯特會出現此狀況。D 系統我們無任何權限,我們能做的也只是不斷調整 ASP.NET Web API 程式並不斷請呆伯特幫忙 Login 與測試。但每每得到"不行"時,心情都低落到不行(測到呆伯特都生氣了),不過最後得到一條重要資訊,呆伯特的密碼含有數個的特殊符號。
我們為加解密演算法補上特殊符號的測試程式碼,先確保特殊符號在加密與解密過程正常。其中小心\與"這兩個符號,在C#的字串中,需要使用\\與\"進行轉義。
以這條線索測試到最後終於有了曙光。
前篇提到SSMS 2016中文版的更新錯誤的問題,今天談另一個相關的 Microsoft SQL Server Data Tools(SSDT) 中文版更新錯誤的問題。
前篇學習到如何透過修改.csproj專案檔,讓我們在建置(Build)時就能使用 XML-Document-Transform (XML文件轉換)功能,但有個缺點,那就是必須每一個專案都必須手動一一設定.csproj專案檔。
地表除了最強開發工具 Visual Studio 之外,別忘了,還有它的兄弟Visual Studio Gallery,以下介紹我覺的好用又免費又佛心的兩套擴充套件:Fast Koala - [Web/App].config XML transforms 與 ConfigTransformation。
網站開發到一定規模,你一定有經驗,開始在 Web.config 裡去註解A執行B設定,或註解C執行D設定,最常碰到的需求有:測試區與正式區的 appSettings
設定,測試區與正式區的 connectionStrings
設定等。當專案離開本機開始發行至測試區或正式區時,千萬不要還在用切換註解的方式,應該參考 Kevin:「發佈網站時依據組態設定的不同而轉換 Web.Config」的模式去進行發行時 *.config 的切換。這種動作的名稱「XML-Document-Transform」(XML文件轉換),簡單說,就是利用 Locator
找出要修改位置,再利用 Transform
屬性指定進行的動作。
發行可以利用「XML-Document-Transform」來解決不同區域不同配置的問題。但開發人員最常碰到卻是開發當下!開發除錯當下,你無法去只是簡單切換 Debug | Release 來達到或啟用XML文件轉換的功能,假設,你想將原本 SqlLocalDb 的連線字串切換至 SQL Server Express 連線字串進行測試時,好像只有註解、移除註解這條路。 :-(
這樣的路,其實走了好久好久,我累了,我想,是應該跟它分手了。(超假文青 XD)
這裡會利用如何:擴充 Visual Studio 建置處理序裡的技巧。以下技巧通用於 ASP.NET WebForms 與 ASP.NET MVC 與 ASP.NET Web API 專案。(照理說是只要是 XML 的 .config 都通用,但我沒一一嘗試就是了)
安裝SQL Server Management Studio(SSMS) 2016之後一直有個問題困擾我,現在 SSMS 2016 更新頻率算高(幾乎一個月一次),如果你乖乖按照SSMS 2016去進行更新,嗯…沒有一次會成功 >_<,有幾次還為了找到正確的下載點,還要額外花時間才找到,哥可是一分鐘幾十萬上下的人 :P,怎麼能這樣浪費時間!
我沒裝過其他語系版本,其他語系有沒有碰到一樣的問題,我不知道,以下只是簡單筆記SSMS 2016中文版更新步驟。
如果,你正要開發一個 Web API 來自用?
如果,你需要提供 Web API 讓第三方(例如,手機App)呼叫?
如果,你需要串接其他第三方 Web API 來使用?
隨著 client 越來越多樣化,Web API 的重要性不言而喻,還沒趕上或是充滿迷惘?
2016年重磅規劃的課程,業界實戰的內容,走過路過,真的不要錯過!
Windows 10周年更新(版本1607),如未自動下載又想快點更新的人(例如,我),可以到這裡下載Windows 10升級小幫手來進行升級。此次更新除了Microsoft Edge有大進步外,最大特色就是內含 Linux 子系統(Ubuntu bash)。在更新完 Windows 10 - 1607版之後,需要經過一點點設定才能啟用這個 Windows 的 Linux 子系統。
在導入持續整合(CI)後,方案與專案架構方式 的分享,從小朱與董大偉老師得到很棒的回應:
小朱:我兩種都用過,但我最後採用 Multiple Solutions。
董大徫:目前我們team的VSTS專案,一個Repository裡面會有多個solutions(如果有必要的話,小一點的專案只有一個),一個solutions裡面會有多個project(幾乎都是這樣)。只要會彼此reference或必須一起build的project,我們大多會放在同一個solution。如果本質上不需要一起build(但架構上有關,例如一套ERP中的某幾個部分,例如mobile App, desktop client)、且Work Items/Sprints在一起控管的project,會切成兩(多)個solutions(但大多放在同個Repository)。至於Deploy,一個Solution裡面有多個Web Project應該不少見,在Build完之後(同一個build definition)可以同時deploy到各自的web site這應該沒問題。但我們用的是TFVC。
在 VSTS 的 Build(CI) 建立 build definition 時,通常會選擇範本來調整修改,例如,選擇 Visual Studio 範本:
在不修改範本步驟與內容的情況下,我們直接進行 Build 動作,我們可以看到所有動作都亮起綠燈:
看到綠燈,心情就非常好。但我發現一個可怕的事實...
https://www.nuget.org/ 提供套件管理的好處大家都知道,處理相依性、web.config組態管理、套件升降級等等方便性,免費。大量佛心人員提供可重覆使用的元件(輪子),免費(絕大多數)。而自從有了 NuGet Server 之後,架設私有NuGet Server就是一件簡單不過的事。對於要上傳套件至 Nuget Server 也走過一些路,最早是用 NuGet Package Explorer 發行與管理,後來知道了 NuGet Packager 這個好物,可以直接從 Visual Studio 進行發行,超高興的。不過好景不長,大家又開始流行 DevOps,希望往自動化更進一步,所以我們又開始在VSTS上進行 Team Build + Release Management 發行至 Microsoft Azure 上的站台!
這裡有個很大的問題 Azure Web Site,預設的 NuGet Server 是個公開的環境,除了上傳套件需要 ApiKey 外,其他瀏覽或下載使用很非常自由的。也就是,在非公司內網環境,你的私有套件可能有一天突然就被下載與看光光了。
以前是無解,現在終於有一個很好的選擇:Visual Studio Team Service - Package Management。
如果你有跟著 ASP.NET Core (1)(2) 篇練習的話,會發現開發上有那麼些許的不方便,就是我們要不斷中斷dotnet程序,重覆dotnet build
、dotnet run
的流程。我們希望後端的 C# 也能像前端擁有 LiveReload 或 React Hot Loader 的功能,在 Visual Studio 我們介紹過 Reload 來解決此一問題,而在.NET Core dotnet watch
套件可以實現自動編譯的工作。
前篇:使用ASP.NET Core建立Web API服務,我們使用 VS Code 來開發了一個.NET Core(ASP.NET Core) 的 Web API 服務,接著我們要把開發好的服務發行至Microsoft Azure來執行。和前篇相同,如果是使用 Visual Studio 那麼發行動作只在點選之間就完成了,不過這篇,我們依然是不採用 Visual Studio 來實作,還是使用 VS Code 與指令來完成。
在 VS Code 切換至 git 圖示,點擊"初始化 git 儲存機制"並且在訊息輸入第一次簽入的資訊。
.NET Core(ASP.NET Core)與之前的 ASP.NET MVC / ASP.NET Web API 兩套不同的 Framework 不同,ASP.NET Core 中的 MVC 整合了 Web API,現在要建立 API 或 Web 都將更為簡單,因為整合後的 ASP.NET Core MVC 基於相同的程式碼與管線(pipeline)。
ASP.NET Core 的跨平台特性,使用開發工具與開發環境的選擇相當多元。
.NET Core SDK 安裝:
安裝頁面有各平台(Windows, Linux, Mac, Docker)的安裝指南,照步驟安裝即可。
開發工具方面:
使用 Windows 的開發者,地表最強的 Visual Studio 當然是最好的選擇,如果使用 MAC(Windows) 那 VS Code + C# 擴充套件後也不差。如果 Visual Studio 2015 Update 3 並安裝了最新的 .NET Core Tooling Preview 2 for Visual Studio 2015 ,那麼已包含 .NET Core SDK 的安裝。
如果 VS Code + C# 擴充套件,使用起來不是很順(例如,IntelliSense、提示加 using 等),看一下 OmniSharp Log (檢視 → 切換輸出)是否正常。重開幾次 VS Code 看看。
測試工具:
兩套測試工具都行,挑喜歡的用即可。
範本工具:
安裝指令:
npm install -g yo
npm install -g generator-aspnet
這是延伸自 yeoman 的範本產生器,在不使用 Visual Studio 的情況下,它會很有幫助。
以下範例,讓我們使用 VS Code 來走一次建立 ASP.NET Core - Web API 的過程。相同的過程,使用 Visual Studio 的體驗與以前沒有太大差異,更重要的是,使用 VS Code 可以讓我們更瞭解 .NET Core 運作流程(因為要下指令),所以選擇使用指令與 VS Code 來進行實作。
我們的一個 Cordova 專案,內容有使用到 Bower 來進行套件管理,設計者提醒我們,簽出之後需要申請對外網路,透過外網才能正常還原下載所有 Bower 管理的套件。原先一直以為是資安方面的考量,而且也能透過外網去進行還原,再回到內網繼續工作,就沒多想兩分鐘。但老天爺不放你走,怎麼可能走得了。
近日,在公司 VM 內幫同事設定開發環境,就碰到此一難題,Bower自動還原失效,專案根本無法建置與執行,VM 又不是筆電,沒法子換上臨時外網去進行 Bower 還原,怎麼辦呢?
前一篇「雲端VSTS透過地端MAC建置iOS專案-以Cordova專案為例」我們建立雲端 Visual Studio Team Services(VSTS) 與地端 MAC 的 Agent 的連接,但要觸發地端 MAC 的 Build 行為,還需要在 VSTS 裡去定義 Build 的步驟與行為,然後 Agent 會依照我們在 VSTS 定義的步驟一一執行。而 Cordova 專案在 iOS 上有二種 Build 的方法,一種是 Cordova Build,另一種是 Xcode Build。
想要在 VSTS 裡去定義 Cordova Build,必須先安裝 VSTS 的擴充程式,請先在 VSTS 登入的瀏覽器去開啟 Cordova Build 網頁進行安裝。這樣 Cordova Build 會才出現在"add build step..."的步驟裡。
VSTS 除了可以透過本身提供的 agent 來建置之外,它也提供 private agent 的設計,意思是自行架設的 agent 來進行 Build 的工作。今天我們需要編譯一個iOS專案,例如,Cordova 專案,VSTS本身沒有提供這個iOS agent,那麼我們需要準備一台 MAC,然後在這台地端 MAC 安裝一支 agent 與 VSTS 連線,這樣雲端的 VSTS 就能發專案發行至地端 MAC。
以下先建立一組PAT帳號,以便地端的MAC Agent可以與雲端的VSTS連線。
在巡覽列自己帳號選擇「My Profile」,選擇「Security」的頁籤,選擇「PerPersonal access tokens」選擇「Add」,新增後即可取得 Token。
如果你沒有權限可加入,可以請管理員幫忙加入。
我在設定時碰到我已經加入 Security 的 Administrators 的群組,還是無法加入上述兩個群組。這時只能請連絡管理員幫忙加入也行。
Visual Studio Code(VS Code)是微軟新推出跨平台(Linux, OSX, Windows)的程式編輯器。前較於Visual Studio,VS Code非常的輕量化,且對於前端程式的支援非常的強大。我們想要透過VS Code當成Visual Studio Team Service(VSTS)專案的另一個開發工具(尤其是MAC OSX的使用者),這樣就不用特地在MAC OSX上去安裝虛擬機再裝Visual Studio。
在瞭解分支命名資料時,看到一篇StackoverFlow的git branch naming best practices討論,覺得解答者 phord 提供的建議非常不錯,簡單翻譯筆記一下。
上圖,是我碰到的怪問題,我的 Visual Studio 在電腦安裝更新並重開機後,Visual Studio 啟動後就一直停在啟動畫面,等超過數十分鐘完全無反應,從工作管理員來看,Visual Studio並不在應用程式清單,反而是在背景處理程序清單中,整個CPU與磁碟並無任何更新程式之類的程序在跑。Visual Studio 就靜靜的在那裡與我相望。
Visual Studio的問題碰過不少,以下整理我碰過的問題與解決辦法。(我好命苦 XD)
自從「ASP.NET MVC 4網站開發美學」一書的Web API章節介紹Postman開始,Postman一路穩扎穩打,從網頁版到Chrome App版一直都是Web API(RESTful)開發人員的首選,Postman一個人用,真的超級好用,而且後來加上的Sync(同步)功能後,只要註冊一個帳號,不管你有幾電腦,登入之後通通全部自動同步完畢。像我家裡有二台筆電、公司有一筆電一桌機,有了"Postman + Sync"幾乎是個人完美的解決方案了。
可以瑞凡-現在不是一個人的世界了。
在一次機會中,需要在ASP.NET MVC去接MySql資料庫,試玩一下之後,發現在ASP.NET MVC與Entity Framework環境下去對接MySql資料庫並不會太難,以下為簡單的筆記。
其實走對第一步,對接MySql資料庫已經完成了80%說。 :)
首先你要安裝三個重要的元件:
ASP.NET Web API一開始就以JSON.NET來取代JavaScriptSerializer以完成世代交替,JSON.NET的表現一直是中規中矩,以我的認知他是求穩。ASP.NET Web API採用Formatter的設計方式,預設有JsonFormatter與XmlFormatter,在求快的過程,如同頭文字D的86,換上一顆新F1引擎是最快的方式,我們來替ASP.NET Web API安裝一顆JilFormatter的高速引擎。
在前集,找到以效能(速度)為主軸的Jil套件,經過自我驗證後,在JSON(反)序列化效能上確實不差,這一篇我們就利用ASP.NET MVC優秀的擴充機制以新的JilResult來取代原有的JsonResult,以完成JavaScriptSerializer退休的使命,讓ASP.NET MVC換上一顆高速的JSON(反)序列化引擎。
ASP.NET MVC的ActionResult一直有個讓人疑惑的地方,就是它的JsonResult,JsonResult預設使用了.NET Framework的JavaScriptSerializer類別,並不是說JavaScriptSerializer不好,每一個技術都有它的時空背景,.NET Framework發展過程中JSON格式也是慢慢才成為標準。在JSON格式流行與大量使用下,JavaScriptSerializer已經有點上氣不接下氣。而微軟在ASP.NET Web API第1版中就非常明確的以JSON.NET取而代之。而ASP.NET MVC到第5版為止雖然一直無異動這部分的程式碼,原因也很簡單,ASP.NET MVC設計了優良的擴充點,讓開發者想要擴充原有的ActionResult也不是太難的問題。
如果讀者想使用Json.NET來擴充原有的ActionResult,可以參考Json.NET的作者James所寫的JsonNetResult或是參考黑大所寫的JsonNetController版本。這都是能直接上線使用的程式碼,我就不再多說明。
最近在進行專案效能調教,在MVC專案中使用了大量的JsonResult,在黑大JSON轉換效能評比-Json.NET,就決定是你了!得到JavaScriptSerializer早就應該退休了的結論,取代ASP.NET MVC預設JsonResult是個快又有效的一步。不過在這個唯快不破的時代,我想找找是否還有更好的選擇。
我發現一個JSON(反)序列化新選擇-Jil。
以下效能圖表參考原專案:
最近進行一些ASP.NET MVC/ASP.NET Web API系統效能改善的工作,改善之初當然是找出最耗效能(或是說較耗效能)的程式碼來下手改善。找出吃資源程式碼的方式很多,第三方有許多不錯的選擇,不過我需求真的很簡單,只想得到一個數字,在 .NET Framework 最簡單是用的System.Diagnostics.Stopwatch 類別進行耗用時間的測量。
我們先從最簡單的開始,計算一段程式碼的執行時間。
public ActionResult InActionTimer() { System.Diagnostics.Stopwatch stopWatch = new System.Diagnostics.Stopwatch(); stopWatch.Start(); // 模擬程式執行 System.Threading.Thread.Sleep(1527); stopWatch.Stop(); TimeSpan ts = stopWatch.Elapsed; System.Diagnostics.Debug.WriteLine($"ActionTimer: {ts.ToString()} from Foo/InActionTimer"); return Content($"ActionTimer: {ts.ToString()} from Foo/InActionTimer"); }
可以看到.Start()
與.Stop()
之間的程碼計算出耗費時間。
自從G大(谷歌)說,我要提升使用HTTPS網站排名之後,慢慢網站的世界有了改變。啟用HTTPS的網站比例不斷升高。例如,kkbruce.tw就啟用了HTTPS。這裡感謝DigiCert提供免費的SSL憑證。
kkbruce.tw是建置在Microsoft Azure之上,而且現在Microsoft Azure上的文件寫的還不錯,新的一年到來,也到了要更新kkbruce.tw的SSL憑證時間,要更新SSL憑證可以參考針對 Azure App Service 中的 App 啟用 HTTPS的內容。在取得SSL憑證,我採用的是使用 Certreq.exe 取得憑證。
如圖,我在第四步碰到些問題:
前一篇「使用VS2015建立單元測試專案」介紹VS2015的單元測試(Unit Test)建立與NUnit 2.6.x的使用方式。而NUnit 3在2015/11/16終於release了。這一篇是說要說明Visual Studio 2015與NUnit 3的整合使用方式。