Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
Similar a Visual Studio 2019で始める「WPF on .NET Core 3.0」開発 (20)
Más de Atsushi Nakamura
Más de Atsushi Nakamura (17)
Visual Studio 2019で始める「WPF on .NET Core 3.0」開発
- 1. Visual Studio 2019で始める 「WPF on .NET Core 3.0」開発 Desktop App Dev Strategy for .NET Core 3.0 Atsushi Nakamura
- 2. Desktop App Dev Strategy for .NET Core 3.0 Overview
- 3. Overview Slide 3Copyright 2019 @nuits_jp 主に次の二つについて、お伝えしたいと思います。 1. WPFを.NET Coreで開発するモチベーション 2. .NET Core移行の「感覚」
- 4. Desktop App Dev Strategy for .NET Core 3.0 About Me
- 5. About Me Copyright 2019 @nuits_jp Slide 5 中村 充志 / Atsushi Nakamura • リコージャパン株式会社 所属 • Enterprise（金融）系SIerのITアーキテクト • アプリケーションアーキテクチャを試行錯誤するのが趣味 • 2019年の目標 • 「世界一簡単なクリーンアーキテクチャ」で登壇したい • 「xUnit & Moqハンズオン」開催 • 「RICOH Handy Printerハンズオンとか？」やりたいな？ • Blog http://www.nuits.jp • Blog（英語） https://blog.nuits.jp • Twitter @nuits_jp
- 6. .NET Core 使ってますか？ Copyright 2019 @nuits_jp Slide 6
- 7. .NET Core 3.0でWPFを動かしてみましたか？ Copyright 2019 @nuits_jp Slide 7
- 8. Desktop App Dev Strategy for .NET Core 3.0 おねがい
- 10. Desktop App Dev Strategy for .NET Core 3.0 WPFを.NET Coreで開発する「私の」モチベーションとは？
- 11. WPFを.NET Coreで開発する「私の」モチベーションとは？ 1. .NET Core 3.0におけるWinForms・WPFのサポート 2. 開発の中心が.NET Coreへシフト 3. 魅力的な.NET Coreの特徴
- 12. デスクトップ アプリを.NET Coreで開発するモチベーションとは？ 1. .NET Core 3.0におけるWinForms・WPFのサポート 2. 開発の中心が.NET Coreへシフト 3. 魅力的な.NET Coreの特徴
- 13. • 開発の中心はすでに.NET Coreへシフト • .NET Frameworkへのポーティングは後方互換性重視 https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/ • .NET Framework4.8は.NET Standard 2.0相当 • .NET Core 3.0は.NET Standard 2.1相当 • クラウドは.NET Core一択 開発の中心が.NET Coreへシフト Copyright 2019 @nuits_jp Slide 13
- 14. デスクトップ アプリを.NET Coreで開発するモチベーションとは？ 1. .NET Core 3.0におけるWinForms・WPFのサポート 2. 開発の中心が.NET Coreへシフト 3. 魅力的な.NET Coreの特徴
- 15. 魅力的な.NET Coreの特徴 • Side by Sideの復活 • Runtimeを同梱して配布可能（たったの60Mぽっち） • 軽快な動作速度を含む、先進的な機能の採用 ついに.NET Framework 4.0とおさらばだ！（某金融向SIer） .NET Framework 3.5で頑張らないでいいんですね！涙（某金融向SIer） Copyright 2019 @nuits_jp Slide 15
- 16. で、.NETCoreでWPFって現実的なの？ Copyright 2019 @nuits_jp Slide 16
- 17. Desktop App Dev Strategy for .NET Core 3.0 .NET Framework → .NET Core Live Migration
- 18. ！注意事項！
- 19. 1. 本マイグレーションは、移行における「感覚」を理解しやすいと思 われる手順で実施しています 2. 実際の移行案件では以下の公式ドキュメントを参照してください • .NET Framework から .NET Core にコードを移植する https://docs.microsoft.com/ja-jp/dotnet/core/porting/ • WPF デスクトップ アプリを .NET Core に移植する https://docs.microsoft.com/ja-jp/dotnet/core/porting/wpf 注意事項
- 20. 実業務レベルのアプリをMigration Copyright 2019 @nuits_jp Slide 20
- 21. 対象アプリの特徴 • .NET Framework 4.5.2 • 大き目な.NET Framework製のサードパーティライブラリ • ビルドしたDLLの編集（静的コード生成） • TWAIN制御（.NET→COM→Win32 API 32bit driver） • System.Drawing.Bitmapに依存（つまりGDI+に依存） Copyright 2019 @nuits_jp Slide 21
- 22. Let’s Migration! Copyright 2019 @nuits_jp Slide 22
- 23. .NET Frameworkでは標準で参照できたパッケージが.NET Coreでは標準 では参照できない可能性があります。 次のいずれかで、概ね解消できます。 1. NuGetから同名のパッケージを適用する 2. Windows 互換機能パックを利用する https://docs.microsoft.com/ja-jp/dotnet/core/porting/windows-compat-pack とはいえ、無いものもあります。その話は後程。 Point 1 Copyright 2019 @nuits_jp Slide 23
- 24. To Migration again. Copyright 2019 @nuits_jp Slide 24
- 25. .NET Coreで正式に非対応なものも存在します。 AppDomain、.NET Remoting、コード アクセス セキュリティ (CAS)、透過的 セキュリティコードなど。 https://docs.microsoft.com/ja-jp/dotnet/core/porting/net-framework-tech-unavailable • 自分のコード内の場合 → .NET Portability Analyzerでチェックし別の実現手段を採用 https://docs.microsoft.com/ja-jp/dotnet/standard/analyzers/portability-analyzer • サードパーティ コード内の場合 → .NET Coreもしくは.NET Standard対応ライブラリに変更 Point 2 Copyright 2019 @nuits_jp Slide 25
- 26. ちょっと待って！ Copyright 2019 @nuits_jp Slide 26
- 27. なんで.NET Frameworkプロジェクトを参照できるの？？ Copyright 2019 @nuits_jp Slide 27
- 28. Xamarinを例に考えると（私には）分かりやすい Copyright 2019 @nuits_jp Slide 28 UserSideFrameworkSide System.IO.File for .NET Standard My Class Library for .NET Standard My Application User Interface for .NET Standard Build時Android実行時 iOS実行時 System.IO.File for Mono.Android My Class Library for .NET Standard My Application User Interface for .NET Standard Mono.Android Runtime java.io.File My Class Library for .NET Standard My Application User Interface for .NET Standard System.IO.File for Mono.iOS Mono.iOS Runtime NSFileManager ? and SwitchBait
- 29. .NET Frameworkと.NET Coreの場合 Copyright 2019 @nuits_jp Slide 29 UserSideFrameworkSide .NET Framework Runtime Win32 API System.IO.File for .NET Framework My Class Library for .NET Framework My Application for .NET Framework Original .NET Core Windows Runtime Win32 API System.IO.File for .NET Core My Class Library for .NET Framework My Application for .NET Core .NET Coreで実行時.NET CoreでBuild時 System.IO.File for .NET Framework My Class Library for .NET Framework My Application for .NET Core and SwitchBait
- 30. なぜ.NET Frameworkのプロジェクト参照が通るのか 理由は主に2点 • 中間言語（CIL）は共通仕様である • ネイティブ呼び出しは元々サポートされている 従って条件を満たせば、.NET Frameworkでビルドしたモジュール も.NET Coreから利用可能です。 Copyright 2019 @nuits_jp Slide 30
- 31. .NET Frameworkと.NET Coreの場合 多分こんなイメージ（ちょっと間違ってるかも？ Copyright 2019 @nuits_jp Slide 31 UserSideFrameworkSide .NET Framework Runtime Win32 API System.IO.File for .NET Framework P/Invoke My Class Library for .NET Framework My Application for .NET Framework .NET Core Runtime Win32 API System.IO.File for .NET Core P/Invoke My Class Library for .NET Framework My Application for .NET Core
- 32. .NET Frameworkと.NET Coreの場合 多分こんなイメージ（ちょっと間違ってるかも？ Copyright 2019 @nuits_jp Slide 32 UserSideFrameworkSide .NET Framework Runtime Win32 API System.IO.File for .NET Framework P/Invoke My Class Library for .NET Framework My Application for .NET Framework .NET Core Runtime Win32 API System.IO.File for .NET Core P/Invoke My Class Library for .NET Framework My Application for .NET Core この二つは完全に別物です My Class Libraryから利用している クラス・メソッドがCoreに存在しない 場合、実行時エラーとなります
- 33. 1. .NET Frameworkでビルドされたモジュールも動作する可能性はある .NET Framework 互換モード https://docs.microsoft.com/ja-jp/dotnet/core/porting/third-party-deps#net-framework-compatibility-mode 2. ただし直接・関節的に.NET Coreでサポートされていない物に依存してい る可能性がある 3. サードパーティの.NET Frameworkライブラリが.NET Core上で正常動作す るかどうか、.NET Portability Analyzerではわからない（と思う） 4. 一時的に動作していても、内部分岐で突如動かなくなる可能性がある 5. 可能な限り.NET Coreもしくは.NET Standard対応ライブラリを利用する Point 3 Copyright 2019 @nuits_jp Slide 33
- 34. To Migration again. Copyright 2019 @nuits_jp Slide 34
- 35. 不安視してたけど問題なかった箇所 • ビルドしたDLLの編集（静的コード生成） • TWAIN制御（.NET→COM→Win32 API 32bit driver） • System.Drawing.Bitmapに依存（つまりGDI+に依存） Copyright 2019 @nuits_jp Slide 35
- 36. まとめ Copyright 2019 @nuits_jp Slide 36
- 37. 1. .NET CoreのWPFサポートは非常に魅力的です 2. 移行は（依存ライブラリが.NET Standard対応してれば）そう難しくない！ 3. まずは公式ドキュメントを参照 • .NET Framework から .NET Core にコードを移植する https://docs.microsoft.com/ja-jp/dotnet/core/porting/ • WPF デスクトップ アプリを .NET Core に移植する https://docs.microsoft.com/ja-jp/dotnet/core/porting/wpf 4. .NET Framework製のライブラリは .NET Coreもしくは.NET Standardへ全て移行推奨 → 動作する可能性はあるが、特定の条件下で.NET Core 未サポートのAPIを利用している可能性があり危険 まとめ Copyright 2019 @nuits_jp Slide 37
Notas del editor
- みなさんこんにちは。 ご紹介いただきました。ニュイこと中村です。 今日は Visual Studio 2019で始める「WPF on .NET Core 3.0」開発 というTitleでお話しさせていただきます。 よろしくお願いいたします。
- さて、まず初めに本日の概要についてお話します。
- 本日は、主に次の二つについてお話しします。 まず初めに、そもそもデスクトップアプリを なぜ.NET Coreで実装するのか？したいのか？ そのモチベーションについて再確認したいと思います。 その後、実際に.NET Frameworkで作られた WPFのアプリケーションを.NET Coreに移行しつつ 移行の「感覚」をとらえて貰えたらと思います。 「感覚」と表現したのは意図があります。 移行の詳細をもれなく理解するには公式のドキュメントを読んでいただくのが最良でしょう。 本セッションではモチベーションから具体的な計画につながる そのハザマの「現実的に可能だ」という感覚を理解してもらいたいと思っています。 時間の関係上、前者はさらっとお話しして、基本的に後半をじっくりやりたいと思います。
- さて、本題に入る前に簡単に自己紹介をさせてください。
- 中村充志と申します。 リコージャパンという会社で 主に金融機関向けのEnterprise系SIerでITアーキテクトをやらせてもらっています。 アプリケーションアーキテクチャをうだうだ考えるのが趣味で、今年は「世界一簡単なクリーンアーキテクチャ」ってタイトルでどこかで登壇したいなと思ってます。 あと最近界隈で人気の弊社のハンディプリンタを触ったり遊べるイベント企画してみたいと思ってますが、会社がOKくれるか分かりません。 興味ある方はぜひTwitterをフォローください。 悲しみばかりが流れてくるかもしれませんが。 というわけで、本題に入る前に、二つほど質問させてください。
- 一つ目！ もうすでに.NET Coreを仕事に使ってるよって方、どの程度いらっしゃいますか？
- 二つ目！ .NET CoreでWPFを動かしてみたよって方はどの程度いますか？
- ありがとうございます。 コメント さて、始める前に二点、お願いがあります。
- 今回のデモの中で某サードパーティさんのライブラリがでてきますが、該当製品について言及したい訳ではありませんので、製品についてTwitterなどで拡散するのは控えていただけたらと思います。 あと今回のデモのコードは、ガチで弊社の業務アプリを使います。 会社内緒でもってきたので、私が製品コードでデモしてたよ！というのは弊社の人間には内緒にしておいていただけると助かります。 というのは半分冗談です。基本的には私の裁量の範疇に収まる話なので気にしていただかなくて大丈夫です。
- では早速、本題に入りたいと思います。
- デスクトップアプリケーションを.NET Coreで開発したい、その本質的な理由はどこにあるのか？ まずそこからお話ししたいと思います。 私は主に次の3点から、Coreを利用したいと考えています。 ①まず第一に、.NET Core 3.0から、WPFやWinFormsがサポートされたということ。 ②つぎに、すでに開発の中心が.NET Frameworkから.NET Coreにシフトしているということ ③最後に.NET Coreが非常に魅力的な特徴を持っているということ この3点です。 一番目は良いとして、2番以降をもう少し掘り下げてお話ししたいと思います。
- まず、開発の中心が.NET Coreにシフトしているという点について
- 実はすでに.NETの開発の中心は.NET FrameworkからCoreにシフトしています。 現在、.NET Frameworkへのポーティングは後方互換性を重視して行われています。 したがって、最先端の技術はCoreでだけ利用できるということが実際に起こり始めています。 実際、つい先日リリースされた.NET Framework4.8では.NET Standard 2.1のサポートは見送られていますし そうではなくても、クラウドファーストが推進されている現在、クラウドでの利用は.NET Core一択だという現実もあります。
- また、Framework側のネガティブな問題だけではなく そもそもCoreが非常に魅力的だということがあります。
- 私が特に魅力を感じるところは、次の3点にあります。 ①ひとつはSide by Sideが復活し、異なるバージョンを共存して利用できるということ ②二つ目はRuntimeを事前にインストールしておかなくても、アプリに含めて配布できるということ ③そして軽快な動作速度を含む、先進的な機能の採用 です。 技術的な投資を効率化する上で、Frameworkに絞って投資する意味はあまりなく、Coreに集中したいというのが私の本音です。
- とはいえ、.NET Coreってクロスプラットフォーム用でしょ？ WPF動かすなんて現実的にどうなの？という疑問はあるかと思います。
- そこで本セッションでは .NET Frameworkで書かれたアプリを.NET Coreにマイグレーションすることを通して そのあたりのポイントについて実際に感じていただけたらと思います。
- さて、実際にマイグレーションを見ていただく前に ひとつ注意していただきたい点があります。
- このマイグレーションはあくまで移行における「感覚」を理解していただくことを主眼においています。 実際に移行する際には、こちらの公式のドキュメントを参照して進めてください。
- では実際にマイグレーションする前に、どのような特徴をもったアプリなのか 簡単に説明しておきたいと思います。
- 対象のアプリケーションは実際に弊社で開発している業務アプリで かれこれ8年くらい熟成された全体としてはそこそこ大きなアプリの一部です。 アプリは.NET Framework 4.5.2という最新のフレームワークで開発されており 比較的大きな.NET Framework製のサードパーティライブラリを利用しています。 また、トラブりそうな要素として 静的コード生成を利用したDLLの書き換えや、COM経由でのスキャナードライバの呼び出し System.Drawing.Bitmapに代表されるようなWindowsに強く依存するコードが含まれています。 実際に移行デモをするのにそこそこ良い題材だと思います。
- ではマイグレーションを始めましょう。
- .NET Coreには.NET Frameworkにはあったけど、正式に対応しないことが明言されているものが存在します。 AppDomainや.NET Remotingなどで、詳細はこちらのリンクに記載があります。 このため、そういったものを利用している場合、自分のコードであれば.NET Portability Analyzerでチェックして別の実現手段によって解決する必要があります。 またサードパーティライブラリの場合は.NET Coreもしくは.NET Standard対応のライブラリに移行していただく必要があります。
- ところで、鋭い方はすでにお気づきかもしれません。
- なぜか .NET Core可したプロジェクトから.NET Frameworkのプロジェクトへ参照が設定されて、ビルドできています。 クロスプラットフォームプロジェクトから、プラットフォーム依存のコードが参照できては拙いのでは？という疑問が当然生まれますよね？
- このことは、私的にはXamarinの例をとって考えると非常にわかりやすいです。 Xamarinでは共通コードは.NET Standardで記載します。 ①.NET Standardで実装された共通のUIライブラリは ②.NET Standardで実装されたクラスライブラリを利用しているとします。 ③そのクラスの中でファイルIOを実装していたとしましょう。 そうした場合、実際にはどのように動作するでしょうか？ ④例えばAndroidの場合はこうなります。 ビルド時には.NET StandardのFileクラスを参照してビルドしていましたが 実行時にはMono.Androidで実装されたFileクラスが呼び出されます。 そしてその中では、Androidのネイティブであるjava.io.Fileが呼び出されることによってファイル操作が実現されます。 ⑤iOSであっても同様です。 これは一般的に ⑥Bait ⑦And Switchと呼ばれる手法です。 元々は「おとり商法」の意味で、例えば不動産屋なんかで、ネットで有料広告を売っておいて店頭に言ったら 「いやお客さんその物件さっき契約されちゃいまして。ちょっと高いですけどこんな物件どうですか？」 といった最初から存在しないBaitつまり餌でつっておいて、Switchここでは小枝でむち打ちという意味だそうですが、Switchすることが語源だそうです。 .NET StandardのFileというBaitで釣っておいて、ビルドしておいて、実行時は各プラットフォームにSwitchするわけです。 この場合別に鞭打たれていませんけどね。
- では.NET FrrameworkとCoreに置き換えて考えてみましょう。 最初、すべてのモジュールは.NET Frameworkでビルドされていました。 ①そしてアプリケーションを.NET Coreに置き換えました。 しかしライブラリは依然Frameworkのままです。したがってライブラリが参照するのもFrameworkのFileクラスです。 ②これを実行すると、ランタイムはWindows用のCoreランタイムです。 従ってFileクラスは.NET CoreのWindows用のランタイムになります。 実行環境がLinuxならランタイムもFileクラスもLinux用のものになります。 つまりここで ③Bait and Switchが発生しているわけです。
- この状況で動作する特に重要なポイントは次の二つです。 ひとつは、中間言語は共通仕様であってFrameworkでもCoreでも変わりない事 そして別にWPFとは関係なく、もともと.NETからネイティブのAPIを呼び出す仕組みは.NET Frameworkにも.NET Coreにも備わっているからになります。 従って、条件を満たせば実のところ.NET Framework向けにビルドされたモジュールは.NET Coreでも動作します。
- ただもちろん注意は必要です。 この二つのFileクラスは
- 完全に別物になります。 例えばライブラリから利用しているメソッドが、Frameworkには存在しても、Coreには存在しないということは起こりえます。 この場合、ビルドは通って実行時エラーになります。
- というわけで三つ目のポイントです。 まずFrameworkでビルドされたモジュールも、Core環境で動作する可能性があります。 ただし、直接・間接的に.NET Coreでサポートされていない物に依存している可能性があります。 既にFrameworkビルド済みのサードパーティライブラリが、Coreで動作するかどうかは、.NET Portability Analyzerでは分からないと思います。多分。 また一時的に動作しても、内部分岐次第では、非常に低い確率で突如実行時エラーになるということがあり得ます。 このため、特別な理由があってFrameworkのライブラリを利用せざるを得ず、かつ利用しても問題がないという何らかの確証がないかぎり、基本的には.NET CoreやStandard対応のライブラリを利用したほうが安全だと思います。
- さて。それではマイグレーションの続きに戻りましょう。
- というわけで、一通り動作が確認できました。 今回、つぎのような技術要素について、不安視していましたが実際には問題なく動作してしまいました。 個人的には静的コード生成はFramework 4.5.2を対象にしていたことから、エラーになるつもりだったのですが、思った以上に素直に移行できてしまい驚いています。
- さて、最後にまとめましょう。
- .NET CoreがWPFをサポートすることは、少なくとも私にとっては非常に魅力的です。 また移行自体は、もちろんなんでも移行できるわけではありませんが、条件が整えば比較的簡単に移行できそうです。 移行する際には、すでに公式のドキュメントが用意されていますので、まずはそちらを確認しましょう。 公式ドキュメントにも、Frameworkのライブラリが利用できる旨記述がありますが やはり危険なケースもありますから、可能であればCoreもしくはStandardに統一したほうがよいのではと私は考えています。
- 以上で私の発表を終わります。 ご清聴ありがとうございました。