使用 android device 時，遇到 "若要建立此專案，必須安裝下列工作負載: maccatalyst" 這個錯誤



In Terminal, install the latest public build of .NET MAUI:

dotnet workload install maui --source https://api.nuget.org/v3/index.json

dotnet workload install android

安裝後要重新啟動 Visual Studio

這篇文章中的回答提到 https://ithelp.ithome.com.tw/questions/10209520

多核使用時CPU的運作頻率會被限制，因此當使用多執行續進行大資料量處理時(先不考慮硬碟速度)對每個CPU核心的效率會下降，因此為了進行多核處理進行資料分割的成本考量會有不小的影響。

 

從github抓取應用程式
https://github.com/g13579112000/ShopeeApiV2

--建立 table (要記得改 XXX)
CREATE TABLE IF NOT EXISTS public.table_monitor
(
    table_name text COLLATE pg_catalog."default" NOT NULL,
    update_at timestamp without time zone NOT NULL DEFAULT now(),
    update_count bigint NOT NULL DEFAULT 0,
    CONSTRAINT table_monitor_pkey PRIMARY KEY (table_name)
)

TABLESPACE pg_default;

ALTER TABLE IF EXISTS public.table_monitor
    OWNER to XXX;

-- 這一段只要執行一次
CREATE OR REPLACE FUNCTION public.table_monitor_trigger_fnc()
    RETURNS trigger
    LANGUAGE 'plpgsql'
    COST 100
    VOLATILE NOT LEAKPROOF
AS $BODY$
BEGIN
     Update public.table_monitor Set update_count = update_count + 1, update_at = now()  Where table_name = TG_TABLE_NAME; 
RETURN NEW;
END;
$BODY$;

ALTER FUNCTION public.table_monitor_trigger_fnc()
    OWNER TO XXX;

-- 對於被監控的 table, 要執行以下的指令，記得 monitor_table_name 要改為 table 的名字(要符合大小寫)
INSERT INTO public.table_monitor (table_name, update_at, update_count) VALUES ('monitor_table_name', '2000-01-01', 0) ON CONFLICT DO NOTHING;

CREATE OR REPLACE TRIGGER table_monitor_trigger
    AFTER INSERT OR DELETE OR UPDATE 
    ON monitor_table_name
    FOR EACH STATEMENT
    EXECUTE FUNCTION public.table_monitor_trigger_fnc();

監控用的程式碼:

public static void UpdateTableCache()

{

    //標記自已是正在執行的 Thread. 讓舊的 Thread 在執行完畢之後, 應該會自動結束. 以防舊的 Thread 執行超過 10 秒.

    CurrentThreadId = System.Threading.Thread.CurrentThread.ManagedThreadId;



    try

    {

        //確認自已是正在執行的 Thread, 重覆執行. (另一個 Thread 插入執行)

        while (CurrentThreadId == System.Threading.Thread.CurrentThread.ManagedThreadId)

        {

            LastUpdateDate = DateTime.Now;



            foreach (var dbId in CachedDbs)

            {

                var sql = @"select * from table_monitor";



                var dt = Su.PgSql.DtFromSql(sql, dbId);



                foreach (DataRow row in dt.Rows)

                {

                    string changeId = row["update_count"].DBNullToDefault();

                    string CacheKey = TableCacheKey(dbId, row["table_name"].DBNullToDefault());

                    ObjectCache cache = MemoryCache.Default;



                    string OldValue = (string)cache[CacheKey];



                    if (OldValue == null)

                    {

                        cache.Set(CacheKey, changeId, DateTime.MaxValue);

                    }

                    else

                    {

                        if (changeId != OldValue)

                        {

                            cache.Remove(CacheKey);

                            cache.Set(CacheKey, changeId, DateTime.MaxValue);

                        }

                    }

                }

            }



            //每兩秒檢查一次

            System.Threading.Thread.Sleep(2000);

        }

    }

    catch (Exception)

    {

        //依經驗, 只要 DB 能通, 這裡幾乎不會有問題, 所以這裡暫時不處理, 未來有問題時可以考慮寫入文字檔比較好.

    }

}

