程式碼大概是這樣的…

public string Extract(Stream stream)
{
    var Arg = $"-jar {TikaPath} -t --encoding=UTF-16 -";

    //run Tika

    var p = new Process();
    p.StartInfo.FileName = JavaPath;
    p.StartInfo.Arguments = Arg;
    p.StartInfo.CreateNoWindow = true;
    p.StartInfo.UseShellExecute = false;
    p.StartInfo.RedirectStandardInput = true;
    p.StartInfo.RedirectStandardOutput = true;
    p.Start();

    var stdin = p.StandardInput.BaseStream;
    stream.CopyTo(stdin);
    stdin.Close();

    var output = p.StandardOutput.ReadToEnd();
    p.WaitForExit();

    return output;
}

從別的地方讀取了檔案之後呼叫了這個方法，傳入了一個Stream，透過Stream.CopyTo的方式將傳入的內容複製到Tika的StandardInput，用ConsoleApp很簡單的弄了一個測試，逐步執行的時候會發現就卡在Stream.CopyTo這個地方，但是如果是pdf檔案就可以順利執行。

Stream.CopyTo有一個非同步的方法是CopyToAsync，稍微試了一下就算用了CancellationToken嘗試在超過時間要取消操作，實際上仍然是沒辦法中止卡在這個地方的情況。而且這樣根本也不知其所以然，到底為什麼卡住還是不知道原因。

OK，既然是卡在這個Stream複製的地方，而且不同的檔案(txt vs pdf)在相同的程式碼是不同的結果，pdf可以正常執行，txt卻不行，那就是txt檔案的內容在輸入StandardInput的時候發生了問題。

想要知道發生什麼問題，過程中還試了StandardError，要看看是不是發生什麼錯誤輸出了錯誤訊息到這裡面，不過從內容中去找尋線索未果，不過在官方文件上看到有可能發生死結的情況，不知道為何卻想到試著改用內容較少的txt檔案，在同樣的程式碼運行卻可以正常。

最終在多個不同的假設測試下，發現會卡住的原因是txt檔案太大，內容過多的情況下會卡在Stream.CopyTo這個環節，所以判斷可能是在複製到StandardInput的過程中也會將處理的結果輸出到StandardOutput，但是StandardOutput一直收收收，收到緩衝區滿了沒處理，CopyTo這裡傳給Tika，Tika說「你等等，我在等Output處理」，我們的程式是在後面才呼叫StandardOutput.ReadToEnd，所以在Stream.CopyTo的這裡一直等Tika接收完內容，最終形成了死結…

處理這個問題不困難，除了StandardOutput.ReadToEnd這個方式處理內容之外，它還有個非同步的處理方式，在前面先建立一個StringBuilder來接收內容，最後再改成從StringBuilder取得所有內容，結果就是相同的。最後修改後的程式碼如下：

public string Extract(Stream stream) 
{
    var Arg = $"-jar {TikaPath} -t --encoding=UTF-16 -";

    //run Tika

    StringBuilder output = new StringBuilder();

    var p = new Process();
    p.StartInfo.FileName = JavaPath;
    p.StartInfo.Arguments = Arg;
    p.StartInfo.CreateNoWindow = true;
    p.StartInfo.UseShellExecute = false;
    p.StartInfo.RedirectStandardInput = true;
    p.StartInfo.RedirectStandardOutput = true;

    p.StartInfo.StandardOutputEncoding = Encoding.BigEndianUnicode;
    p.OutputDataReceived += new DataReceivedEventHandler((s, e) => output.AppendLine(e.Data));

    p.Start();
    p.BeginOutputReadLine();

    var stdin = p.StandardInput.BaseStream;
    stream.CopyTo(stdin);
    stdin.Close();

    p.WaitForExit();

    return output.ToString();
}

修改後的內容改用OutputDataReceived事件處理每次收到的Output內容放入StringBuilder，只是這邊有個地方要特別注意，那就是StandardOutput的Encoding要特別設定，不然結果會和使用StandardOutput.ReadToEnd的內容不同(編碼不同)。

