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

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

Hello Visual Studio 2017

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 - ASP.NET MVC與API專案範本

Restart Visual Studio Message

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 憑證簽章檔案

如何在 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來

還在徒手揮汗寫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-使用反射執行方法的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 種方向。