Windows Server Core新手區:如何檔案分享與Proxy設定

安裝好 Server Core 遠端桌面連線之後你會發現只有一個 command line 畫面在等你。以下就幾個必須先處理的問題記錄一下。

• 如何與進行檔案分享
• 如何設定Proxy

一次就愛上MS SQL Server for Linux

MS SQL Server for Linux 是微軟重大的一步，它非常輕量但是使用相同和現有 SQL Server 資料庫引擎。以下介紹如何在 docker 下去建立並使用 mssql-server-linux，讓各位從入門到愛上它！

Let's go！

注意，讀者需要有 docker 基本概念。本篇不會太深入 docker 身上。

Docker：Private Registry for Windows Container Service

Docker - Private Registry-Windows Container Service

公司環境特別，在測試 docker 過程只能被限定在 Windows Server 2016 - Windows Container，測試過程碰而一個非常實務上的需求，在公司內部需要架設私有 registry 服務，以提供私有 docker windows images 的 push 與 pull 服務。

第一次失敗

第一次，找到 docker 官方的 labs 的文件：https://github.com/docker/labs/blob/master/windows/registry/part-1.md 有做出 registry.exe 了，但在「Dockerfile for the Registry Server」步驟一直卡關，一直無法往下進行，苦腦了幾日。

超狂．超提升ASP.NET Web API效能的8種方法(有沒有100倍呀?)

看到一篇 8 ways to improve ASP.NET Web API performance 覺得整理的不錯，順手簡單整理與寫點心得。

1. 使用最快的 JSON 序列化套件

ASP.NET Web API 預設採用 JSON.NET。JSON.NET 求穩不求快，如果要求快，透過 ASP.NET Web API 優秀擴充點機制，可隨時更換序列化套件。

之前在 Blog 介紹過 Jil：

• JSON(反)序列化之唯快不破新選擇-Jil
• ASP.NET MVC-取代JsonResult新選擇-招喚JilResult
• ASP.NET Web API-取代JsonFormatter新選擇-招喚JilFormatter

8 Ways作者則是採用 ServiceStack.Text 套件。

圖片來源：theburningmonk.com

ASP.NET Core Debugging Breakpoint not hit?

同事反應，ASP.NET Core 專案無法正常進行中斷點(breakpoint)偵錯。簽出專案，下中斷點偵錯取得以下資訊：

The breakpoint will not currently be hit. No symbols have been loaded for tis document.

如果這時你下關鍵字「asp.net core breakpoint」去搜尋，在第一筆你就能找到解決方案。

他的解決方案是叫你「關閉：Enable Just My Code」與「開啟：Microsoft symbols Server」。

如果這樣就解決了，那我還要寫這篇嗎？

POST GZIP/Deflate Data to ASP.NET Web API

前一篇使用GZIP或DEFLATE壓縮，提升資料傳遞效能40倍，我們處理了查詢資料量大時，Web API 在傳遞未經壓縮的資料產生許多不必要的網路流量的問題。現在我們轉換方向，如果是用戶端要傳遞大量資料至 Web API 時，那麼我們要怎麼處理？這比較麻煩，有二個方向要討論，一是 Client 端進行發送請求時，必須先做 GZIP/Deflate 的壓縮，而 Web API 接收到 GZIP/Deflate 壓縮資料後需要解壓縮還原資料內容。

從這個方向來思考，你應該能發現另一件事，就是前一篇我們只專注在 GZIP/Deflate 的壓縮上，並無做任何解壓縮的工作，那是因為瀏覽器本身在協商過程與接收到的 Header 可以判定接收到的是 GZIP/Deflate 的內容，瀏覽器會直接幫我們進行 GZIP/Deflate 的解壓縮工作。

ASP.NET Web API使用GZIP或Deflate壓縮，提升資料傳遞效能40倍