比較方式: 對相同的資料表讀取 1000 次，來比較速度。
資料庫為 MS SQL

這裡做了 4 個 Case:

Case 1: 
使用 Entity Framework，DbContext 為每次 new 一個。

Case 2:
使用 Entity Framework，使用同一個 DbContext。

Case 3:
用 DAO，轉為 Data Table 的格式 (使用 DtFromSql)。

Case 4:
使用 Dapper。

專案啟動時的記憶體使用量約為:  123 MB



測試一:
第一次讀取
Case 1, 時間: 3673.0303 ms, 記憶體: 566 MB

Case 2, 時間:  3889.9379 ms, 記憶體: 304 MB  (這個時間有時會測試到 3000 ms)

Case 3, 時間:  1665.7748 ms, 記憶體: 205 MB

Case 4, 時間:  1639.7211 ms, 記憶體: 193 MB

讀取五次
Case 1, 時間: 1984.6395, 記憶體: 544MB (有發生 GC)


Case 2, 時間:  2367.9792 ms, 記憶體: 627 MB (沒有發生 GC)


Case 3, 時間:  1395.1132 ms, 記憶體: 280 MB (有發生 GC)



Case 4, 時間:  1531.3555 ms, 記憶體: 271 MB


結果: Dapper 看來完勝，速度上和直接使用 DAO 轉進 Data Table 的速度相近。但 Dapper 傳回的結果已經轉換為物件 List， 操作上會更為方便。

Entity Framework 一如預期的較慢，且花費較多的記憶體。但和想像中最大的差異是，使用同一個 DbContext 比 new 1000 個 DbContext  的速度還要慢， 花費的記憶體在 GC 之後，差異不大。

所以不一定要用 DI 注入 DbContext, 在各 function 中一直傳遞 DbContext. 在 Static 的 function 中，可以安心的 new 一個 DbContext 出來使用吧，只是要記得用 using 哦，否則可能會有 connection 沒有關閉的問題。


 

 
於VS Web中建立虛擬目錄，導致Swagger Handler出現重複錯誤
主要原因是因為跟網站與子網站指向同一個資料夾，而父子網站的web.config有繼承關係導致。

解決方式:
1. 前往 根目錄 / .vs / 專案 / config / applicationhost.config

2. 將site中設定的子網站移除或變更虛擬目錄位置

 
3. 回到網頁重新整理就完成囉!

參考: 【茶包射手日記】怪異的web.config HttpHandler重複錯誤

直接對 Action 參數傳入 IFormFile 物件會變成 Json 物件，要包在物件中才會正常 出現一個 file upload 如下圖












 

為了遏止垃圾郵件以及釣魚郵件，SPAM組織有定義一些規則，這些規則主要是經由 DNS 反查相關設定，看郵件來源是不是沒有問題。其中一個就是 SPF 設定。
SPF 設定(txt)我這邊就不多說，網路上很多資源有相關介紹，基本上 他的設定就會像是 
"v=spf1 include:_spf.mx.cloudflare.net ~all"
中間 include: 就是寄件來源的 domain， include 也可以設定多筆，
也可以設定 ip4 格式或是 mx 所以他可能會長得像這樣
"v=spf1 include:_spf.emfwd.name-services.com include:amazonses.com ip4:112.121.xxx.0/24 ?all"
最後的 all 前面用 ? - ~ 都有他的意義，請參考網路上的資源
在這裡不管是 include 或是 ip4 設定，都是寄件者的IP來源白名單。

其工作原理大致是
1.  郵件伺服器收到一封email後，抓出寄件者的 email domain
2.  由 email domain 去 DNS 檢查 spf 設定，若有，就從裡面IP來源白名單，比對寄信來源的伺服器IP是不是在白名單
3.  若不是白名單，郵件伺服器可能直接拒收(收件者完全找不到新件)，或是列入垃圾郵件
---------------------------------------------------------

