Mais conteúdo relacionado Semelhante a Visual Studio 2019で始める「WPF on .NET Core 3.0」開発 (20) Mais de Atsushi Nakamura (17) Visual Studio 2019で始める「WPF on .NET Core 3.0」開発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
10. Desktop App Dev Strategy for .NET Core 3.0
WPFを.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
15. 魅力的な.NET Coreの特徴
• Side by Sideの復活
• Runtimeを同梱して配布可能(たったの60Mぽっち)
• 軽快な動作速度を含む、先進的な機能の採用
ついに.NET Framework 4.0とおさらばだ!(某金融向SIer)
.NET Framework 3.5で頑張らないでいいんですね!涙(某金融向SIer)
Copyright 2019 @nuits_jp Slide 15
17. Desktop App Dev Strategy for .NET Core 3.0
.NET Framework → .NET Core Live Migration
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
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
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
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
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 do 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に統一したほうがよいのではと私は考えています。 以上で私の発表を終わります。
ご清聴ありがとうございました。