More Related Content Similar to Desktop app dev strategy for .net core 3.0 (20) More from Atsushi Nakamura (10) Desktop app dev strategy for .net core 3.02. About Me
Copyright 2019 @nuits_jp Slide 2
中村 充志 / Atsushi Nakamura
• リコージャパン株式会社 金融事業部所属
• Enterprise系SIerのITアーキテクト
• 最近はもっぱらC#er
• アプリケーションアーキテクチャを試行錯誤するのが趣味
• Blog http://www.nuits.jp
• Blog(英語) https://blog.nuits.jp
• Twitter @nuits_jp
9. Desktop App Dev Strategy for .NET Core 3.0
.NET Coreでデスクトップアプリを開発するモチベーションとは?
12. 開発の中心が.NET Coreへシフト
• 開発の中心はすでに.NET Coreへシフト
• .NET Frameworkへのポーティングは後方互換性確保が困難ではない
範囲に限定されつつある
• C#8.0の適用が.NET Frameworkへは部分的になっている
• .NET Frameworkは5.xはもう出ない噂も?
• クラウドは.NET Core一択では?
Copyright 2019 @nuits_jp Slide 12
14. 魅力的な.NET Coreの特徴
• Side by Sideの復活
• Runtimeを同梱して配布可能(たったの60Mぽっち)
• 軽快な動作速度を含む、先進的な機能の採用
ついに.NET Framework 4.0とおさらばだ!(某金融向SIer)
.NET Framework 3.5で頑張らないでいいんですね!涙(某金融向SIer)
Copyright 2019 @nuits_jp Slide 14
16. Desktop App Dev Strategy for .NET Core 3.0
.NET Framework → .NET Core Live Migration
17. Live Migration Menu
• 単純なWPFアプリをMigrationして基本を確認
• 実業務レベルのWPFアプリをMigrationして勘所を整理
Copyright 2019 @nuits_jp Slide 17
21. 対象アプリの特徴
• .NET Framework 4.5.2
• ビルドしたDLLの編集あり〼(PropertyChanged.Fody)
• 大き目な.NET Framework製のサードパーティライブラリあり
• TWAIN制御あり(.NET→COM→Win32 API、32bit driver)
• System.Drawing.Bitmapに依存(つまりGDI+に依存)
Copyright 2019 @nuits_jp Slide 21
23. Point 1
• .NET Framework 4.5.2
• ビルドしたDLLの編集あり〼(PropertyChanged.Fody)
• 大き目な.NET Framework製のサードパーティライブラリあり
• TWAIN制御あり(.NET→COM→Win32 API、32bit driver)
• System.Drawing.Bitmapに依存(つまりGDI+に依存)
Copyright 2019 @nuits_jp Slide 23
• .NET Frameworkでは標準で参照できたパッケージが.NETCore
では標準では参照できない可能性があります。
→ NuGetからパッケージを明示的に適用
24. Point 2
• .NET Framework 4.5.2
• ビルドしたDLLの編集あり〼(PropertyChanged.Fody)
• 大き目な.NET Framework製のサードパーティライブラリあり
• TWAIN制御あり(.NET→COM→Win32 API、32bit driver)
• System.Drawing.Bitmapに依存(つまりGDI+に依存)
Copyright 2019 @nuits_jp Slide 24
• .NET Frameworkの旧世代(どこまでかは不明)のILを編集をして
いたDLLはBatImageExceptionが発生するかも?
→静的コード生成ツールは.NET Standardに対応したものを利用
28. なぜ.NET Frameworkのプロジェクト参照が通るのか
多分こんなイメージ(ちょっと間違ってるかも?
Copyright 2019 @nuits_jp Slide 28
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
29. なぜ.NET Frameworkのプロジェクト参照が通るのか
多分こんなイメージ(ちょっと間違ってるかも?
Copyright 2019 @nuits_jp Slide 29
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
30. なぜ.NET Frameworkのプロジェクト参照が通るのか
多分こんなイメージ(ちょっと間違ってるかも?
Copyright 2019 @nuits_jp Slide 30
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に存在しない
場合、実行時エラーとなります
(Coreでビルドできても実行時エラーになることも)
31. Point 3
• .NET Framework 4.5.2
• ビルドしたDLLの編集あり〼(PropertyChanged.Fody)
• 大き目な.NET Framework製のサードパーティライブラリあり
• TWAIN制御あり(.NET→COM→Win32 API、32bit driver)
• System.Drawing.Bitmapに依存(つまりGDI+に依存)
Copyright 2019 @nuits_jp Slide 31
• .NET Framework製サードパーティライブラリは利用しない
• 自家製.NET Frameworkライブラリは.NETCoreへ移植して動作
検証を済ませてから利用する
32. 不安視してたけど問題なかった箇所
• .NET Framework 4.5.2
• ビルドしたDLLの編集あり〼(PropertyChanged.Fody)
• 大き目な.NET Framework製のサードパーティライブラリあり
• TWAIN制御あり(.NET→COM→Win32 API、32bit driver)
• System.Drawing.Bitmapに依存(つまりGDI+に依存)
Copyright 2019 @nuits_jp Slide 32
34. まとめ
1. プロジェクト移行ツールなどを通す必要がない
→ 変更範囲の把握から死ねる的なことはない
2. 以下の対応だけで動く可能性は大いにある
• .csprojをCore形式に修正
• AssemblyInfo.csを削除
• 参照やファイルコピーなどを移行前と同じように追加
3. .NET Framework製のライブラリは
.NET Coreもしくは.NET Standardへ全て移行推奨
→ 特定の条件下で.NET Core未サポートのAPIを利用している
可能性があり危険
4. API Browserと友達になろう!
https://docs.microsoft.com/ja-jp/dotnet/api/
Copyright 2019 @nuits_jp Slide 34
35. .NET Coreでデスクトップアプリを開発するモチベーションとは?
1. .NET Core 3.0におけるWinForms・WPFのサポート
2. 開発の中心が.NET Coreへシフト
3. 魅力的な.NET Coreの特徴
弊社(私の周辺限定)の場合
• 基本的にサーバーサイドの新規作成サービスは.NETCoreへ移
行中(.NETCore 2.2)
• 既存サーバーサイドサービスも、改修に合わせて移行予定
• デスクトップアプリは技術検証を進めて.NETCore 3.0のGo Live
まち
36. 既存アプリの.NET Core移行はどうすべきか?
• 以下の条件が担保できるなら一括置き換えもありか?
• .NET Coreもしくは.NET Standard対応ですべて揃えられる
• すべてのケースにおいてテスト可能な時間・コストが取れる
• 上記の条件を満たせない場合、アプリケーションの分割を検討
• アプリがモノリシックである事が技術的負債となっている
• .NET Coreの採用関係なく、ユースケースまたはユースケースパッ
ケージ単位でのアプリ分割を進める
• その中で、.NET Coreに移行しやすい箇所から移行を進める
→ Side by SideやRuntime同梱のメリット
Copyright 2019 @nuits_jp Slide 36
Editor's Notes みなさんこんにちは。
ご紹介いただきました。ニュイこと中村です。
今日は
継続的にテスト可能な設計を考える
というTitleでお話しさせていただこうと思います。
よろしくお願いいたします。 まずは自己紹介から
中村充志と申します。
リコージャパン株式会社の金融ソリューション開発部
というところに所属しています。
Enterprise系SIerでITアーキテクトをやらせてもらっています。
さて、本題に入る前に、みなさんに二つほど質問をさせてください。
もうすでに.NET Coreを仕事に使ってるよって方、どの程度いらっしゃいますか? .NET CoreでWPFを動かしてみたよって方はどの程度いますか? ではセッションに入りましょう。 本日は、主に次の二つについてお話したいと思います。
まず初めに、そもそもデスクトップアプリを
なぜ.NET Coreで実装するのか?したいのか?
そのモチベーションについて再確認したいと思います。
その後、実際に.NET Frameworkで作られた
WPFのアプリケーションを.NET Coreに移行しつつ
以降のポイントについてお話したいと思います。
時間の関係上、前者はさらっとお話しして、基本的に後半をじっくりやりたいと思います。 さて、始める前に一点だけお願いがあり〼。 今回お見せするアプリケーションは本物の業務アプリです。
一応弊社の共同著作になっているものですし、デモでお見せすることもよくあるので、お見せすること自体は問題ありません。
ただ、インターネット上に流れているのが目に留まって、弊社内で騒がれると対応が面倒なので、申し訳ありませんがデモアプリの撮影はご遠慮ください。
では早速、本題に入りたいと思います。 デスクトップアプリケーションを.NET Coreで開発したい、その本質的な理由はどこにあるのか?
まずそこからお話ししたいと思います。
私は主に次の3点から、Coreを利用したいと考えています。
①まず第一に、.NET Core 3.0から、WPFやWinFormsがサポートされたということ。
②つぎに、すでにMS側の開発の中心が.NET Frameworkから.NET Coreにシフトしているということ
③最後に.NET Coreが非常に魅力的な特徴を持っているということ
この3点です。
一番目は良いとして、2番以降をもう少し掘り下げてお話ししたいと思います。
まず、開発の中心が.NET Coreにシフトしているという点について 実はすでに.NETの開発の中心は.NET FrameworkからCoreにシフトしています。
現在、.NET Frameworkの開発は、後方互換性の確保が容易なもののみが対象となっていて、Coreにのみ適用されている改修というのが多数あります。
実際、最新のC#8.0では一部の機能は.NET Frameworkへの採用は見送られておいますし、そもそも.NET Frameworkは4.x世代が最後で、5は出ないのではないか?といううわさもあります。
またそうではなくても、クラウドファーストが推進されている現在、クラウドでの利用は.NET Core一択だという現実もあります。 また、Framework側のネガティブな問題だけではなく
そもそもCoreが非常に魅力的だということがあります。
私が特に魅力を感じるところは、次の3点にあります。
①ひとつはSide by Sideが復活し、異なるバージョンを共存して利用できるということ
②二つ目はRuntimeを事前にインストールしておかなくても、
技術的な投資を効率化するうえで、もう今後Frameworkに投資する意味はあまりなく、Coreに集中すべきだというのが私の考えです。
デスクトップアプリケーションを.NET Coreで開発したい、その本質的な理由はどこにあるのか?
まずそこからお話ししたいと思います。
私は主に次の3点から、Coreを利用したいと考えています。
①まず第一に、.NET Core 3.0から、WPFやWinFormsがサポートされたということ。
②つぎに、すでにMS側の開発の中心が.NET Frameworkから.NET Coreにシフトしているということ
③最後に.NET Coreが非常に魅力的な特徴を持っているということ
この3点です。
一番目は良いとして、2番以降をもう少し掘り下げてお話ししたいと思います。
以上で私の発表を終わります。
ご清聴ありがとうございました。