發表文章

目前顯示的是 2019的文章

使用WIX建立Window安裝程式 - 包含.Net Framework

圖片
前言        此篇是接續,前一篇[ 使用WIX建立Window安裝程式 - 基本安裝 ],本文要來介紹如何在安裝時,順便將離線檔的.Net 4.8也順便安裝好。 建立Bootstraper安裝專案 1.選擇專案樣板:Bootstrapper Project for Wix v3。此專案用來將多個安裝專案及必要條件,作封裝用。 2.加入應用程式專案、前一篇建立的Setup,以及相關extension參考,如下圖的(1) 另外圖的第2點Resources目錄下有一個.net 4.8的離線安裝程式,等會我們會把它封裝入安裝程式內。ps:此檔案不會在Github的原始檔內,因為檔案太大無法簽入。需要的話請 另外下載 3.打開Bundle.wxs,修改如下圖,此為部份設定,完整的請參考 Github的完整程式 。關於此檔案的設定,實現的功能如下: PackageGroup : 指定.net framework 4.8的檢查條件及安裝來源、命令等。 Chain : 設定安裝順序,本例:先安裝.net 4.8後再安裝Setup.msi。 設定完畢後,按建置會產出一個Setup.exe檔案,此檔案已含安裝程式.msi及.net 4.8安裝程式,安裝畫面如下: 用戶端沒有安裝.Net 4.8的話,會先安裝: 安裝完畢後,若此次有安裝.Net4.8,會要求重新開機。 若本來已有的話,則會出現Launch 按鈕。 參考連結 Sample  (主要參考) http://www.shisujie.com/blog/WiX-ToolsetIndex Bootstraper theme Sample https://www.shisujie.com/blog/Install-the-dotNet-Framework-Using-Burn

使用WIX建立Window安裝程式 - 基本安裝

圖片
前言        目前有一支.Net 4.8的Window程式,要讓使用者下載來安裝。在安裝過程,若用戶端沒有安裝.Net 4.8的話,也要在安裝過程中一併加入。關於.Net Framwork的安裝,以個人之前的經驗, 若採用線上安裝的話,在某些情況下,常會發生一些奇怪的問題(例如:防火牆、網路中斷等),而導致安裝失敗。所以打算用離線的安裝來解決此問題。 一開始是使用Visual Studio傳統的安裝專案,但封裝後的安裝檔,在給使用者安裝,沒那麼直覺,它會產出2個檔案: Setup.msi : 主要的應用程式安裝,若不考慮.net的執行條件的話,可以直接使用這個安裝。 Setup.exe : 會先檢查必要條件後,例:.net 4.8。再進行msi的安裝。 上述,勢必要先作一個壓縮檔,給使用者下載後,再解壓縮來安裝才行。 WIX Setup 研究相關的安裝工具後,找到Wix這個不錯的安裝工具,它是透過XML格式定義安裝元表,並在Visual Studio有對應支援的專案樣板。開始必須先安裝如下: 專案樣板 : Wix Toolset Visual Studio 2019 Extension SDK : https://github.com/wixtoolset/wix3/releases/download/wix3112rtm/wix311.exe 安裝後的路徑:C:\Program Files (x86)\WiX Toolset v3.11\bin\ 程式要參考的dll位置。 建立第一個安裝專案 1.選擇專案樣板: Setup Project for Wix v3。主要的安裝專案,輸出msi 。不考慮安裝.net framework的話,可以直接用這個。 2.加入應用程式專案參考,本例為WpfApp 3.加入Wix Extension參考,本例參考WixUIExtension,瀏覽路徑:C:\Program Files (x86)\WiX Toolset v3.11\bin\ 4.打開Product.wxs,修改如下圖,此為部份設定,完整的請參考 Github的完整程式 。關於此檔案的設定,實現的功能如下:

.Net Core IIS 503錯誤