對於我們公司的客戶而言，若他的網站通知信不是經由 aws ses寄送
是經由我們公司建立的 smtp 寄送，其實是可以請他們去 DNS 做一下設定
而且最好建議寄件者是使用子網域，避免跟 root 網域的 email 設定有衝突
例如  service@ec.examplesite.com.tw
這樣就可以請客戶去 DNS ec.example.com.tw 設定 spf txt
"v=spf1 ip4:112.121.xxx.0/24 ?all"
這樣就可以減少email變成垃圾郵件的狀況
不過以上僅限在 "通知信"範疇

如果客戶要大量寄送 EDM，還是要請他們是用外部資源， aws ses 或是 mail trimp, 電子豹
不要使用內建的 SMTP 主機，因為同一IP同時發送大量郵件，也會被 SPAM 組織列為黑名單

 

*分解元組(Deconstructing tuples)的支援必須要至少C# 7.0以上*

以前一個funtion如果需要回傳複數個參數你會怎麼做呢?

1.可能會定義一個物件，在回傳的時候宣告並將值塞進去return。(為了一個function而去定義，好醜...)
2.又或者是將回傳參數型別直接改成dynamic，回傳時直接使用匿名物件。(performance炸裂!!!)

如果你使用了上面兩種方式...請一定!一定!!一定!!!要把這篇文章看完。

先來說說在C#7.0以前的處理方法，在呼叫function之前先將欲接收的參數宣告好並傳入。



但是這樣做有幾個缺點，
1. 當傳入的參數與傳出的參數一多起來，function定義時的參數會又臭又長。
2. 使用這個function前每次都需要宣告變數，不累嗎?
3. 不管你要不要使用這個參數，你都一定要傳入，因為ref與out不能有預設值。

接下來...讓我與各位介紹 " 元 組 元 素 "!!! (Tuple)

早上好台灣，現在我有Tuple。我很喜歡Tuple，但是速度與激情9比...咳咳...沒事。

先來個簡單的範例

定義一個funciton JohnCena

然後我們就可以很漂亮的一次性取得JohnCena的姓名、出生日期、國籍、年齡等等資料!

 
假如你的參數需要在外面先行宣告也沒問題!



而從C#10開始，甚至可以混合使用也沒關係!



這樣我們就輕鬆解決了以前的兩個缺點了，而要解決最後一個缺點更是簡單，
只需要將你想要丟棄(discard)或是用不到的那個參數使用UnderLine( _ )就可以囉!



元組元素的基礎講完了再來說說解構元素的部分
建構式想必大家都已經很熟悉了



但是'分解式'你有聽過嗎?
顧名思義就是可以定義物件被指派出去的參數!
驚不驚喜! 意不意外?

使用的方法就是在class底下新增一個Deconstruct function



如此一來我們就可以來試試看將John Cena解ㄊ一.... 分解!



建構式可以多載，分解式當然也可以!



以上就是這次的內容，有沒有覺得Coding時的可玩性又更好了呢?
不過要提醒一點，目前解構式並無法使用查看定義來移置相對應的位置，
對於可讀性會有不小的影響，但如果你想要把某個東西藏起來不讓你同事找到... (請不要這樣做!)
這次的範例也歡迎到我的GitHub參考囉!

06/09/2022   由Bike 補充
 
可以將function的回傳參數先行命名!!
直接當成物件使用，對開發效率與可讀性有著明顯的提升，相信會是未來的趨勢。

另外要道歉並修正之前將Deconstruct翻譯成解構式的錯誤
Destruct (解構式)指的是class生命周期結束前執行的function
使用方式是class名稱為dunction名稱並在前面加上波浪符號 '~'
Deconstruct的翻譯應該為分解式

我們的目標是在啟動時，掛一個 global filter 來檢查上傳的檔案附檔名，避免上傳未預期的可執行檔。使用 global filter 可以防止程式設計師忘了做檔案檢查，發生危險。我們目前用到的 .Net Framework 有兩個類別，一個是 System.Web.Http.ApiController，另一個是 System.Web.Mvc.Controller，兩個要分開處理。

