#記事の説明
.net core 3.1がLTSになったので、以前から試してみたかったC++/CLIを軽く使っていました。
まだ少ししか使っていないので、文法はよく分からないのですが、なかなか良い感じの言語だと思いました。
でも、思っていたよりイマイチ使いづらいと感じました。
そう感じた理由を、メモ代わりに書いていきます。大半がVisual Studio 2019で検証したものです。
（間違いはあるかもしれません）
.net core 3.1関連リンク先は記事の一番下にあります
#.Net Core 3.1 向け C++/CLIの始め方
１・Visual Studio 2019 Ver 16.4.0 をインストールします
２・Visual Studio 2019のインストーラを起動し、
ワークロードから「C++によるデスクトップ開発」と
個別のコンポーネントから「v142 ビルドツール(14.24)のC++/CLIサポート」をチェックしてインストールします
３・Visual Studio 2019を起動し、
ファイル＞新規作成＞プロジェクトをクリック、プロジェクト一覧から「CLR 空のプロジェクト(.Net Core)」を
選択して、適当なパスにプロジェクトを作ります
#.Net Core 向けC++/CLIが思ったほど使いやすくないと感じた理由(本題)
##ビルドすると、ネイティブバイナリの「Ijwhost.dll」も出力される
C++/CLIの実行に、Ijwhost.dllが必要な上、x86のIjwhost.dllとx64のIjwhost.dllとの
混同はできない。
なので、32ビットOS用と64ビットOS用に実行ファイルを作る場合、別々のディレクトリに出力されるようにすること
##一度ビルドしないと、別プロジェクトのインテリセンスの候補が正しくならないし、エラー表示も正確な表示にならない
＊Visual Studio 2019 Ver 16.4.0 にてこの現象を確認＊
##C++/CLIだけだとDLLしか出力できない
プロジェクト設定の構成を「ダイナミック ライブラリ (.dll)」以外にするとビルドが通らない
ので、C++/CLIから実行ファイル(exe)を作ることは不可能
C#からC++/CLIのクラスを使うことはできるので、c#とC++/CLIを組み合わせると実行ファイルを作ることは可能
こうする場合、C#から作るexeとC++/CLIで作るdllとのビット数設定が違うと実行時エラーが出るので、
C#の対象プラットフォーム設定は、Any CPUではなく、x86かx64の方がよい
また、C#側も.net core 3.1向けにする必要がある
（.net framework向けの場合なら、C++/CLIだけでも実行ファイルを出力可能なのに・・・）
##C++側からC++/CLI側の関数を呼べない？（逆は普通に可能）
C++/CLI側で定義した__declspec(dllexport)なグローバル関数は、C++側から呼ぶのができない？（どうやっても関数の未定義エラーが出る）ので、
C++側からC++/CLI側エントリポイント代わりの関数を呼ぶプログラムは作れない
##CC++/CLIのクラスを使うC#のコードをビルドする際、VisualStudioが必須？
VisualStudioを使う場合、正しく設定等ができている時、普通にビルドが通ります。
しかし、コマンドラインからビルドするのは非常に厳しそう・・・
dotnetコマンドでは、C#のビルドはできてもC++/CLIのビルドはできないので・・・
#最後に
C++/CLIの言語仕様じゃなくて、ツール周りに使いにくさを感じさせますね。
言語仕様にも、想像と違うって要素（非ネイティブ関数から関数ポインタ取って使えるかと思ってた、できない）があったりしたけどね。
C++/CLI単体でexeを作ることができないという点だけでかなりマイナスになってる感じ・・・
単純にC#とネイティブコードを連携させるなら、C#とC++を使ったほうがいいような・・・って。
でもC++/CLIは良い感じなんですよね
ネイティブコードの混在が簡単で、
C#には不可能なテンプレート（ジェネリックではない）が使えて、C#より利便性が高そうなとこ
C#よりできること多くて面白いので、C++/CLIの勉強しようかな・・・
#.Net Core 3.1のリンク先
・Download .NET Core 3.1
https://dotnet.microsoft.com/download/dotnet-core/3.1
・Announcing .NET Core 3.1
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/