專案有個查詢資料量不小，基本測試資料每次約1.92 MB，透過 ASP.NET Web API 傳遞至 Client 端每次就是 1.92 MB 的網路傳遞量，而且未來上線後，資料量只會越來越大，直覺感到不對勁(壞味道)。

IIS的動態壓縮與靜態壓縮對 ASP.NET Web API 是無效的。而且，平常 ASP.NET Web API 的請求，資料負載量也不是很大，那種 KB 級的資料壓縮率不高，平常也就沒特別注意。不過在 MB 級的資料，有無啟用 GZIP 或 Deflate 壓縮的資料量差異，直接說結果，以我實測得到的數據差了40倍。

如何在Visual Studio 2017中編輯Global.asax

某個專案進行重構，異動部分較大，連方案、專案檔都重新命名，進而影響命名空間。全部整理完之後，重新建置正常，但執行確出現一個Global.asax錯誤。

線上網站很慢！使用DebugDiagnostic Tool進行線上IIS網站程式效能分析

我們有個專案的架構如下：

JS Framework <--> ASP.NET MVC <--> ASP.NET Web API(Service) <--> UDSP <--> ASP.NET Web API(Authorzation)

專案網站有個怪問題，如果網站2到3小時的時間無人使用，那麼閒置時間後第一個第一次使用的人會特別慢。針對IIS的Application Pool的啟動模式由OnDemand改為AlwaysRunning，針對IIS站台的預先載入也已經修改為true，但效果有限。相關停頓、反應時間過長等情境在本地端(Local)模擬不出來，由於分層(tier)過多追起來費時費工。

有無什麼好辦法，可以針對發行至IIS的站台進行線上的偵錯？有的，目前我知道的有三種方法：

1. WinDBG
2. IntelliTrace Collector
3. DebugDiagnostic Tool

WinDBG功能強大，但指令參數複雜，而且取得Dump檔的過程不是那麼友善。針對這樣的問題，WinDBG近期有推出一支Microsoft Store App - WinDBG Preview，可以透過GUI來查詢分析Dump檔案。IntelliTrace Collector也是強大，但推廣不易，因為IntelliTrace定位在Visual Studio企業版才能使用。DebugDiagnostic Tool是本篇的主角，選擇它的原因很簡單，第一、它安裝與使用容易。第二、它收集Dump容易。第三、它分析Dump容易。

首先，你必須先下載Debug Diagnostic Tool v2 Update 2並安裝至IIS所在的伺服器上。安裝好會多三套工具，DebugDiag 2 Collection、DebugDiag 2 Analysis、DebugDiag 2 RuleBuilder(beta)。

Project Template使用前請詳閱公開說明書

前篇「.NET開發者，你應該養成用空白範本寫正式專案」引起不少正反討論。其中有提到到團隊專案範本幾個字，fb討論我留下：「template有好有壞，好的是有規範，壞的是沒有創新與創意。但創新與創意又常常是重構的來源...」這句話，意外得到另一主題回應。我想就團隊專案範本來做另一主題說明，我為什麼會做這樣留言。

---

.NET開發者，你應該養成用空白範本寫正式專案

這是一篇有感而發的短文。

最近又在做效能調教的工作，在單一個專案內我移除了近30個無用的NuGet套件。其實不用問，一眼就能看出，這是一個從預設專案範本開始寫的專案。用專案範本有錯嗎？嗯，沒錯，也有錯。原因，最後在說。我們先來看看之前 twMVC#22分享主題：「一個微信專案從0到000的效能調教」的幾張投影片。

VSTS之Build(CI)自動化建置與XML組態轉換的神秘關係

關於的Web.config瞭解與使用，在開發的網站規模越來越大時，需要瞭解的越多，之前也做有幾次的討論：

• 在WEB.CONFIG中引用外部組態檔
• 讓ASP.NET網站在開發除錯時期擁有WEB.CONFIG文件轉換功能
• 好用的VISUAL STUDIO-XML文件轉換擴充套件

