.NET Core 3.0時代のデスクトップアプリ開発戦略を考える

1. .NET Core 3.0時代の
デスクトップアプリ開発戦略を考える
Desktop App Dev Strategy for .NET Core 3.0
Atsushi Nakamura

2. 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

3. .NET Core 使ってますか？
Copyright 2019 @nuits_jp Slide 3

4. .NET Core 3.0でWPFを動かしてみましたか？
Copyright 2019 @nuits_jp Slide 4

5. Desktop App Dev Strategy for .NET Core 3.0
Overview

6. Overview
Slide 6Copyright 2019 @nuits_jp
本日は主に次の二つについて、お話ししたいと思います。
1. デスクトップ アプリを.NET Coreで開発するモチベーションとは？
2. 実業務アプリを実際に.NET CoreにLive Migration

7. Desktop App Dev Strategy for .NET Core 3.0
おねがい

8. ライブ マイグレーション対象は、実業務で利用しているものです。
そこだけは撮影をご遠慮ください。
おねがい

9. Desktop App Dev Strategy for .NET Core 3.0
.NET Coreでデスクトップアプリを開発するモチベーションとは？

10. .NET Coreでデスクトップアプリを開発するモチベーションとは？
1. .NET Core 3.0におけるWinForms・WPFのサポート
2. 開発の中心が.NET Coreへシフト
3. 魅力的な.NET Coreの特徴

11. デスクトップ アプリを.NET Coreで開発するモチベーションとは？
1. .NET Core 3.0におけるWinForms・WPFのサポート
2. 開発の中心が.NET Coreへシフト
3. 魅力的な.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

13. デスクトップ アプリを.NET Coreで開発するモチベーションとは？
1. .NET Core 3.0におけるWinForms・WPFのサポート
2. 開発の中心が.NET Coreへシフト
3. 魅力的な.NET Coreの特徴

14. 魅力的な.NET Coreの特徴
• Side by Sideの復活
• Runtimeを同梱して配布可能（たったの60Mぽっち）
• 軽快な動作速度を含む、先進的な機能の採用
ついに.NET Framework 4.0とおさらばだ！（某金融向SIer）
.NET Framework 3.5で頑張らないでいいんですね！涙（某金融向SIer）
Copyright 2019 @nuits_jp Slide 14

15. で、.NETCoreでWPFって現実的なの？
Copyright 2019 @nuits_jp Slide 15

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

18. Let’s Migration!
Copyright 2019 @nuits_jp Slide 18

19. 最もシンプルなMigration
1. .csprojを.NET Core形式に修正
2. AssemblyInfo.csを削除
3. ビルド時にコピーする設定をしていたファ
イルなどを再設定するのを忘れずに
Copyright 2019 @nuits_jp Slide 19

20. 実業務レベルのアプリをMigration
Copyright 2019 @nuits_jp Slide 20

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

22. Let’s Migration!
Copyright 2019 @nuits_jp Slide 22

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に対応したものを利用

25. ちょっと待って！
Copyright 2019 @nuits_jp Slide 25

26. なんで.NET Frameworkプロジェクトを参照できるの？？
Copyright 2019 @nuits_jp Slide 26

27. なぜ.NET Frameworkのプロジェクト参照が通るのか
実はWPFやWinFormsが移植できた理由がここにあります。
理由は主に2点
• ILは共通仕様である
• DllImportはもともとサポートされている
System.IO.Fileなどを例に考えると理解しやすい。
Copyright 2019 @nuits_jp Slide 27

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

33. まとめ
Copyright 2019 @nuits_jp Slide 33

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

37. ThankYou!
Any Questions?