對於一個相對長期大多是使用 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 服務的功能重複。
在這兩篇文章當中有
一個必要條件:
兩個網址要使用:
三個觀念要知道:
以上都捧友都清楚的話，即可繼續閱讀本文...
在這兩篇文章當中有
一個必要條件:
兩個網址要使用:
三個觀念要知道:
以上都捧友都清楚的話，即可繼續閱讀本文...
若網站是 Host 在 Azure 的 PaaS 服務的 App Service 中，要綁定所指定網域到該 "App Service" 的 "Web 應用程式" ，可透由本篇文章所記錄之步驟完成。
要繼續閱讀本文並完成的必要條件:
還有已閱畢 "替 Azure 的 App Service 網站設定自訂網域後掛上 SSL 憑證 (上)" 的內容，那就可以繼續了，Go!
現在網站不掛上 SSL 憑證作網路加密安全性連線的話，那你的網站只會被檯面上列的出來科技龍頭們(如: Microsoft, Google, Apple, Amazon...等)排擠。
原因很簡單，因為沒有掛上 SSL 憑證替網站作加密安全性連線，那對使用該網站的用戶們來相對來說就是屬於高風險網站，為了保護用戶的資料安全性，替網站掛上 SSL 憑證作加密連線是網站自身一件責無旁貸的事。
但對於一些小企業主或小規模網站來說，要買 SSL 憑證掛到網站上做加密連線確實是一筆不小的花費，如果每年真的擠不出這樣的預算購買憑證，是可以考慮使用 Let's Encrypt SSL 等服務，佛心提供的 SSL 憑證方式來處理。
而若網站又剛好有 Host 在 Azure 的 App Service 上的話...