但這一次是碰到VSTS在自動化建置後產出Web.config一直不正常，一開始有點鬼打牆的狀態，但在新聞追追追的精神下，讓我又對Web.config組熊轉換又更進一步瞭解。

無法載入System.Diagnostics.DiagnosticSource錯誤

專案升級套件後，Web、API相繼掛點，出現黃白畫面：

Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Biztalk應用程式四大金剛-Schema, Pipeline, Map, Orchestration

Biztalk應用程式基本上是一個資料轉換+流程設計的封裝，這個流程的每個步驟(細節)都必一一定義清楚。最後，開發好的 Biztalk 應用程式部署提供給 Biztalk Server 來使用。讀者可以參考使用 Biztalk Server 處理 JSON Message 輸入輸出來閱讀本文，會更清楚Schema, Pipeline, Map, Orchestration四者的本質。

使用 Biztalk Server 處理 JSON Message 輸入輸出

以下，我們將以一個「JSON訂單-->Biztalk Server-->JSON發票」的 Lab 來簡單介紹 Biztalk Server 的設計與開發流程。

(from MSDN)

Microsoft Biztalk Server 2013 R2安裝與設置筆記

Biztalk Server 2013 R2安裝與設置

因 B2B 專案需求接觸到 Microsoft Biztalk Server 2013 R2 這個產品，因學習與測試需要，以下試著自己架設一台 Biztalk Server。Biztalk Server 的安裝區分為單機(全部安裝在同一台主機)與分離(Biztalk Serer 與 MS SQL Server)，因分離安裝額外包含許多權限與防火牆的設定，複雜許多，以下為單機 Biztalk Server 安裝與設置筆記。

專案進行當下，Microsoft Biztalk Server 2013 R2 為最新版本，目前最新版為 Microsoft Biztalk Server 2016。

關閉資料庫專案檔案造成Visual Studio 2017停止回應

同事反應，在Visual Studio 2017當要關閉修改過資料庫專案檔案時，整個 VS 2017 會停止回應數十秒才會關閉。在我電腦測試，確實會停頓個2-3秒時間才會關閉。本來以為是 SSDT 的問題，因為 SSDT 在目前的 VS 2017 還沒準備好。我猜，SQL Server 2017 GA 時應該會一併更新 SSDT for VS 2017 吧。

還好，轉個彎下對關鍵字，看到一個很瞎的解決方式。

重開 VS 2017，問題立即解決。

參考：

• https://developercommunity.visualstudio.com/content/problem/67789/visual-studio-hangs-when-closing-sql-files.html
• https://stackoverflow.com/questions/43983886/visual-studio-hangs-when-closing-sql-files/44507018#44507018

dotnet.exe五大天王new, restore, build, run, publish命令與watch外傳

在 .NET Core SDK 裡最重要的莫過於 dotnet.exe 命令，它提供一切 .NET Core 運行所需的基礎環境。

dotnet [command] [arguments] [--version] [--info] [-d|--diagnostics] [-v|--verbose]
dotnet [-h|--help]

dotnet 是進入點， dotnet 之後的 [command] 指定所要執行的命令，例如，dotnet build。也可以指定相容 .NET Core 的 DLL 來執行應用程式。

C#-寫一個 Retry 機制程式碼

平常，Web 比較多人問關於「時間」的問題是「排程」，在課程被問到「Retry」機制，想想，真的托開發微信API的福，我還真的寫過那麼一小段 Retry 機制的程式碼。完整程式碼沒幾行，就說點小故事，拉點畫面行數吧。

