dotnetconfJP2017_netcore2
Download as PPTX, PDF1 like846 views
[Japanese] .NET Conf Japan 2017での.NET Core 2.0と.NET Standard 2.0の紹介スライド
dotnetconfJP2017_netcore2
- 1. .NET Core 2.0 V1.1 2017/10/7 .NET Conf Japan 2017 藤原 雄介 @yfakariya
- 2. このセッションについて ▪ 2017/10頭時点での.NET Coreと.NET Standardについて全体像を説明するセッションです。 ▪ 目的は、「そろそろ.NET Core/Standard使ってみよう」 ▪ GCやJIT、MethodTableといった内部実装の深い話はしません。 ▪ .NET Standard 2.0の実現方法の話もしません。 ▪ UnityやXamarin（ネイティブ）やC#のことを期待しているかたは別セッションへ ▪ できる限り生々しい「使ってみた」感がお届けできれば幸いです。 ▪ 内容は個人的な調査・経験に基づくものであり、所属する企業とは一切関係ありません。 ▪ このスライドはSlideShareにアップロード済みです。 ▪ https://www.slideshare.net/yusukefujiwara731/dotnetconfJP2017netcore2 2
- 3. スピーカーについて ▪ SIerでAzureとかIIoTとかに関わりつつ、週末はOSSでシリアライザーを書いたり、Azureの SDKにPRを送ったりしています。 ▪ MsgPack for CLI https://github.com/msgpack/msgpack-cli ▪ 最近Issueをあげているところ ▪ Azure IoT SDK for C# ▪ Azure IoT Edge 3
- 4. セッションのあらまし ▪ .NET Coreの現状 ▪ 何ができるのか ▪ どんなことができるのか ▪ これからどうなっていくのか ▪ .NET Standard 2.0とは何か ▪ いったいこいつは何なのか ▪ どんなことができるのか 4
- 6. .NET Coreとは何か ▪ クロスプラットフォーム向けにリファインした.NET ▪ LinuxやMac OSへの対応（ランタイム、クラスライブラリ） ▪ ランタイムのベースはCLRやSiliverlightのランタイム（CoreCLR）を先祖にしている ▪ クラスライブラリへのPAL（プラットフォーム抽象化レイヤー）の導入 ▪ クラスライブラリの負債の返却（失敗） ▪ ASP.NET Core ▪ かつてASP.NET 5とかASP.NET MVC 6とか言われていたもの ▪ ASP.NET MVCとASP.NET Web APIの融合 ▪ DI（依存先注入）ベースのアーキテクチャ ▪ 今日はこれ以上触れません 6
- 7. .NET Coreでできること ▪ .NETのコンソールアプリとASP.NET CoreをLinuxやMacで動作させることができる ▪ たとえば、 ▪ System.IO.PipesでUnix Domain Socketを使った通信をしたり ▪ /dev以下のファイルを読み書きしてデバイスI/Oしたり（P/Invokeでioctl呼び出す必要はあるだろうけど） ▪ .NETのクラスライブラリやC#/VB/F#を使用してLinux上で動くアプリケーションが書ける ▪ .NET系列のクラスライブラリ ▪ 日付、I/O、ソケット、http、 Task、ThreadPool、 i18n/l10n、XML… ▪ .NET Standard 2.0により、使えるライブラリは増えた（後述） ▪ DataSet、CodeDOM、BinaryFormatter…（完全互換ではない） ▪ System.DirectoryServices（ADSI）とかSystem.Management（WMI）とか 7
- 8. .NET Coreでできないこと ▪ GUIアプリケーション ▪ 単純に実装されていない ▪ 逆に言えば、UIフレームワークを実装すればできるかも ▪ いくつかできないことがある（以下一例） ▪ CodeDOM APIでコードをコンパイルできない（コード生成までは可能） ▪ TypeをBinaryFormatterでシリアル化できない ▪ AppDomainの生成 ▪ .NET Remoting（ContextBoundObject含む） ▪ 互換性のためにMarshalByRefObjectの型定義はある 8
- 9. .NET Coreでできないこと ▪ サポートされている環境 ▪ Windows：x86/x64 ▪ MacOS：x64 ▪ Linux：x64 ▪ armは「プレビュー」（サポート無し、テストも不十分） ▪ RasberryPiで動かすことは可能 ▪ dotnet publish -r linux-armする（Self Contained Deployment）で配置するのが手っ取り早い 9
- 10. .NET Coreの使いどころ ▪ Linux ▪ 正直既存資産の移行的な意味合いは強いが ▪ IDEによる支援、強い型指定、使い慣れたライブラリやプログラミングモデル ▪ サーバーアプリケーション ▪ Webアプリケーションやバッチ処理 ▪ RHELを使う場合はRed hat製のビルドを使う必要があるので注意 ▪ エッジコンピューティング ▪ 産業IoT（IIoT）でのデータ集約・加工処理部分 10
- 11. .NET Coreの使いどころ ▪ Self Contained Deployment（SCD） ▪ .NET Coreはランタイムをアプリケーションと一緒にパッケージングできる（＝ランタイムの事前インストール不 要） ▪ GoよりはJavaのツールに近い ▪ 将来的にはMono Linkerによる不要なコードの切り捨てや単一ファイルへの集約も可能に ▪ 業務系では嬉しいこともあるのでは ▪ ただし、RHELではサポート外 ▪ .NET Core 2.0からは依存先のLinuxネイティブパッケージも同梱可能に ▪ 従来はaptやyumで依存先のパッケージ（curlとかicuとかuuidとか）をインストールする必要があった ▪ https://github.com/dotnet/core/blob/master/Documentation/self-contained-linux-apps.md ▪ .NET Core 2.0からOSの指定が簡素化可能に ▪ 以前：ubuntu.16.04-x64;debian.8-x64;win7-x64;win10-x64 ▪ 今：linux-x64;win-x64 11
- 12. .NET Coreの使いどころ ▪ Dockerコンテナー ▪ Linux/MacOSでDockerコンテナーをサポート ▪ WindowsでもDockerコンテナー（Windows Server Container）をサポート ▪ .NET Frameworkではできない ▪ Dockerコンテナーでできること（SCDと何が違うのか） ▪ 実行環境の設定やミドルウェアを含めてまとめてデプロイ可能になる ▪ Dockerのエコシステム（クラスター管理とか）を利用可能 ▪ プラットフォーム非依存のアセンブリ（Framework Dependent Deployment、dotnet publishで-rを つけない方）を使って構築可能 12
- 13. デモ – self contained deployment 13
- 14. Tips - .NET Coreアプリケーションの起動 ▪ dotnet <エントリポイント>.dll ▪ 内部的にはdotnet exec <エントリポイント>.dllが呼ばれる ▪ これはhostfxr <エントリポイント>.dllを呼び出す ▪ hostfxr（muxer） ▪ .NET CoreのHosting APIを「.NET Core標準の流儀で」呼び出す ▪ 引数なしの場合、<自ファイル名>.dllという名前のアセンブリを実行（正確にはもう少し条件がある） ▪ hostfxr.exeをfoo.exeにリネームすれば、隣に置いたfoo.dllに定義されたMainを実行するということ ▪ SCDで作られる「実行可能アプリケーション」は、これをコピーしてリネームしたもの ▪ 詳細はblogで http://yfakariya.blogspot.jp/2017/03/net-core.html 14
- 15. .NET Coreとツール ▪ Visual Studio 2017で.NET Coreの対応がなされている ▪ とは言え、コードカバレッジなどまだ未対応 ▪ 単体テストツールはXUnit、NUnit、MSTestのいずれも対応済み ▪ XUnit – dotnet new xunitや.NET Core用「xUnitテスト プロジェクト」で作成 ▪ MSTest – dotnet new mstestや.NET Core用「単体テスト プロジェクト」で作成 ▪ NUnit – dotnet newnunit するかライブラリプロジェクトで作成してパッケージ参照を追加 ▪ ただし、 dotnet new -i “NUnit3.DotNetNew.Template::*” でテンプレートの追加が必要 ▪ 指定可能なテンプレートはこちら ▪ https://github.com/dotnet/templating/wiki/Available-templates-for-dotnet-new ▪ thanks @pocketbarserker 15
- 16. デモ - NUnit on .NET Core 16
- 17. .NET Coreのロードマップ ▪ 2017/8 .NET Core 2.0リリース ▪ 2017秋（今月？）：UWP 6.0（UWPを.NET Standard 2.0対応に） ▪ 2018 1Q：.NET Core 2.1 ▪ JITの進化 ▪ Linux ARM対応 ▪ Future ▪ Arm64、android、x86 Linux？ ▪ ライブラリの充実（ML等？） 17
- 18. .NET Core 2.0 ▪ 2017/8にリリース ▪ .NET Standard 2.0対応 ▪ 多くの.NET Framework向けNuGetパッケージが利用可能に ▪ ライブラリ（Corefx）の拡充 ▪ CodeDOM、Pipe、Binary Formatter、DataSet etc ▪ WCF（クライアント）の追加 ▪ 全体的な性能向上 ▪ Span<T>サポート ▪ SCAでの依存ネイティブライブラリの同梱（Linux） 18
- 19. .NET Coreとサポート ▪ LTS（長期サポート版）とCurrent（最新版）がある ▪ .NET Core 2.0はLTSではなくCurrentなので注意 ▪ 具体的な日付 ▪ サポートとは？ ▪ OSSとして、そのバージョンに対して新機能を追加することなく、修正パッチ（セキュリティを含む）の開 発が続くということ バージョン リリース日 最新のパッチバージョン サポートレベル サポート終了日 .NET Core 2.0 2017/8/14 2.0.0 Current 2020/8/14、次のCurrentリリースから3か月後、次のLTSリリースから12か月後のう ちで、いずれか最も早い日。 .NET Core 1.1 2016/11/16 1.1.4 LTS* 2019/6/27、次のLTSリリースから12か月後のうちで、いずれか最も早い日。 .NET Core 1.0 2016/6/27 1.0.7 LTS 2019/6/27、次のLTSリリースから12か月後のうちで、いずれか最も早い日。 * .NET Core 1.1は1.0のLTSライフサイクルに組み入れられており、サポート終了日は同時になります。 https://github.com/dotnet/core/blob/master/microsoft-support.md の内容を抜粋・翻訳 19
- 20. OSS ▪ .NET Coreのソースコードはgithubで公開されている ▪ Pull Requestも可能 ▪ 昔の（.NET Core 1.0時代の）ランタイムのソースコードを見ると、CLRの影が見えて面白い ▪ アクティブ ▪ 開発スピードは上がっていて、すぐに新機能や改善版が来る ▪ 中身を見られるので、障害追及が容易に ▪ ベンダーサポート ▪ よりOSSに近い流儀に変わっていく可能性 20
- 21. 主なgithubリポジトリ ▪ dotnet/core：ホーム（一部のドキュメントはここにしかない） ▪ dotnet/coreclr：ランタイムとライブラリの根幹（いわゆるmscorlib） ▪ 新機能の議論やレビュはdotnet/designsリポジトリ ▪ dotnet/corefx：クラスライブラリ（いわゆるBCLやFCLと言われていたもの＋α） ▪ 新しいAPIの議論やレビュはdotnet/apireviewsリポジトリ ▪ dotnet/cli：dotnetコマンドのフレームワーク ▪ dotnet/core-setup：muxerやインストーラー/パッケージ ▪ dotnet/docs：ドキュメントのマークダウンファイル ▪ dotnet/corert：AOTによるネイティブコンパイル向けに最適化されたマネージドコードによるランタイムの実装 ▪ dotnet/corefxlab：corefxに入れる前の試験実装置き場 21
- 23. .NET Standardとは ▪ さまざまな.NETの実装が共通で持つべき基本クラスライブラリの仕様（＝型とメンバー）の定義 ▪ .NET Framework ▪ UWP ▪ Xamarin/Mono ▪ Unity ▪ 各実装が持つ「基本クラスライブラリの充実度（1.0～1.6、2.0）」を定義 ▪ PCLのフラグセットの後継 ▪ ライブラリの場合は「前提としているStandardのレベル」という意味で、2つの意味がある ▪ レベルが高ければ高いほど、そのライブラリでは、たくさんの「基本クラスライブラリ」APIを使える ▪ レベルが低ければ低いほど、そのライブラリを、多くのプラットフォームで実行できる 23
- 24. .NET Standardのレベルと関係 ランタイムX ランタイム同梱の 基本クラスライブラリ サードパーティ製の パッケージ アプリケーション ビルド対象： netcoreapp2.0 net47 サポートするstandard 1.5 サポートするstandard 1.3 ビルド対象が対応するレベル以下の standardをサポートしているか？ 使いたいAPIをサポートするレベル以上の standardをサポートしているか？ ビルド対象が対応するレベル以下の standardをサポートしているか？ • レベルを大きくすればするほど 多くの基本クラスライブラリAPIを使える • レベルを小さくすればするほど 多くのアプリケーションやライブラリから 使えるようになる 24
- 25. .NET Standardがないと ▪ ライブラリの作成者は、各実装ごとにビルドを分ける必要がある ▪ プラットフォームごとに基本クラスライブラリの型やメンバーに過不足がある ▪ プラットフォームごとに型を定義するアセンブリの名前が違う ▪ 結果 ▪ #if地獄 ▪ nuspec記述地獄 ▪ ディレクトリ（Target Framework Moniker）構成地獄 ▪ ビルドスクリプト地獄 ▪ リリースも面倒 ▪ どこまでテストすればいいのか 25
- 26. .NET Standardが解決！ ▪ 単一のライブラリをビルドして配れば、多くの環境で動く ▪ 単一の環境でテストしたバイナリが様々な環境で動く ▪ ライブラリ作成者にとっては夢のような話 ▪ 過去PCLで公開されていたライブラリも.NET Standardとしてみなすことができる ▪ 詳細はここを参照：https://docs.microsoft.com/ja-jp/dotnet/standard/net- standard#comparison-to-portable-class-libraries ▪ Profile 259(portable-net45+win8+wpa81+wp8)が多め？ 26
- 27. さらに.NET Standard 2.0！ ▪ 従来の.NET Framework（4.6以降）向けにビルドされたライブラリを.NET Core等で動かす仕掛けが加わっ た ▪ 従来の問題：アセンブリ名の不一致（例：System.Objectが定義されているアセンブリが異なる）によるビルドエラーや 実行時エラー ▪ 型フォワーディングで解決 ▪ .NET Standard 2.0向けライブラリのビルド時に、ビルド対象プラットフォームで規定された名前からnetstandard.dllにフォ ワードするファサードアセンブリ群を同梱する（NetStandard.Libraryパッケージに含まれている） ▪ これにより、依存先ライブラリ（.NET Standard 1.x向けや.NET Framework向けの可能性がある）が公開している型を含 め、.NET Standard 2.0向けライブラリからのすべてのアセンブリ参照がnetstandard.dllに集約され、依存関係グラフが簡素化 される ▪ アプリケーションのビルド時に、ビルド対象プラットフォームが用意したファサードアセンブリが同梱される（.NET Standard 1.x互換のアセンブリ群、.NET Framework互換のアセンブリ群、netstandard.dllのうち、対象のプラットフォームに存在し ない名前のもの） ▪ .NET Frameworkであれば、最終的にmscorlibやSystem.Coreにフォワード ▪ .NET Coreであれば、最終的にSystem.Private.CoreLib.dllやSystem.Runtime.Extensions.dllにフォワード ▪ これで、従来の.NET 4.6.1以上向けのNuGetパッケージもサポートされる！ 27
- 28. 型フォワードについてもうちょっと詳しく ビルドターゲット ビルド時の 参照先アセンブリ .NET Frameworkでの 実行時の動作 .NET Coreでの 実行時の動作 .NET Framework mscorlib、 System.Core… そのままGAC内のアセ ンブリを実行 System.Private.CoreLi b、System.Runtime… などにフォワードされ て実行 .NET Standard 1.x .NET Core System.Private.CoreLi b… mscorlib、 System.Core…にフォ ワードされて実行 そのまま System.Private.CoreLi bを実行 .NET Standard 2.0 netstandard.dll mscorlib、 System.Core…にフォ ワードされて実行 System.Private.CoreLi b、System.Runtime… などにフォワードされ て実行 28
- 29. 枯草や兵どもが夢のあと ▪ 基本クラスライブラリに入っていない機能が必要な場合は#if ▪ ビルドできたと思ったら実行時のPlatformNotSupportedException ▪ AOT環境だと実行時のExecutionEngineException ▪ HTTPスタックなどの実装差異等でなんか動かない ▪ ネイティブライブラリ依存があるとアウト ▪ .NET Framework 4.5向けまでしかリリースしてないとアウト 29
- 30. Done is Better than Perfect ▪ 統計処理だとか、パーサーだとかであれば問題ない ▪ シリアライザはリフレクションベースで実装されていればOK ▪ 環境ごとに依存先が違うなど #if だけでは辛い場合はNuGetizer 3000を使うのも手 ▪ https://github.com/NuGet/Home/wiki/NuGetizer-3000 ▪ あなたが（フルマネージドで）書いた以下のようなライブラリが色々な場所で使える ▪ 統計処理、機械学習、自然言語処理、etc ▪ データ構造・アルゴリズム（Trie、SkipList、etc） ▪ パーサー（markdown、YAML、etc） ▪ 通信ヘルパー（exponential backoff、circuit breaker、etc） 30
- 31. .NET Standardとの向き合い方 ▪ アプリケーション開発者が気にすべきこと ▪ NuGetパッケージが.NET Standard対応してくれると使えて嬉しい！ ▪ プロジェクトが.NET Standard対応だといろんなNuGetパッケージが使えて嬉しい！ ▪ ライブラリ開発者（公開・非公開関わらず）が気にすべきこと ▪ .NET Standardでビルドしておくと後から色々使いまわしがきいて嬉しい！ ▪ .NET 4.6以上に対応しておくと.NET Standard 2.0互換になってて嬉しい！ ▪ ランタイム開発者が気にすべきこと ▪ エコシステムが広がって嬉しい！ ▪ 苦労話はUnityやXamarinの中の人に聞くといいんじゃないかな 31
- 32. .NET Standardの使いどころ ▪ 新しくライブラリを作るならとりあえず.NET Standardにしておけば良い ▪ Amazon Linuxで動かしたくなった ▪ Linux搭載機器で動かしたくなった ▪ Web Appsのログ出力を楽にしたいのでMicrosoft.Extensions.Logging使おうと思ったらDIないとつ らいしASP.NET Coreにしてみたくなった ▪ .NET Standard 2.0のライブラリを.NET Framework 4.6（以降）のライブラリから参照でき るので、.NET Framework固有の機能が必要なものを外出し、.NET Standard 2.0ライブラ リを参照した「拡張ライブラリ」を定義できる ▪ Windows固有の機能を使いたい場合 ▪ .NET Standard 2.0でも動かない既存ライブラリを使いたい場合 32
- 33. .NET StandardでどのAPIが使えるのか？ ▪ https://github.com/dotnet/standard/tree/master/docs/versions を参照 ▪ ざっくりいうと ▪ (.NET Framework) - (GUI) - (Win32) - (AppDomain) - (.NET Remoting) - (Code Access Security) - (COM Interop) ▪ 使えないものの例 ▪ CallContext：AsyncLocalを使う ▪ AppDomain.CreateDomain/Unload：ワーカープロセスを使う（まじか） ▪ 「フレームワーク」に近いものはそれなりに考慮が必要 33
- 34. .NET Standard周りの動き ▪ Xamarin.Formsは2.4.0で.NET Standard 1.0をサポート済み ▪ UWPはFall Creators Update（UWP 6.0）で.NET Standard 2.0に対応予定 ▪ Unityも.NET Standard 2.0に対応予定 ▪ 2017.3.beta2時点ではまだ ▪ いずれも、AOT環境固有の問題は別 34
- 35. 2017年版.NET Standardの選び方 ▪ アルゴリズム系のライブラリなどで外部依存がなく、少しでも多くの環境をサポートしたいか？ ▪ netstandard 1.0 ▪ .NET 4.5やWindows Phone、Windows8.xをサポートする必要があるか？ ▪ netstandard 1.0 ▪ FCUより前のUWPをサポートする必要があるか？ ▪ netstandard 1.4 ▪ それ以外 ▪ netstandard 2.0 35
- 36. .NET Standard対応済のライブラリの一例 ▪ JSON.NET ▪ Utf8Json ▪ MessagePack for CLI ▪ MessagePack for C# ▪ CsvHelper ▪ Reactive Extensions ▪ Microsoft.Extensions.Log ging ▪ Serilog ▪ log4net ▪ MySQL.Data ▪ Npgsql ▪ AWS Lambda ▪ Azure Storage SDK ▪ Azure IoT Device SDK ▪ Azure IoT Service SDK ▪ Azure IoT Edge SDK ▪ Azure Cosmos DB SDK 36
- 37. PCL互換で対応済のライブラリの一例 ▪ Math.NET Numerics (profile259) ▪ AWS S3 (profile259) ▪ AWS SQS (profile259) ▪ AWS SNS (profile259) ▪ AWS Kinesis (profile259) 37
- 38. NuGetパッケージの.NET Standard対応の調べ方 ▪ NuGetサイトのDependenciesを見ればある程度推察できる ▪ .NET Standardなら依存先として何かしら存在するはず ▪ ただし、これは.nuspecファイル内の自己申告であり、間違っている可能性もある ▪ 最終的には、.nupkgファイルをマニュアルダウンロードし、lib/以下を見るのが良い ▪ 7zipなどのzipファイラーで中身を見ればいい 38
- 39. まとめ ▪ .NET Coreはクロスプラットフォームで動く.NET ▪ Linux ARMは次の2.1を待つ ▪ サーバーやエッジコンピューティングなどで使える ▪ Self Contained DeploymentやDockerによる配置 ▪ ツール類の対応が追い付いてきており、始めるには好機 ▪ .NET Standardはライブラリの準拠度合いのこと ▪ 新しいライブラリは.NET Standard 1.0か2.0で作るといい ▪ UnityやUWPの準拠でますます使いやすく ▪ エコシステムを拡大していきましょう！ 39