參考資訊：

• https://docs.microsoft.com/zh-tw/dotnet/api/system.diagnostics.process.standarderror
• https://docs.microsoft.com/zh-tw/dotnet/api/system.diagnostics.process.standardinput
• https://stackoverflow.com/questions/26384772/deadlock-while-writing-to-process-standardinput
• https://stackoverflow.com/questions/36918007/beginoutputreadline-and-encoding
• https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
• https://blog.darkthread.net/blog/977/

這篇文章 C#透過Process的StandardInput輸入Stream時卡住的可能問題 最早出現於 泰克哪裡去。

Request body too large

Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Request body too large.
at Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw(RequestRejectionReason reason)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1ContentLengthMessageBody.OnReadStarting()
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.TryStart()
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.ConsumeAsync()
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication1 application) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication1 application)

通常不會把每一個設定值都記在腦中，所以就搜尋了一下Kestrel Server的設定應該在appsettings.json檔案中如何調整，查到了設定MaxRequestBodySize的C#程式碼，但是翻了很多篇網路上的文章都沒有找到如何在設定檔裡面調整的方法…

從官方文件和一些文章中看到下面的json設定內容，所以推斷應該同樣在Limits底下加上MaxRequestBodySize和設定值就可以搞定，結果實際上試了之後發現竟然完全沒效…，雖然是有看到有些設定在Server啟動之後會變成唯讀的情況，之後修改的內容不會更新，不過我一直覺得加在appsettings.json裡面不就是在啟動的時候會載入的設定？

{
  "Kestrel": {
    "Limits": {
      "MaxConcurrentConnections": 100,
      "MaxConcurrentUpgradedConnections": 100
    },
    "DisableStringReuse": true
  }
}

從這裡的文件內容則是看到下面這麼一段話…，因為Limits的設定是在KestrelServerOptions底下，所以我一直認為應該是可以透過appsettings.json設定，無奈試了幾次之後都沒辦法正常，所以最後只好妥協認命的去改Code…

Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerOptions and endpoint configuration are configurable from configuration providers. Set other Kestrel configuration in C# code.

其實程式碼也不難，作法是在KestrelServerOptions的Limit底下的MaxRequestBodySize設定大小，因為是nullable型態，所以也可以設定為null。

第一段的是官方文件中的程式碼，第二段則是我寫在ConsoleApp(Program.cs)裡的程式碼，在UseKestrel的Extension method中設定。
因為是跑在Container裡面的程式，在改Code之前已經在shell script中判斷是否有MAX_REQ_BODY_SIZE這個環境變數來調整appsettings.json的檔案內容，所以是透過判斷是否有MAX_REQ_BODY_SIZE這個環境變數來設定大小，如果沒有找到MAX_REQ_BODY_SIZE就設定100MB的預設值，比官方預設不到30MB的大小再大一些。

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxRequestBodySize = 100_000_000;
});

public static IHostBuilder CreateHostBuilder(string[] args)
{
    return Host.CreateDefaultBuilder(args)
               .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseKestrel(opt =>
                        {
                            long maxReqBodySize = 100 * 1024 * 1024;
                            if (Environment.GetEnvironmentVariable("MAX_REQ_BODY_SIZE") != null)
                            {
                                long.TryParse(Environment.GetEnvironmentVariable("MAX_REQ_BODY_SIZE"), out maxReqBodySize);
                            }
                            opt.Limits.MaxRequestBodySize = maxReqBodySize;
                        })
                        .UseStartup<Startup>();
                });
}

結果最後繞一圈多花了一天的時間還是乖乖的改了程式碼…

對了，上面這樣的作法是整個網站都設定相同大小的限制，或許會有一些其它額外的潛在風險，所以官方建議的作法是只在需要調整的Function加上RequestSizeLimit Attribute。

參考資訊：

