本篇是把先前 "在 Visual Studio Code 中撰寫 SmartContract 並透過 Web3 進行區塊鏈服務交易 I、II、III" 的介紹，再串接到已建立好的 Azure Blockchain Service 服務 上並進行交易。
若有需要參考本篇內容，請先到 Azure 上建立好 Azure Blockchain Service 的服務。
PS 完成後 強烈建議 立刻把所建立的相關資源全數刪除，奉勸捧友別跟自己的荷包過不去喔💸💸💸
先前的介紹文章如下:
延續安裝 Meadow 的 Visual Studio Extension 與 建立 Meadow 開發專案後，接著透過 Meadow.CLI 工具繼續來安裝(更新) MeadowF7 開發晶片板的作業系統 meadowOS。
了解前一篇所介紹的處理後，捧友應該有發現要發佈 SmartContract 應用到乙太坊區塊鏈服務上(目前仍是使用本機端的 ganache-cli 模擬環境)，在處理上都有點蠢(但也是基本功)。
由於得 手動 透過 Web3 下達指令來取得 abi 與 bytecode 後，才能繼續完成發佈 SmartContract 應用，並再設定其 Web 應用才能進行交易。
本篇要繼續介紹透過 Truffle 的套件使用，並完成自動發佈 SmartContract 到乙太坊區塊鏈服務上的設定處理(仍是本機端透過 ganache-cli 建立的乙太坊區塊鏈模擬環境)。
接續第一篇 "在 Visual Studio Code 中建置 SmartContract 並透過 Web3 進行區塊鏈服務交易 I" 的介紹，接下來要進入建立網頁並透過 Web3.js 在網頁中進行 ganache-cli 所建立的本機乙太坊區塊鏈的服務交易設定。
針對區塊鏈服務來撰寫一個基本的 SmartContract 並不是什麼太特別的難事。在網路上利用關鍵字在各家搜尋引擎，搜尋後應該就有很多相關的文章介紹。
而本系列文章要透過使用 Visual Studio Code 來建置 SmartContract，針對先前的 "在 Visual Studio Code 中安裝 Blockchain Development Kit for Ethereum 延伸模組" 介紹文章，透過已經有安裝好的相關開發套件，並且在 Azure 上所建立的 Azure Blockchain Service 服務，來進行部屬自己的 SmartContract 進行乙太坊區塊鏈服務交易。
在本篇就來接續 "透過 VS Code 建立 Web App (Node.js) 並佈署到 Azure App Service (上)" 的相關介紹，完成發佈 Web 應用(Node.js) 到 Azure 的 Web App Service 吧!
GoGoGo~~~
對於一個相對長期大多是使用 Visual Studio 開發 .NET 相關(而且是 Mobile App - Xamarin) 應用的開發者來說，突然要在 Visual Studio Code 操作起全指令的方式，來做相關的開發操作還真有點不太熟悉呢😅
但也因為如此，更需要詳細的紀錄下來，讓自己好能回顧與記憶囉!
GoGoGo~~~
Azure Blockchain Service(預覽) 是 Azure 目前提供的區塊鍊服務中的一項 PaaS 服務，讓用戶可以快速地建立自己的區塊鍊應用，不需要浪費時間建立其基礎架構。
要在 Visual Studio Code 當中建立應用發佈到 Azure Blockchain Service 服務當中之前，需要先在 Visual Studio Code 安裝 "Blockchain Development Kit for Ethereum 延伸模組"。
由於步驟上有點煩雜，在本篇記錄其相關的安裝過程。
文長圖多...請慎入。
今年 (2020) 因為 Work from Home (WFH) 的快速興起，微軟 Teams 服務也是一個 WFH 的重要利器，對於一般使用者可能沒有什麼太大的問題，只要申請註冊成 Microsoft Account (利用如: hotmail、outlook、gmail...等 Email 帳戶都可以註冊)，即可開始享受微軟 Teams 服務種種強大的便利性。
但問題來了，因為微軟 Teams 服務本來的設計是給工作或教育帳號使用的，在設計上是綁定 Azure Active Directory (文後簡稱 Azure AD) 來做為驗證、授權...等管理的基礎。
在微軟將 Teams 服務提供免費版本給一般大眾使用的時候，在 Azure AD(目錄) 中就會根據註冊的 Email 帳號再產生一個隨機的 Azure AD(目錄) 來作為處理的機制。
(此為目前自己的認知，若有錯誤會再改正)
近期微軟將旗下的 Power 系列產品: PowerBI、Power Apps、Power Automate、Power Virtual Agent，整合成一套 "Microsoft Power Platform" 的解決方案:
(上圖取自微軟 Power Platform 官網介紹)
有需要了解更多的朋友可以直接到微軟的 Power Platform 的網頁 來觀看介紹。
光陰似箭歲月如梭，一年過去了...SSL 憑證剛好要更新，順便(?)也更換到另外一個網域中。
如果不知道如何設定網域 SSL 的捧友，請看:
今天要處理的問題是，把已綁定到某個網域的 SSL 憑證，綁到另外一個網域上，所以...就開始來動手做吧😎
自從 Microsoft 推出地圖服務到目前為止，曾歷經了相當多的改朝換代的地圖服務方式，在此不論過去的功過，先把目光投向 Azure 上近期推出的其中一項雲端的 PaaS 服務: Azure Maps。
Azure Maps 所提供的服務當中，也提供了室內地圖 (Indoor Maps) 的部分，讓地圖的應用不再侷限於室外資訊的使用，而是可以朝向室內來發展，例如: 在停車場當中車道與車位佔用資訊、展場或市集的攤位販售資訊、辦公大樓的各會議室資訊是否使用中(或其溫度、濕度狀況監控)...等，這些都可以進一步協助應用廠商，完成在某個室內地域中處理其資訊的最後一哩路，讓使用者在獲取地域資料上能更加透明與便利。
其詳細介紹可參閱微軟提供的 Blog:
https://azure.microsoft.com/zh-tw/blog/azure-maps-creator-now-available-in-preview/
自從 Microsoft 推出地圖服務到目前為止，曾歷經了相當多的改朝換代的地圖服務方式，在此不論過去的功過，先把目光投向 Azure 上近期推出的其中一項雲端的 PaaS 服務: Azure Maps。
Azure Maps 所提供的服務當中，也提供了室內地圖 (Indoor Maps) 的部分，讓地圖的應用不再侷限於室外資訊的使用，而是可以朝向室內來發展，例如: 在停車場當中車道與車位佔用資訊、展場或市集的攤位販售資訊、辦公大樓的各會議室資訊是否使用中(或其溫度、濕度狀況監控)...等，這些都可以進一步協助應用廠商，完成在某個室內地域中處理其資訊的最後一哩路，讓使用者在獲取地域資料上能更加透明與便利。
其詳細介紹可參閱微軟提供的 Blog:
https://azure.microsoft.com/zh-tw/blog/azure-maps-creator-now-available-in-preview/
自從 Microsoft 推出地圖服務到目前為止，曾歷經了相當多的改朝換代的地圖服務方式，在此不論過去的功過，先把目光投向 Azure 上近期推出的其中一項雲端的 PaaS 服務: Azure Maps。
Azure Maps 所提供的服務當中，也提供了室內地圖 (Indoor Maps) 的部分，讓地圖的應用不再侷限於室外資訊的使用，而是可以朝向室內來發展，例如: 在停車場當中車道與車位佔用資訊、展場或市集的攤位販售資訊、辦公大樓的各會議室資訊是否使用中(或其溫度、濕度狀況監控)...等，這些都可以進一步協助應用廠商，完成在某個室內地域中處理其資訊的最後一哩路，讓使用者在獲取地域資料上能更加透明與便利。
其詳細介紹可參閱微軟提供的 Blog:
https://azure.microsoft.com/zh-tw/blog/azure-maps-creator-now-available-in-preview/
有一天，突然某個手上的專案上線後需要提供部分資料給 End User 下載，放在 Azure 的 Storage 中 Blob 裡的資料也是都有供外部直接存取的 URL 沒錯，但直接給 End User 類似 "<xxxxxxx>.blob.core.windows.net" 網域開頭的網址來下載檔案好像也怪怪的(個人心理因素，資安上有無風險考量不確定)。
於是就查了一下資料...
結論是可以在 Azure 的 Storage 中綁定自訂(子)網域的，於是不囉嗦...就是開始動手進行綁定了😅
在 「替 Azure 的 App Service 網站設定自訂網域後掛上 SSL 憑證 (上)」 的篇章中，有提到如果購買憑證跟購買網域的單位、組織、或負責處理的人是不同的，會遭遇到驗證網域控制權的問題。
上圖黃標字寫了特別提醒，結果...有一天就遇上了😥
就說做人不要鐵齒了吧!
如果 AppCenter 的額度預算能有 "半無限大" 的話(?)，在 Xamarin 的開發上為了能夠 "感謝飛天小女警的努力，開發的世界又和平的度過了一天" 🙆♀️
通常可以在 Android 的開發過程中，選擇讓 iOS 能讓 AppCenter 自動化建置，以便確認在某些環節上 iOS 的版本是否有遺漏了什麼，才不會導致於後面要補 iOS 的部分時，不知道該從何處下手。
畢竟會選擇使用 Xamarin 技術開發 App 的話，通常是伴隨著希望雙平台的 App 的誕生。但由於一切的資源都是有限的，開發上會先選擇單一平台先進行到某種層次上的段落後(又通常會先選擇 Android 來進行)，再來補上另一個平台的部分。
此時有 AppCenter 來協助進行相關的建置紀錄的話，會讓開發上有著相當程度的追蹤過程，本篇文章就是在這樣的觀點下而生的~~~
AppCenter 除了很多好處之外，更是一個讓 App 在佈版上更為方便的平台。若是在開發團隊能導入使用的話，就能讓開發好的 App 在要佈署給測試人員時能更加的便捷。
本篇就來看看 AppCenter 在開發端這邊針對 Android 的環境設定，要如何做最基本的自動建置與更版，快速地讓測試人員取得新版本的測試 App 吧~~~
AppCenter 除了很多好處之外，更是一個讓 App 在佈版上更為方便的平台。若是在開發團隊能導入使用的話，就能讓 App 要佈署給測試人員時更加的便捷。
本篇就來看看 AppCenter 在 Android 的測試人員這方面，如何做基本的接受邀請，快速地進行測試 App 的取得部分吧~~~
因為在測試使用 Microsoft EM + S 的 E5 試用時，要測試 Office 365 中的 Excahange Online 功能，這才發現 Microsoft EM + S 的 E5 授權不包含其相關功能...冏
難怪怎麼在 Outlook App 當中登入帳號都無法連線到 Exchange Online 呢(菸~~~
後來再認真的看了看相關的授權，如果選擇 Office 365 的 E1、E3 或 E5 授權，又或者選擇使用 Microsoft 365 的 E3 或 E5 授權，跟原本已啟用 Microsoft EM + S 的 E5 授權有 Office 365 服務的功能重複。