當時我們與微信的測試主機是放在 Azure 東亞(香港)機房，不過因為大陸特別的網路關係，每每從下班之後就變得不穩定，我們某個 API 需要收到對方很明確的回應(成功-失敗)訊息才能往下進行。但好死不死，大陸在下班至午夜的國際網路相當不穩定，以至於我們的 API 常常在下班｜半夜被搞死，那段時間，半夜看著Slack的Log偵錯，更是家常便飯。找了好久，才確定那支 API 不是問題點。但問題點來了，對方不知是有意或無意 loss 非內陸的請求，我們知道，把正式機放到 China Azure 就能解決特別的網路問題(後來我們正式機放進去了，還是一堆雷 >__< )。有無更好的解法？想了很久，我決定寫一個 Retry 機制。

Microsoft Build 2017之.NET開發者課程匯總小筆記

From:網路

Microsoft Build 2017 已經落幕，但開發者的重點才要開始，數百堂的技術分享，要如何吸收。還好，Scott Hanselman 幫我整理好了 BUILD 2017 Conference Rollup for .NET Developers 。目前我只看了前二個，簡單做了點小筆記。如果你對 .NET Standard 2.0 / .NET Core 2.0 / ASP.NET Core 2.0 興趣，最少建議花點時間把這兩篇看完。

如何成為Microsoft Docs繁體中文貢獻者

你是否有過邊看 MSDN Library 文件，不時浮現一個「x」字，心想：「這是在寫什麼鬼？」(台語)的疑問。

.NET 開發人員，你一定讀過 MSDN Library，早些年，MSDN Library 可說是 .NET 開發人員最好的朋友。但近年來，大量的機器翻譯，讓 MSDN Library 品質直線下降。其實，各位所提交的建議，原有一群義工人士，是"真"人工審核。後來不為何，義工人士不斷消失。小弟有幸加入這個消失中的義工團，就我而言，審核分專業和非專業，我不可能專精整個 MSDN Library 技術，在審核非專業內容時需要大量的時間。由於下班後時間有限，只能慢慢放低義工時間，最後，好像能瞭解，機器人造成大量的品質不良，要靠少數幾個人來改善是有難度的。

Micosoft Docs的Github開放開源

目前微軟新版文件庫叫 Microsoft Docs，這一個以開源為導向的文件庫，所有文件內容都開源開放在 Github 上，目前繁體中文化正在火熱進行中(但目前還有很大比例，你點擊後還是看到英文內容)，既然開源開放，那麼只要你有心，人人都能成為Microsoft Docs繁體中文貢獻者。目前有二種途徑可以參與：

VSTS Build CI建置Visual Studio 2017 C# 7專案失敗

早上簽入一專案，VSTS CI Build沒幾秒立即出現紅燈：

此專案為類別庫專案，差異點是之前是用 Visual Studio 2015 開發，目前改用 Visual Studio 2017 並重構 C# 6 語法改使用一些 C# 7 out variables 語法。就簽出來使用 Visual Studio 2017 開啟專案狀態來看，Visual Studio 2017 並無修改任何專案內容，在使用 C# 7 out variables 也能正常編譯出 dll 並讓其他專案參考使用。

直覺反應：VSTS 不支援 C# 7 編譯？不會吧！

ASP.NET Core-Tag Helpers無IntelliSense效果

在 ASP.NET Core 的 Views (Razor) 提供了一個新的 Tag Helpers，Tag Helpers 有別於 ASP.NET MVC 的 Html Helpers。在 Visual Studio 2017 可以新增「ASP.NET Core Web Application (.NET Core)」或「ASP.NET Core Web Application (.NET Framework)」專案：

1. 選擇 ASP.NET Core 1.1
2. 選擇 Web Application

我們開啟 Views/About.cshtml 貼上以下程式碼：

<form asp-controller="Movies" asp-action="Index" method="get">
    <p>
        Title: <input type="text" name="search" />
        <input type="submit" value="Filter" />
    </p>
</form>

可以看到 asp-* 的 Tag Helpers 會被解析為正常的 HTML 內容。但如果是手刻程式嗎呢？

可以看到，不論是直接輸入 asp- 或修改舊的程式碼，Visual Studio 2017 不會有任何 IntelliSense 提示。這...