• The Code Blogger – Certificates and Limits for ASP .NET Core Kestrel Web Server
• AspNetCore.Docs/options.md at main · dotnet/AspNetCore.Docs · GitHub
• Upload files in ASP.NET Core | Microsoft Docs
• How to increase file upload size in ASP.NET Core (talkingdotnet.com)
• Set MaxRequestLength in ASP.Net Core (aspsnippets.com)
• Increase ASP.NET File Upload Limits | Khalid Abuhakmeh
• New default 30 MB (~28.6 MiB) max request body size limit · Issue #267 · aspnet/Announcements · GitHub
• c# – Increase upload file size in Asp.Net core – Stack Overflow
• Configure options for the ASP.NET Core Kestrel web server | Microsoft Docs
• asp.net core – Increase upload request length limit in Kestrel – Stack Overflow

這篇文章 Asp.Net Core Kestrel設定Request Body Size 最早出現於 泰克哪裡去。

如果要關閉上面這些Request Info記錄的顯示，在appsettings.json檔案中加上Logging的記錄就可以了，參考下面的這段設定內容：

"Logging": {
    "LogLevel": {
      "Default": "Error",
      "Microsoft.Hosting": "Warning"
    }
  }

加到appsettings.json檔案之後重新啟動程式再試試，頁面正常顯示卻不會有這些Request Info洗版了。

參考資訊：

https://docs.microsoft.com/zh-tw/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0#configure-logging

這篇文章 Asp.Net Core Kestrel Server關閉Request Info記錄 最早出現於 泰克哪裡去。

首先，有個2021ironman的Solution方案檔，裡面有3個C#專案，分別是ConsoleApp、ModuleA、ModuleBase：

ModuleBase中只有一個IModuleInfo.cs，程式碼如下：

using System;
using System.Collections.Generic;
using System.Text;

namespace ModuleBase
{
    public interface IModuleInfo
    {
        public string Name { get; }
        public string Description { get; }

        void EntryPoint();
    }
}

ModuleA裡面只有一個Startup.cs，程式碼如下：

using System;

namespace ModuleA
{
    public class Startup : ModuleBase.IModuleInfo
    {
        public string Name => "ModuleA";
        public string Description => "ModuleA is a test module.";

        public void EntryPoint()
        {
            Console.WriteLine("Hello world, this is ModuleA.");
        }
    }
}

接著是ConsoleApp的Program.cs，程式碼如下：

using System;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Collections.Generic;
using System.Runtime.Loader;
using ModuleBase;

namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            DirectoryInfo modulesDir = new DirectoryInfo("modules");
            Console.WriteLine("Hello World! This is Console app.");

            if (modulesDir.Exists)
            {
                var dlls = modulesDir.GetFiles("*.dll", SearchOption.AllDirectories);
                List<Assembly> assemblies = new List<Assembly>();

                foreach (var dll in dlls)
                {
                    var assembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(dll.FullName);

                    foreach (var type in assembly.GetTypes())
                    {
                        if (typeof(IModuleInfo).IsAssignableFrom(type) && !type.IsInterface)
                        {
                            IModuleInfo moduleInfo = Activator.CreateInstance(type) as IModuleInfo;
                            Console.WriteLine($"Load {moduleInfo.Name}, {moduleInfo.Description}.");
                            moduleInfo.EntryPoint();
                        }
                    }
                }
            }

            Console.ReadLine();
        }
    }
}

ModuleBase這個Class Library作為定義Module的基礎，雖然目前只有ModuleA，但是之後的ModuleB、ModuleC都要以ModuleBase為基底，所以ModuleBase會在後續用來製作成nuget package，在Azure DevOps中建立私有的nuget套件庫。

ModuleA實作ModuleBase中所定義的介面，如上面所說，之後會有ModuleB、ModuleC，如果每一個Module都替它們建立一個專屬的Pipeline，那數量會很可觀，所以之後建立的Pipeline中，會有一個是設計成可以讓使用者來告訴Pipeline應該要選擇哪一個來建置(Build)。