1. Web API (System.Web.Http.ApiController)
.Net Framework 的 Web API 2 在接收檔案時，必需使用 Request.Content.ReadAsMultipartAsync 把上傳的資料存入 MultipartMemoryStreamProvider 之後再來處理。
範例如下: 

    public class UploadController : ApiController

    {

        public async Task<object> PostFormData()

        {

            var provider = new MultipartMemoryStreamProvider();



            if (! Request.Content.IsMimeMultipartContent())

            {

                return "no file";

            }



            //要注意這裡的 await

            await Request.Content.ReadAsMultipartAsync(provider);



            foreach (var content in provider.Contents)

            {

                if (content.Headers.ContentDisposition.FileName != null)

                {

                    string localFilename = content.Headers.ContentDisposition.FileName.Replace("\"", "");

                    System.IO.Directory.CreateDirectory(HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/"));

                    string filename = HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/" + localFilename);

                    if (System.IO.File.Exists(filename))

                    {

                        System.IO.File.Delete(filename);

                    }



                    using (var fileStream = new FileStream(filename, FileMode.Create, FileAccess.Write))

                    {

                        var contentStream = await content.ReadAsStreamAsync();

                        await contentStream.CopyToAsync(fileStream);

                        Trace.WriteLine("Save To" + filename);

                    }

                }

            }

            return "OK";

        }

    }

程式碼中有個地方我沒有注意到。我一開始是用 Request.Content.ReadAsMultipartAsync(provider); 把資料讀進 provider，但前方沒有加上 await，造成有時讀不到檔案的情況，再次提醒自己 Async 和 Await 的關係。

直覺的想法是在 filter 中執行一樣的程式碼，不存檔，只要抓出檔名來檢查即可。但這時遇到一個問題 Request.Content.ReadAsMultipartAsync 不能執行兩次，Google 了一陣子，也沒找不到類似 seek(0) 的操作。所以只好自己寫一個暫存的機製。

這裡決定使用 System.Web.HttpContext.Current.Items 來暫存 provider，最後的 OnActionExecutingAsync 結果如下:

        /// <summary>

        /// 檔案檢查

        /// </summary>

        /// <param name="actionContext"></param>

        /// <param name="cancellationToken"></param>

        /// <returns></returns>

        public override async Task OnActionExecutingAsync(HttpActionContext actionContext, CancellationToken cancellationToken)

        {

            Trace.WriteLine("ApiCheckFile OnActionExecutingAsync");



            var request = actionContext.Request;

            if (!request.Content.IsMimeMultipartContent())

            {

                return;

            }



            var provider = new MultipartMemoryStreamProvider();

            await request.Content.ReadAsMultipartAsync(provider);



            //把 provider 存入 System.Web.HttpContext.Current.Items 之中，以便在 controller 中再度使用

            System.Web.HttpContext.Current.Items["MimeMultipartContentProvider"] = provider;



            foreach (var content in provider.Contents)

            {

                if (content.Headers.ContentDisposition.FileName != null)

                {

                    var filename = content.Headers.ContentDisposition.FileName.Replace("\"", "");

                    Trace.WriteLine(filename);



                    var ext = System.IO.Path.GetExtension(filename);

                    if (!".jpg,.jpeg,.png".Contains(ext.ToLower()))

                    {

                        throw new Exception("file format error.");

                    }

                }

            }



            return;

        }

而 controller 中的 Action 則改為以下的版本；本版本中，除了把上傳的檔案存檔以外，還有讀取 form data 中其它欄位的範例:

        public async Task<object> PostFormData()

        {

            //改由 HttpContext.Current.Items 中，讀取資料。

            MultipartMemoryStreamProvider provider = (MultipartMemoryStreamProvider)System.Web.HttpContext.Current.Items["MimeMultipartContentProvider"];



            //如果沒有經過 filter，provider會是 null, 這時就要直接由 Request.Content 讀入 provider

            if (provider == null)

            {

                provider = new MultipartMemoryStreamProvider();

                Request.Content.ReadAsMultipartAsync(provider);

            }



            foreach (var content in provider.Contents)

            {

                if (content.Headers.ContentDisposition.FileName != null)

                {

                    string localFilename = content.Headers.ContentDisposition.FileName.Replace("\"", "");

                    Trace.WriteLine("FileName: " + localFilename);

                    Trace.WriteLine("FileName: " + @"~/App_Data/Temp/" + localFilename);

                    System.IO.Directory.CreateDirectory(HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/"));

                    string filename = HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/" + localFilename);

                    if (System.IO.File.Exists(filename))

                    {

                        System.IO.File.Delete(filename);

                    }



                    using (var fileStream = new FileStream(filename, FileMode.Create, FileAccess.Write))

                    {

                        var contentStream = await content.ReadAsStreamAsync();

                        await contentStream.CopyToAsync(fileStream);

                        Trace.WriteLine("Save To" + filename);

                    }

                }

                else

                {

                    var contentStream = await content.ReadAsStreamAsync();

                    var reader = new System.IO.StreamReader(contentStream);

                    var data = reader.ReadToEnd();

                    Trace.WriteLine("data: " + data);

                }

            }

            return "OK";

        }

以上是展示 Web Api 的 Filter。

如果是 MVC 的 Controller，就簡單多了，直接讀取 actionContext.HttpContext.Request.Files 裡面各檔案的 FileName 即可。不過也遇到了一個和直覺不同的地方，對 actionContext.HttpContext.Request.Files 居然不能用 foreach 請見下方註解掉的地方。也許是我的用法有問題，如果有人找到可以使用的方法也麻煩告知。

        public override void OnActionExecuting(ActionExecutingContext actionContext)

        {

            Debug.WriteLine("MvcCheckFileFilter OnActionExecuting");

            if (actionContext.HttpContext.Request.Files.Count > 0)

            {

                for (int i = 0; i < actionContext.HttpContext.Request.Files.Count; i++)

                {

                    System.Web.HttpPostedFileBase file = actionContext.HttpContext.Request.Files[i];

                    if (System.IO.Path.GetExtension(file.FileName) != ".jpg")

                    {

                        throw new Exception("file format error.");

                    }

                    Debug.WriteLine(i + "MvcCheckFileFilter OnActionExecuting File type: " + file.FileName.ToString());

                }

            }



            //以下寫法會發生錯誤: 無法將類型 'System.String' 的物件轉換為類型 'System.Web.HttpPostedFileBase'。

            //foreach (HttpPostedFileBase file in actionContext.HttpContext.Request.Files)

            //{

            //    if (System.IO.Path.GetExtension(file.FileName) != ".jpg")

            //    {

            //        throw new Exception("file format error.");

            //    }

            //}

        }

最後是把 filter 掛在 global filter 裡，如下:
Web API Controller 的部份:
在 WebApiConfig.cs 裡加上 config.Filters.Add(new ApiCheckFile()); 見下圖:
 

附帶一提，Register 是在 global.asax 裡被叫用的。微軟的架構常常這樣，硬是拉到另一個目錄的獨立檔案裡，如果 global.asax 沒有這一行，不知所以的人，在 App_Start 裡，建立了一個 WebApiConfig.cs 然後會發現完全沒做用... 見下圖

 
MVC Controller 的部份，
在 FilterConfig.cs 中，加上 filters.Add(new MvcCheckFileFilter()); 如下圖
 

一樣是在 global.asax 中呼叫  FilterConfig.RegisterGlobalFilters，見下圖:

 
不過有趣的地方是，在 global.asax 裡, WebApiConfig.Register 和 FilterConfig.RegisterGlobalFilters 的叫用方法不同，一個是把 function 當作變數，一個是直接呼叫 function, 大家可以比較一下。

附註 1, 關於 OnActionExecutingAsync 和 OnActionExecuting:

Web API 的 filter 中，提供了 OnActionExecutingAsync 和 OnActionExecuting 兩個 method 可以 override ，我實驗的結果是如果兩個 method 都 override 了，只有 OnActionExecutingAsync 會被呼叫。

MVC 的 filter 中，只有 OnActionExecuting 可以 override。