圖片
這兩天試著把測試的Blazor App部署到IIS後,一執行就出現503錯誤,並且Pooling整個停止。 測試環境: .Net Core 3.0 Window 10 Build 17763 部署方式 503錯誤 一開始Google時查到的解決方式,大部份的文章都是裝完 ASP.NET Core Runtime & Hosting Bundle ,即可解決。但我安裝完, IIS及電腦都重開機過,但依然出現503錯誤。 查詢"事件檢視器"後,發現一些缺少.dll的錯誤。如下列表: The Module DLL C:\Windows\System32\inetsrv\isapi.dll failed to load.  The data is the error. The Module DLL C:\Windows\System32\inetsrv\iiswsock.dll failed to load.  The data is the error. The Module DLL C:\Windows\System32\inetsrv\iprestr.dll failed to load.  The data is the error. The Module DLL C:\Windows\system32\inetsrv\aspnetcore.dll failed to load.  The data is the error. 上述訊息,不是一次性的全部出現,是在我根據訊息,查詢到的可能缺少的元件,安裝後,再出另一個的訊息....昏。由於是本機測試,不管三七二十一,也不太確定是哪個安裝修正哪個錯誤了。 相關安裝: IP Address and Domain Restrictions Web Socket Web Deploy 3.6 在解決了一系列的錯誤後,最後還有另一個奇怪的錯誤要修正。為何寫在這,沒有列在上方? 因為它的解決方式較特別。 The Module DLL C:\Windows\system32\inetsrv\aspnetcore.dll failed to load.  The da

Try.Net - 建立互動式文件

圖片
   這兩天看在Net conf 2019,看到一個蠻有趣的介紹。配合Markdown編輯及讀取既有程式碼的方式,變成一份線上可以即時互動的說明文件。 直接看範例 ,比較容易懂。 安裝說明 1.打開command視窗, 安裝dotnet-try dotnet tool install --global dotnet-try --version 1.0.19317.5 2.在專案加入Package參考,這個套件為alpha,Include prelease要打勾,才看得到。 專案類型: .Net Core 3.0 ConsoleApp。 System.CommandLine.DragonFruit System.CommandLine.Experimental   3.修改Program.cs  修改進入函式的參數,新增region,此為判斷進入的文件要指定該呼叫哪個函式用。 新增2個測試函式Intro,Collections。函式內需要被線上執行的部份,使用region區段區隔。 4.在專案目錄的上層新增一個文件目錄"mydoc",並加入檔案如下: Readme.md,此為文件首頁進入點。 HelloWorld.md 底下程式碼片碼 紅框 為重點,指定此區段的參數,該呼叫哪個程式檔案及區段。 ps:文件目錄不能放在專案目錄內,經測試後,會造成找到重複類別的錯誤。 測試程式 在 文件目錄下執行命令。 dotnet try 執行後,會開啟文件首頁。 進入Hello World連結後,會看到Program.cs的程式碼已帶出來,並可以直接執行。 其它參考 .netConf Beyond Copy + Paste : Creating Interactive Documentation 微軟教學文件 文章範例

Visual Studio 啟用 diagnostic tool

圖片
這兩天Visual  Studio 2019 更新後,在debug時,發現我的Diagnostic Tools不見了....。 花了些時間重新把它呼喚回來.....如下: 如何打開 Ctrl+Alt+F2 開啟Diagnostic Tools視窗。 啟用IntelliTrace              Tools -> Options -> IntelliTrace -> General 這樣在debug時,就可以即時查看memory,cpu,sql等資訊.. 參考連結 https://blogs.msdn.microsoft.com/msdntaiwan/2015/07/21/visual-studio-2015/ https://social.msdn.microsoft.com/Forums/en-US/d399acca-2cd5-4c03-a53f-7b8d79c9cb9c/diagnostic-tools-events-window-empty-blank?forum=vsdebug

Pipeline Shared Library-目錄方式載入-2

圖片
前言    前一篇提到了 Pipeline Shared Library-目錄方式載入 ,可以確保不會因git無法連線,而無法執行工作。但...這樣作的另一個缺點是,當要Library修改後,要更新時又要手動copy一次。這種手工工作,作一次還ok,多了自己都看不過....。 解決方法 1.新增另一個Job,透過git下載Library,並將設定將Library的位置指向它。 2.上面第1點基本設定好就可以使用,但有一個問是放在workspace的目錄,會定時被清空,所以需作一下調整,將git下載後的Library複製到另一目錄,並將設定將Library的位置指向它。 本例:複製到根目錄 stage ('copy') {                  steps {              fileOperations([fileCopyOperation(                   excludes: '',                   flattenFiles: false,                   includes: "**/**",                   targetLocation: "${JENKINS_HOME}\\SharedPipelineLibrary"                 )])                 echo "${JENKINS_HOME}"              }         }

Pipeline Shared Library-目錄方式載入