ConsoleApp的部份則是扮演主程式的角色，這裡也只是把Module的dll載入之後執行輸出結果而已，暫時沒有特別的用途。

初期就先以上面這些東西來準備接下來的Pipeline範例，下一篇我們就要實際來建立Pipeline了。

這篇文章 【2021鐵人賽】CI/CD從這裡：開始之前的準備(範例介紹) 最早出現於 泰克哪裡去。

不過問題是，如果資料庫和資料表是第一次剛建立的，使用這個指令會讓Id欄位一開始的編號是0，期望的初始編號是1，但是在之後刪除資料並且使用上面的指令後，再新增資料的初始編號就會從1開始，符合期望的數字。

這個問題我試了一下，發現如果是資料庫與資料表剛建立的時候，若是執行DBCC CHECKIDENT (‘TableName’, NORESEED)會取得NULL，但是新增資料的時候Id會是1(沒有執行ReSeed的情況下)，這部份感覺上應該是資料庫有自行處理這一個部份，所以若是在一開始執行ReSeed，反而是讓資料庫不處理NULL到1的部份，新增資料時的Id就變成是0。

原本建議同事在執行完單元測試的時候刪除資料時再做ReSeed的動作，不過他說有時候想要在新增資料後看看資料庫的內容，所以不想要立即刪除資料，因此詢問如何在執行單元測試之前判斷資料庫或資料表是否剛建立？

針對這個問題，我回到如何得知資料庫內的種子遞增值的方向來思考，如何在執行ReSeed之前取得目前的值，判斷是否為NULL再來針對接下來執行相對應的動作。

簡單查了一下，可以利用IDENT_CURRENT( ‘table_or_view’ )這個語法來得知目前資料表的遞增值，透過Select IDENT_CURRENT( ‘table_or_view’ ) As Seed來取得，後面的As Seed部份是將取得的值放在名為Seed名稱的欄位，沒有這一段也沒關係，只是沒有欄位名稱。

從微軟的文件庫中還有看到IDENT_SEED ( ‘table_or_view’ )這個指令，是用來查詢最初設定欄位的遞增值，因為有時候可能會設定自動遞增的欄位不是從1開始，這時候就可以利用這個函數來查詢初始的設定，回傳的結果並不會受到DBCC CHECKIDENT重設的影響，也許以後會用到。

2020/05/27 Update:

後來同事告知使用Select IDENT_CURRENT( ‘table_or_view’ ) As Seed的方式仍然會有問題，也就是說當資料表剛被建立，尚未新增資料的時候，IDENT_CURRENT函數取得的是1，新增多筆資料刪除之後再ReSeed設0，IDENT_CURRENT函數取得也會是1。

因為當資料表剛被建立尚未新增資料前，若是使用DBCC CHECKIDENT來ReSeed設0，第一筆資料新增的時候會直接使用ReSeed時給定的初始值(也就是0)。但是若資料表有新增過資料再刪除，重新ReSeed為0的時候，作法變成是給定的初始值+1，從上面的例子ReSeed為0的情況再+1就變成1，所以兩個情況都會取得1。

至於上次為何我會取到NULL值，應該是我當時在測試的時候沒有留意，執行IDENT_CURRENT函數的時候是在資料表尚未建立的時候(不存在的TableName)，所以取得的結果是NULL。

印象中上次在查詢資料的時候有看到另外的解法，就是去撈取系統資料表中的記錄，只是語法麻煩了一點，這次再把它找出來試了一下，並且留意資料表建立前後的問題，結果是可行的，語法如下：

IF EXISTS (SELECT * FROM sys.identity_columns WHERE OBJECT_NAME(OBJECT_ID) = ‘TableName‘ AND last_value IS NOT NULL)
DBCC CheckIdent(‘TableName‘, ReSeed, 0);
Else
Print(‘no need reseed’)

參考來源：

• IDENT_CURRENT (Transact-SQL)
• DBCC CHECKIDENT Sets Identity to 0

這篇文章 單元測試與資料表自動遞增Id的問題 最早出現於 泰克哪裡去。