Successfully reported this slideshow.
Your SlideShare is downloading. ×

Visual Studio 2019で始める「WPF on .NET Core 3.0」開発

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 38 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to Visual Studio 2019で始める「WPF on .NET Core 3.0」開発 (20)

Advertisement

More from Atsushi Nakamura (15)

Recently uploaded (20)

Advertisement

Visual Studio 2019で始める「WPF on .NET Core 3.0」開発

  1. 1. Visual Studio 2019で始める 「WPF on .NET Core 3.0」開発 Desktop App Dev Strategy for .NET Core 3.0 Atsushi Nakamura
  2. 2. Desktop App Dev Strategy for .NET Core 3.0 Overview
  3. 3. Overview Slide 3Copyright 2019 @nuits_jp 主に次の二つについて、お伝えしたいと思います。 1. WPFを.NET Coreで開発するモチベーション 2. .NET Core移行の「感覚」
  4. 4. Desktop App Dev Strategy for .NET Core 3.0 About Me
  5. 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. 6. .NET Core 使ってますか? Copyright 2019 @nuits_jp Slide 6
  7. 7. .NET Core 3.0でWPFを動かしてみましたか? Copyright 2019 @nuits_jp Slide 7
  8. 8. Desktop App Dev Strategy for .NET Core 3.0 おねがい
  9. 9. 1. デモの中でサードパーティライブラリが登場しますが、その製品に ついてはTwitterなどでの拡散は控えてください 2. 弊社の人間に、「某XXが製品コードでデモしてたよ!」と積極的に 伝えることはお控えください おねがい
  10. 10. Desktop App Dev Strategy for .NET Core 3.0 WPFを.NET Coreで開発する「私の」モチベーションとは?
  11. 11. WPFを.NET Coreで開発する「私の」モチベーションとは? 1. .NET Core 3.0におけるWinForms・WPFのサポート 2. 開発の中心が.NET Coreへシフト 3. 魅力的な.NET Coreの特徴
  12. 12. デスクトップ アプリを.NET Coreで開発するモチベーションとは? 1. .NET Core 3.0におけるWinForms・WPFのサポート 2. 開発の中心が.NET Coreへシフト 3. 魅力的な.NET Coreの特徴
  13. 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. 14. デスクトップ アプリを.NET Coreで開発するモチベーションとは? 1. .NET Core 3.0におけるWinForms・WPFのサポート 2. 開発の中心が.NET Coreへシフト 3. 魅力的な.NET Coreの特徴
  15. 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. 16. で、.NETCoreでWPFって現実的なの? Copyright 2019 @nuits_jp Slide 16
  17. 17. Desktop App Dev Strategy for .NET Core 3.0 .NET Framework → .NET Core Live Migration
  18. 18. !注意事項!
  19. 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. 20. 実業務レベルのアプリをMigration Copyright 2019 @nuits_jp Slide 20
  21. 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. 22. Let’s Migration! Copyright 2019 @nuits_jp Slide 22
  23. 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. 24. To Migration again. Copyright 2019 @nuits_jp Slide 24
  25. 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. 26. ちょっと待って! Copyright 2019 @nuits_jp Slide 26
  27. 27. なんで.NET Frameworkプロジェクトを参照できるの?? Copyright 2019 @nuits_jp Slide 27
  28. 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. 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. 30. なぜ.NET Frameworkのプロジェクト参照が通るのか 理由は主に2点 • 中間言語(CIL)は共通仕様である • ネイティブ呼び出しは元々サポートされている 従って条件を満たせば、.NET Frameworkでビルドしたモジュール も.NET Coreから利用可能です。 Copyright 2019 @nuits_jp Slide 30
  31. 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. 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. 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. 34. To Migration again. Copyright 2019 @nuits_jp Slide 34
  35. 35. 不安視してたけど問題なかった箇所 • ビルドしたDLLの編集(静的コード生成) • TWAIN制御(.NET→COM→Win32 API 32bit driver) • System.Drawing.Bitmapに依存(つまりGDI+に依存) Copyright 2019 @nuits_jp Slide 35
  36. 36. まとめ Copyright 2019 @nuits_jp Slide 36
  37. 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
  38. 38. ThankYou! Any Questions?

Editor's Notes

  • みなさんこんにちは。
    ご紹介いただきました。ニュイこと中村です。
    今日は
    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に統一したほうがよいのではと私は考えています。
  • 以上で私の発表を終わります。
    ご清聴ありがとうございました。

×