圖片
前一陣子將Jenkins上的Job改成Pipeline grovvy的方式撰寫腳本後,整個CI的運作,也變得相當有彈性。上手後,真的是回不去原本的GUI設定方式。在Job比較多時,針對相同的腳本可以使用Shared Library的方式將共用方法封起來,方便維護與調用, 參考文章 。 問題 回到本文,這陣子同事回報最近的Job在建置失敗時,都沒有發出通知。檢查原因後,發現兇手為Pipeline引用Shared Library時,因載入的方式使用的是git,當git server連不到時,整個Job內的腳本是不會被運行的。所以當然也不會執行到falire的通知區段。 解決方式 Google一下後,好像沒有人有類似的問題....可能是我們家的主機放在網路不甚穩定的區域吧...XD。在找不到相關解決方式下,將方向轉往若不使用git取得,改用目錄位置取得。作法如下: 1.安裝Plugin : File System SCM 2.將Library搬到Jenkins主機目錄,本例:D:\Jenkins\KimPipelineLib 3.到Pipeline Shared Library設定相關參數。 Default version:若是git方式,此值為branch,現在為File System,為檔案比對的識別標籤(必填)。 選擇Legacy SCM後,才會出現File System的參數設定。     Library的主機目錄位置。 參考文章 https://blog.johnwu.cc/article/jenkins-pipeline-job-shared-library.html https://www.slideshare.net/roidelapluie/jenkins-shared-libraries-workshop

關於MVC Area Routing的怪異問題