安裝VS2017後造成SSMS 2016 Components錯誤無法啟動暫時解決方案

如上圖，同事安裝 VS2017 之後，SSMS 2016 無法啟動，啟動會出現：Cannot find one or more components. Please reinstall the application.

重新 re-install SSMS 2016 16.5.3 數次，試過這篇與這篇的做法，也都無效。

Visual Studio 2017資料庫專案語法高亮失效暫時解決方案

團隊許多專案，在資料庫部分都透過資料庫專案進行管理與發行。但在安裝 Visual Studio 2017 RTM 之後會發現，資料庫專案的語法高亮(Syntax Highlighting)失效，如下圖：

在微軟的 Developer Community 找到一個討論串，應該是 bug 無誤了。

其中 Christian Gunderman 提到some language services lose colorization，而且災情似乎只在non-English會出現，看起來要暫時解除此 bug 不是難事。

在非Windows 10(1607)純cmd.exe執行Linux Bash常用指令(ssh, vim, cat, grep, ls...)

之前有朋友在 fb 說他好高興，因為他的 Windows 可以直接下 ssh 指令，原本以為是如何啟用WINDOWS 10(1607)中的UBUNTU的BASH的好結果。結果是那台電腦安裝了 OpenSSL。

在非Windows 10(1607)要執行Linux Bash指令是挺麻煩的。

舉個實際例子：我今天開發 Xamarin app 要建置 iOS app，Visual Studio 突然連不上 MAC 主機，我想用 ssh 去確認 MAC 主機連線是否正常？第一件事就是 ssh 是 Linux 的指令，為了執行 ssh 指令你可以安裝 OpenSSL，哪天，你想用神器 vim 就裝個 Windows 版的 gvim80.exe，需要一個Linux指令裝一套？有沒有一個比較 Total Solution呢？

其實有，而且如果剛好你是位程式開發人員，那麼很有機會這個解決方案早已經在你電腦裡了。今天來分享這個小技巧給各位。

製作離線Visual Studio 2017安裝檔與新VS Installer初體驗

Visual Studio 2017 經過一年多的 Preview → RC，從目前官方 Visual Studio 2017 Launch Event 的消息來看，2017/3/7 會發行 Viusal Studio 2017 RTM 正式版，其中套件元件化是其中一個很棒的特色，也就是說，如果你的開發工作單純，Visual Studio 2017 的安裝是可能非常輕量化，各種元件之間相依性大減，寫 Web 裝 Web 元件、寫 .NET Core 裝 .NET Core 元件、寫 Azure 裝 Azure 元件、寫 Xamarin 裝 Xamarin 元件，不寫就移除元件，要寫再裝，一整個熱插拔的手感。

Visual Studio 2017 VS Installer 是另一個特色，VS Installer 改進了過去了 Visual Studio 的安裝體驗，新增/移除元件如上所說，另一個特色是Visual Studio 2017 更新或升級，例如，你現在安裝 Visual Studio 2017 RC 版，未來 RTM 推出時不需重新安裝，直接透過 VS Installer 進行更新升級即可。

說真的，從接觸 .NET 使用 Visual Studio 開始到現在，不知道為了 Visual Studio 重灌多少次電腦，光這二個特色我就感動到哭了。

消滅浪費的Visual Studio - ASP.NET MVC與API專案範本

Visual Studio 2015 Update 3 的 Web 專案範本有個問題(更正確的說，是NuGet套件造成)。如果你新增一個 Web 應用程式然後更新所有 NuGet 套件，更新完成後會看到 "Microsoft.Net.Compilers.1.0.0 failed to uninstall. Restart Visual Studio to finish the process." 的提示訊息。

新增專案的兩種浪費

自從接觸到Agile/Scrum之後，有個東西會特別注意，那就是浪費。

上述的情況最少有兩種浪費：

1. 重覆更新NuGet套件
2. 重啟Visual Studio

