Marge fix MeCab.DotNet to NMeCab (Issue #32)

[kekyo]

@komutan ベースとなるPRを見ました。表面的な部分はOKと思います。少し手直ししたのがこのPRです。

• Linux上でRiderでビルド出来るようにしておきました
• RelaxVersionerの1.xは古いので2.xに移行しました（これでLinux環境でもビルドできます）
• WindowsFormsSampleはMeCabTaggerの廃止があるのでどうしようかと思いましたが、とりあえずビルドできるように修正しました。一通り終わったら、Avalonia辺りに移植しても良いかもと思っています。

---

ターゲットのバージョン（net45やnetstandard2.0、tfmと呼びます）ですが、出来れば絞り込みたいのはヤマヤマなのですが、以下のような経験があります:

• netstandard系列は、.NET Frameworkと.NET Core系列(.NET 5含む) のどちらにも使える。特にnetstandard2.0はnet461とnetcoreapp2.0以降に対応するので、これだけで殆どをカバーできるので、ライブラリはnetstandard2.0で作るのが良さそう
• 一方で:
  • .NET Framework 4.6.1はCLR4.5だけど.NET Framework 4.5ではなく、CLR4.5のベースバージョンと整合しない（CLR4.5で行けるならnet45にしたい、CLR4.0で行けるならnet40にしたい、のような）
  • netstandard2.0のライブラリをnet461以上のプロジェクトで使う場合に、netstandard.dll (2.0)が必要になり、これに引きずられて、本当に必要なのか一見してわからない大量のアセンブリが配置されてしまう
  • MeCabと関係のない、別のライブラリを一緒に使う時（例えばJsonを扱うライブラリなど）、完全に整合するtfmで無い限り、互換性のあるtfmが計算されて選択されますが、この候補が複数ある場合に、望まない選択をしてしまうことがある（しかも現状回避できない）。例えば、NMeCabがnet46/netstandard2.0で、net48プロジェクトで使用すると、netstandard2.0が選択されてしまい、配置されるアセンブリが物凄く多くなってしまいます。NMeCabがnet48のアセンブリを持っていれば、かなり少なくなる筈です（全てnet48で解決されるため）。ライブラリプロジェクトでNMeCabを使用して、更にそのライブラリを使うプロジェクトでも、同じ問題が発生するので、結果はもっと複雑になります（場合によっては、修正できない事があります）
  • 旧形式のMSBuildプロジェクト（長いcsprojになるやつです）で使う場合、packages.configとApp.configに、人間が理解不能な依存関係が大量に入ってしまう

このようなわけで、私のライブラリプロジェクトやNewtonsoft.Jsonのような、幅広い使われ方をするライブラリでは、一見すると使われそうにない多くのtfmに対応させています（特にライブラリパッケージは、大規模プロジェクトで依存関係が複雑になってくると、何でビルド結果がこうなるのかを説明するのが難しいような結果になります）

なので、NMeCabでもいくつかのtfmはサポートしておいたほうが良いと思います。範囲はおまかせします、参考にしてみて下さい:

• 基本的な考え方は、ビルドに適用するtfmと同じものが存在するのが、最小の依存関係になるので望ましい（つまり全部用意するとベストだけど、現実的じゃないので何を除外するかを考える感じです）
• netstandard系列はできるだけ含める
• .NET Framework系列では、節目になるのがnetstandard2.0に対応するnet461で、ここ未満との差が大きいのでよくやるのがnet45,net461,net48 です。クリティカルな場合はnet46を含めます（netstandard1.6に暗に依存した場合に対応させたい場合）
• .NET Core系列は、ターゲットバージョンのSDKがインストールされていないとビルドできないので、netcoreapp2.1,3.1, net5.0を用意しておくとベター（SDKバージョンに対応するアセンブリがない場合は、netstandard系列を使おうとします。.NET Frameworkほどではないですが、依存関係は増えます）
  *netstandard1系列とnetcoreapp1系列は、さすがにもう良いかという気はします（netstandard1.6辺りをやっておくと、互換性問題の検証になるかも、ぐらい）。また、netcoreapp2.0とnetcoreapp3.0はディスコンなので、強い心がないなら必要ないかと :) ビルドしたい場合はCheckEolTargetFrameworkをfalseにするといいです。