圖片
問題 同事反應了一個關於MVC Area的怪異問題。客戶自行輸入一個不存在的網址,本應該出現404找不到,但卻發生Exception。如下圖,找到JiahuaController的Index,但找不到View。 原因 Route往子層的Area比對到了,專案的層級如下: Root/Home/Index Kim(Area/ Jiahua /Index 一般來說,瀏覽/Jiahua會比對到上層預設的Route,而透過namespace的限制,照理來說不會往Area比對才對。如下圖,結果,它是在此namespace比對不到後,又往area的contoller尋找...昏。 解決方式 以下兩個擇一即可解決: 1.透過自訂Route,只比對上層的Controller。ps:此方法不是最佳解,這是在找到最佳解前實作出來的。 /// <summary>     /// 此類別的建講式只會被執行一次     /// http://johnatten.com/2013/08/21/customizing-routes-in-asp-net-mvc/     ///  https://stackoverflow.com/questions/21583278/getting-all-controllers-and-actions-names-in-c-sharp/21583402     /// </summary>     public class IsRootController : IRouteConstraint     {         private Dictionary<string, string> _rootControllers = new  Dictionary<string, string>();         public IsRootController()         {             Assembly asm = Assembly.GetExecutingAssembly();             var _rootControllers = asm.G

AzureDevOps-透過Command Merge

環境 AzureDevOps Jenkins git 問題     目前的專案每天中午會透過手動的方式,固定發pull request將develop分支併到relesae。由於是常態性質,大部份是不需要review,所以一來浪費時間,二來有時一忙就會忘了作=.=。 解決方式 經測試後,可以透過command及Jenkins的建置工作來完成每日自動合併,以下為測試後的2種方式 (使用jenkins pipeline) 1.使用merge的方式 withCredentials([usernamePassword(credentialsId: '0f57466e-8dc0-444b-a88a-d56d663d3378', usernameVariable: 'username', passwordVariable: 'password')]){     bat "git pull https://${username}:${password}@xxx.visualstudio.com/KimGitLab/_git/KimGitLab"     bat "git merge origin/develop"     bat "git push https://${username}:${password}@xxx.visualstudio.com/KimGitLab/_git/KimGitLab" } 透過withCredentials取得在Jenins上已儲存的AzureDevOps token pull回來後,merge orgin/devlop到本地的release 在pull到遠端 2.使用Pull Request的方式 前面第1點雖然可以每天合併分支,但缺點是在release分支上無法看出develop每次併回來的commit有哪些。而pull request則可以。 安裝VSTS CLI 裝完後要重開機 VSTS CLI Command Sample withCredentials([usern

VS2019無法載入專案The tool version "15.0"

圖片
這兩天看到VS2019正式發佈後,馬上下載來試玩,未料一裝完打開專案後,還來不及開心就出現了無法載入專案錯誤...。 C:\projects\test.csproj : error : The tools version "15.0" is unrecognized. Available tools versions are "14.0", "2.0", "3.5", "4.0" 原因 : 依測試結果,若是 全新的OS安裝不會有問題 ,而原本筆電已有VS2017的才可能會發生。 搜尋相關文章後,錯誤訊息都指向了MsBuild相關的DLL在GAC等版本問題。在連串的測試及比對後,發現MsBuild相關的dll在全新OS安裝下只會有4.0及14.0。而我的筆電卻有 15.1 版本的dllGAC 解決方式: 用administrator 打開Visual Studio Developer Command 執行以下命令來移除Microsoft.Build.*.dll 15.1版本 gacutil.exe /u "Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" gacutil.exe /u "Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" gacutil.exe /u "Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" gacutil.exe /u "Mi

[debug] 分析iis log的工具Log Parser Studio

圖片
今天在查詢IIS Log時,用Notepad打開後,憑著我的鷹眼逐行搜查....。查到一半時,才想到好像有什麼GUI工具的....。馬上Google了一下,果然有一個Log Parser Studio可以使用。 安裝連結 1.安裝Log Parser 2.2 https://www.microsoft.com/en-us/download/details.aspx?id=24659 2.Log Parser Studio https://gallery.technet.microsoft.com/Log-Parser-Studio-cd458765 如何使用 選擇Log 來源 使用現成的Library查詢,本例查詢較緩慢的Request 上方是結果,下方是查詢語法,你也可以複製出來改成你要的。 time-taken 為毫秒,例:5000=5秒 Ps: 馬的...有種從古代來到了現代的感覺。 參考來源 Log Parser Studio介紹 https://dotblogs.com.tw/kinanson/2017/08/18/145528 如何取得IIS記錄檔 https://note.robinks.net/2013/09/how-to-get-iis-log-files.html

使用WinDbg偵錯CPU使用率過高原因

圖片
昨天同事回報,主機上IIS 的CPU不定時衝高50~99%。本想說dump w3wp.exe回來使用WinDbg偵錯。但它間歇性的衝高,一下子就回復了,所以很難dump到在CPU衝高的狀態。幸好微軟提供了針對此狀況的dump工具「 P rocdump 」 ,用來監控特定的process,當超過CPU設定值後自動dump。 Procdump  Download & Setup 下載路徑 教學文章 安裝後,在開始功能列會看到32及64位元的ICON 使用管理者執行cmd -ma 包含所有ram、thread的信息 -r 讓目前的w3wp可以在不用暫停的情況下dump,缺點是會花費較長的時間dump 17488 為w3wp.exe的Process Id -c 50 cpu超過50% -s 3  持續超過3秒 -n 工具退出前要抓取多少個dump文件,例:設-n 2 代表會等觸發了2次dump文件後關閉監控 D:\Downloads\Procdump\procdump.exe -ma -r -c 50 -s 3 -n 1 17488 -o D:\dumpfile WinDbg Download & Setup Dump的檔案,可以透過WinDbg分析除錯 下載路徑 教學文章 只勾選一個Debugging Tools for Windows WinDbg Command 1.先載入dumpfile 2.設定路徑,由微軟網站下載分析需要的Symbol檔 .sympath srv*D:\Temp\debug\RTX64_SYMBOLS*https://msdl.microsoft.com/download/symbols 3. 指定顯示完整Symbol下載資訊 !sym noisy 4. 載入 CLR 偵錯相關模組 .cordll -ve -u  -l 5. 找出佔用 CPU 最多的 Thread,本案例中,Thread 29為使用最長的時間 !runaway 將偵錯對象切換成 Thread 29, ~29s

Jenkins-更新Slack 2.1.5後無法發送

圖片
昨天更新Slack Plugin後,無法收到通知,原因為2.1.5後,設定要重新輸入,並且原本的Integration Token已移除,如下圖 修改方式 1.到Credentials 加入驗證資訊 Kind : Secret text Sercet : 輸入 Slack 提供的Token 2.在Configure/Global Slack Notifier Settings 選擇剛建立的Credential 

IIS網站更新後第一次執行異常緩慢

測試主機的網站,最近只要程式有更新,第一次執行會異常得緩慢.....要花費約10分鐘之久!真是有夠誇張。將Pooling回收測試,只要20秒。研判應該是跟程式在第一次執行時編譯有關。 為先証明程式本身是沒有問題的下,我又在IIS建立另一個網站來試,測試結果只要30秒.....昏,同一份程式在同一主機下的不同Site,會有不同的結果。在查詢相關文章後,才知道是IIS  Temporary ASP.NET Files目錄過大的問題。 解決方式 刪除暫存目錄。一開始在檔案總管要刪除,但目錄太大,進度視窗跑不完。所以改用如下的PowerShell刪除,並使用強制刪除及忽略參數(太久沒清,執行50分鐘)。此方式可以不用在停止IIS的狀況下刪除檔案。 Get-ChildItem "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET  Files\" -Recurse | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue ps:為避免日後再發生,將它設定到排程在假日時執行,一勞永逸。 參考連結 https://www.itread01.com/content/1501827610.html