由於經常需要寫寫測試程式或範例，套件 30 秒重開 30 秒就這樣不見了，這兩件浪費的事有時一天會發生好幾次，尤其是在寫文章或備課期間更是明顯。

有浪費不消滅，說不過去。

如何在 Windows(非IIS) 製作 SHA2(SHA256) 的 .csr 憑證簽章檔案

今天在申請 SSL 憑證被單位告知，使用 IIS 產出的 CSR 採用的 SHA1 演算法已被破解(就找到的新聞來看，是被認為不安全，各大公司有計畫性的淘汰 SHA1，例如：SSL 和程式碼簽章憑證的 SHA-1 雜湊演算法移轉 - 以 SHA-2 憑證取代 SHA-1 憑證、HTTPS網站被Chrome打臉？)，需改用 SHA2(SHA256) 重新製作，但找了半天也沒找到 IIS 在建立憑證簽章請求的 GUI 中可以選擇 SHA2 演算法，後來才知道，使用 IIS GUI 來產生的 .csr 憑證檔案預設都是使用 SHA1 演算法。那麼怎麼辦呢？

還好小弟自己每年要為 kkbruce.tw 申請與安裝 SSL，剛好略懂 SSL 的申請與安裝，不然如果直覺下關鍵字「iis sha2 csr」(我還是有下啦)，那些方法看完頭都昏了。

還在徒手揮汗寫For測效能，閃開讓BenchmarkDotNet來

上集使用反射執行方法的7種方式我們談到寫法不同，效果不同這件事，也說到，通常我們測試程式效能會很習慣的採用 Stopwatch 模式(Stopwatch Pattern)來進行程式執行效率的比較。

Stopwatch sw = new Stopwatch();
sw.Start();
// stuff
sw.Stop();

我們把前面的 7 Ways 程式碼用 for 跑 20000 次計算時間，可以得到以下結果：

Way1 Time: 40 ms
Way2 Time: 40 ms
Way3 Time: 76 ms
Way4 Time: 67 ms
Way5 Time: 148 ms
Way6 Time: 4233 ms
Way7 Time: 2054 ms
  

但這樣對嗎？在談效率時，其實有二種意義：時間或空間(文言文：時間複雜度、空間複雜度)，我不是來教書的，雖然 Stopwatch 寫起來不複雜，但僅能看到時間單一面向，好像只要快就是好，怪怪的。

那有無更好的選擇？

Reflection-使用反射執行方法的7種方式

最近因為專案需求，努力寫著反射(Reflection)程式，還好哥早在2011年就打過底，但大型實務應用開發之後在 fb 上發表些小心得：

• 取得物件 System.Type 後基本上就無敵了。
• 你能做的、你不能做的，Reflection 都能做。白話：一些簡單的 private 之類限制對 Reflection 無效。
• 製作沒有規範 Assembly 的 Reflection 解析執行程式需要：細心、耐心與草x馬的愛心。(突然覺得那些反編譯器好偉大)
• 接上題，規範好 Assembly 介面定義，大家都會很開心
• 寫法不同，效果不同。純反射 4.1 > dynamic 1.4 < delegate 1.2。delegate 最快。
• Expression 網路上的資料它也比 dynamic 快，但我的實作不適合驗證，沒取得數值。
• ps. 美國微軟工程師的 Bruce 說，dynamic 能不用就不用。我自己的實作心得：dynamic 沒有比 delegate 快，又有些缺點，我也不建議使用。

後來，實在手癢的受不了，把底層用 Expression 改寫，得到以下結果：

• v1, reflection - 純反射，最慢;
• v2, delegate - 比純反射快 4 倍(自己測);
• v3, expression - 與 delegate 差不多;

速度與可讀性而言，目前 delegate 最好。寫法不同，效果不同。

Reflection - Method Invoke 7 Ways

這裡我將手邊知道的「執行方法」的方法做了以下整理，總共有 7 種方向。