MeCabは何かのライブラリに使われると言うよりも、最終的なproduct（ASP.NETの実装とか、アプリとか）に使われる方が多いんじゃないかと思うので、上に挙げたライブラリからの利用による依存関係の複雑化についてはそこまで神経質にならなくても良いかも知れません。

---

以下はNewtonsoft.Jsonの例です。12.0.3ではPCLをサポートしていた関係で、かなり多くのftmに対応しています。最新の13.0.1ではPCLを諦めたので、多少減っています。

https://www.nuget.org/packages/Newtonsoft.Json/12.0.3
https://www.nuget.org/packages/Newtonsoft.Json/13.0.1

私のNamingFormatterも、出来るだけ依存性を排除したくて多くのtfmを盛ってあります。netcoreappは入っていませんが...:

https://www.nuget.org/packages/NamingFormatter/2.0.22

[komutan]

@kekyo
ありがとうございます。

Linux上でRiderでビルド出来るようにしておきました

助かります！

WindowsFormsSampleはMeCabTaggerの廃止があるのでどうしようかと思いましたが、とりあえずビルドできるように修正しました。一通り終わったら、Avalonia辺りに移植しても良いかもと思っています。

なるほど。私もこれの扱いはどうしようか考えてました。ただのSampleなのですが、色々な方が軽く試したり、テストドライバにしたり、などの用途があるといえばあり、無くせずにいます。かといって移植に時間を使えずにもいました。Avalonia検討したいです。

TFMに関しても、貴重な情報を詳しく丁寧に解説いただき、本当にありがとうございます。
「依存関係の複雑化」なるほどでした。そのような事情があるとは思い至らずにいました。

NMeCabも、以下の観点あり、

• 他のライブラリ（係り受け解析、全文検索トークナイザ、テキストマイニング、NLP、など）経由で使いたい／使って欲しい、という思いはある（全然実現しませんが😅）
• 企業で古めの.NET FWで使われている事が意外とあるらしい
• 実行速度の向上になるかも？

お勧め頂いたTFM対応の拡大を検討したいと思います。
実は、環境の変遷に長く付き合うのは、私にとってはあまり本意でなかったのですが、やるメリットがあると思えるようになりました。
もし今後もサポートいただけるなら大変幸いです。

RelaxVersionerの1.xは古いので2.xに移行しました（これでLinux環境でもビルドできます）

こちらもありがとうございます。
ただ気になったのは、VisualStudio for Mac で下記のエラーがでてビルドできなくなったことです。
dotnetコマンドではビルドも実行もできるので、monoがらみの問題のようです。
omnisharpでも最初はFatalエラーになっていましたが、これはコマンドでビルドすると起きなくなりました。
決して致命的な問題ではないとは思います。
（でも、私の私物ノートPCがMacで😅テスト結果をGUIでみるにはVisualStudioが便利で、これが気になったのでした）
もし解決できるようならお願いできないでしょうか。

/Users/t_komuta/.nuget/packages/relaxversioner/2.3.0/build/RelaxVersioner.targets(5,5): Error MSB3733: 入力ファイル "/var/folders/0z/_dlrj6gn3w1cqrj0vq44cd_h0000gn/T/RelaxVersioner_Result_eeb81b5b-eec5-44e7-96a8-30f49bae54e1" を開けません。Could not find file "/var/folders/0z/_dlrj6gn3w1cqrj0vq44cd_h0000gn/T/RelaxVersioner_Result_eeb81b5b-eec5-44e7-96a8-30f49bae54e1" (MSB3733) (LibNMeCab)

MacOS 11.2.3
.NET SDK 5.0.202
Visual Studio Community 2019 for Mac Version 8.9.2 (build 0)
omnisharp 1.37.8

[kekyo]

RelaxVersionerの修正はあちらに移動しておきます（できるだけ早く直すつもりです）