.NET Coreとそれにまつわるバージョンはいろいろあって、多分数字が大きい方が正しいのであろうと思いつつも1.1と1.0が並行していた時期があったりとどっちを使えば…と若干混乱したことがあったので整理してみようかと。.NET Standardというものもあって頭が爆発しそうですし。

なお.NET Standardに関して詳しくは.NET Standardのページと、藤原さんの.NET Standard のおさらいがおすすめです。

バージョン一覧

2017年6月9日現在の最新の.NET Core/.NET/ASP.NET Core/ASP.NET MVC Coreのバージョンとそれに対応する.NET Standardバージョンの一覧です。

ASP.NET Core/ASP.NET MVC Coreはランタイムではないので.NET Standardには関係ありません。

インストールするときに微妙に混乱することのあった点として.NET Core SDKバージョンやToolingといったものがあるということでしょうか。特にSDKバージョンは.NET Coreのバージョンと一致していないのでわかりにくいです。

.NETとASP.NET Coreのバージョン選択

.NET Coreは最新版を素直に使えば良いので1.1シリーズでよいでしょう。

.NET Frameworkは4.7が最新なのですがSystem.ValueTupleがコアライブラリ入りしたおかげで、.NET Standardなライブラリ側でSystem.ValueTupleパッケージのNuGet参照があると参照が混乱して無事死亡というひどい問題があるので4.7を選ぶときには気を付けましょう。

ASP.NET Core/ASP.NET MVC Coreは最新で良さそうです。

• .NET Coreは.NET Core 1.1(.2) + ASP.NET Core 1.1(.2) + ASP.NET MVC Core 1.1(.3)
• .NET Frameworkは.NET 4.6.2 + ASP.NET Core 1.1(.2) + ASP.NET MVC Core 1.1(.3)
  • .NET Framework 4.7はSystem.ValueTupleの参照の扱いが要注意

.NET Standardの選択

.NET Coreをターゲットにする分に関してはまあ1.0-1.6どれでもという感じです。

.NET Frameworkがややこしく.NET Framework 4.6で.NET Standardは1.6にするにはTooling 2.0である必要がある、ということです。そもそもTooling 1.0/2.0とはという話になって訳が分からないので1.5以下を選ぶのが無難そうです。

なお.NET Standard 1.5は.NET Framework 4.6.2以降なので気を付けないと.NET Framework 4.6がターゲットにならないものになります。1.4でも4.6.1ですけど…。ややこしい。

そういった点を鑑みると以下のような感じで選ぶのがよさそうかなと思いました。

• .NET Coreのみをターゲットにするなら.NET Standard 1.6
• .NET Framework 4.6/.NET Core/Xamarin/UWPをカバーするなら.NET Standard 1.3
  • .NET Framework 4.6.1以降なら1.4
  • .NET Framework 4.6.2以降なら1.5
• .NET Standard 2.0がでたら.NET 4.6.2/.NET Core 2.0(他はそのまま)に引き上げつつ.NET Standard 2.0へ移行

もちろん使いたいものによって選択するものは変わってくると思います。古いランタイムをターゲットにしている場合にはPCLやShared Projectで#ifの方が良かったりするかもしれません(Unityとか)。

まとめ

.NET Standard 2.0はよ。

LINQPadでちょっとしたツールやバッチスクリプト的なものを作ったときに処理対象のとしてファイルを取ることはよくあるのですが、大抵はコードにパスを直接書いていることがほとんどではないでしょうか。

ただ便利なものは往々にして対象ファイルを変えたりしたいとか誰かに渡したいこともあり、そんな時処理対象のファイルをドラッグアンドドロップでコードに渡せれば…と思ったりすることもあります。残念ながらLINQPadに標準で備わっているユーザー入力と言えば Console.ReadLine や Hyperlinq ぐらいでドロップを受け付けるユーティリティは備わっていません。

その時点で普通のWindowsアプリケーションとして作りましょうという気もするのですがそうはいってもめんどくさいですよね。というわけでなんとか渡せるようにする方法です。

解決策

LINQPadは通常出力をHTMLベースで行っていますが、自力でHTML以外のカスタム出力結果パネルを出すこともできます。カスタムな出力結果パネルはWindows FormsやWPFのコントロールをホストできるというものなので、それを利用して通常のWindowsのアプリケーションと同様にドラッグアンドドロップを受け付けるという形でドロップターゲット機能を実現できます。

というわけで以下のようなメソッドを用意することでドロップ用のパネルを表示し、ドロップしたファイルのパスを返せます。

// PresentationFramework.dll と PresentationCore.dll を References に追加しておきます
Task<string[]> WaitForFileDrop()
{
    var tcs = new TaskCompletionSource<string[]>();
    var running = Util.KeepRunning();
    var button = new System.Windows.Controls.Button
    {
        Content = "Drop Here",
        AllowDrop = true,
    };
    var outputPanel = PanelManager.DisplayWpfElement(button, "File Drop");
    button.DragEnter += (sender, e) =>
    {
        e.Effects = System.Windows.DragDropEffects.Copy;
    };
    button.Drop += (sender, e) =>
    {
        var dropPaths = e.Data.GetData(System.Windows.DataFormats.FileDrop) as string[];
        
        running.Dispose();
        outputPanel.Close();
        
        tcs.SetResult(dropPaths);
    };

    return tcs.Task;
}

やっていることは単純でドロップを受け付けるボタンを作り、出力パネルとして表示し、ドロップされたらパスを取り出して TaskCompilationSource<T> を通して呼びもとに返すだけです。

使い方はこんな感じです。必要に応じてMyExtensionsなどに収めておくと使い勝手がいいでしょう。

async Task Main()
{
    // ドロップを待ち受け
    var paths = await WaitForFileDrop();

    // ドロップされたファイルのパスを出力
    paths.Dump();

    // ドロップされたファイルを画像として表示
    paths.Select(x => Util.Image(x)).Dump();
}

これで人に渡したりバッチ的に使うときにちょっと便利に使えるようになるかもしれません。どうぞご利用ください。