今から始める、Windows 10＆新.NETへの移行戦略

今から始める、Windows 10＆新
.NETへの移行戦略
岩永信之

本日のテーマ
Windows 10 & .NET 2015を見据えて
 今すぐに対応できること
 .NET 2015までに準備すべきこと
 おすすめの開発指針

まずなによりも、業務系において
 .NETは「変えないこと」の大切さをわかってる
既存のアプリ
既存の.NET
(.NET 4.5)
既存の.NETで動いてたなら
だいたい※動く
.NET vNext
(.NET Core 5)
• 事前Native化
• SIMD演算対応
• モジュール化
• ソースコード配置
既存の.NETの
延長
(.NET 4.6)
.NET 2015世代の新機能
はランタイムの内部で
頑張ってるものが多い
• アプリの変更少なく
• アプリの適用範囲が広がる
※ ReflectionとかInteropとかで変なことしていなければほぼ

あらためて、本日のテーマ
Windows 10 & .NET 2015を見据えて
 今すぐに対応できること
 .NET 2015までに準備すべきこと
 おすすめの開発指針
割と、
「何かやることあったっけ？」
と言いたいレベル
• Microsoftの組織変化
• .NETチームの開発体制変化
.NETを使う側も参考にすべき指針に

キーワード
 “One .NET”
Open
 Every developers
 Cloud

互換性
本題の前に、どう「変わってないか」の話を
「変えないこと」の大切さをわかってる

.NET Frameworkと.NET Core
 .NET 2015
.NET Framework
ASP.NET 5
ASP.NET 4.6
WPF
Windows Forms
.NET Core
ASP.NET 5
.NET Native
Innovation
• モジュール化
• オープンソース
• Agileリリース
• エコシステム
• クロスプラットフォーム
ASP.NET 5 for Mac and Linux
Common
Runtime
Next gen JIT
SIMD
Compilers
.NET Compiler Platform
Language innovation
NuGet packages
.NET Core 5 Libraries
.NET Framework 4.6 Libraries
Compatibility
• 既存デスクトップ
• 既存サーバー
ポイント
既存のものには下
手に手を入れない
ポイント
既存環境にも最新の
アプリ開発モデルをポイント
可能な限り旧環境にも
オープンソースの成果を
pull-req
受付
back porting
とはいえ、4.6どころか…

.NETのサポートOS
OS サポート期限.NETのバージョン
Windows Server 2003
2010/7/13
2.0
R2
2015/7/14
4
Windows 7 / Windows
Server 2008 R2
2015/1/13
2020/1/14
3.5.1
4.6
Windows 8 /
Windows Server 2012
2018/1/9
2023/1/10
4.5
4.6
上段: メインストリーム
下段: 延長
現実的に多そう
なのはこいつ？
上段: 標準インストール
下段: サポートする最新バージョン
業務におかれましては、サポート期限ギリギリのOSで、標準
インストールのバージョンの.NETでないと使えないことも
多々あるかと思われます

VS 2015でも、2.0, 3.5開発できます
古いバージョンのVisual Studioとの共存も可能
今はクライアントOSでもHyper-V動くし
実機開発でも、Visual Studio 2015はWindows 7に入る
「Windows 7だからVisual Studio 2008で開発」とかやめて

.NET 2.0でもC# 6.0使えます
 C# 6.0
 Getter-only auto-property
 Expression bodied function
 Using static
 Null-conditional operators
 String interpolation
 nameof
 Index initializers
 Exception filters
 Await in catch/finally
割と単純な構文糖衣ばっかり
ライブラリ依存の機能なし
.NET 2.0で動く
.NET 4.5で動く
「Windows 7だからC# 3.0」とかやめて

統制
統制取りたいから新機能使わせたくないって？
 Privateな部分にうるさく言ってもしょうがない
 C# 6.0が影響するのはprivateなところばかり
int X(int x)
{
return x * x;
}
メソッドの外から見えてる情報
はここだけ(変わってない)
 ここがレビューしにくいなら、何か別の問題あり
 メソッド1個1個が大きすぎるとか
 変数名がちゃんとついてないとか
int X(int x) => x * x;

まとめ
既存のものは下手に触らず、新しい試み
古い環境向けのアプリも、最新のC#, .NET, Visual Studioで

“One .NET”
「縦割り」の改善
1つのエコシステム

“One”
今年に入ってから、“One”(1つになろう)を標語にしてる
 “One Microsoft”
 縦割り組織の改善
 PC向けOSとモバイル向けOSで社内で争ってる場合じゃない
 1つのOSコアに
 1つの開発モデルに
 1つのストアに
 .NETも“One .NET”

“One .NET” 以前(.NET Framework)
現状: Profileベースのフレームワーク
.NET for
Windows
Desktop
.NET for
Windows
Store
.NET for
Server
BCL※
Runtime
BCL
WinRT
Interop
BCL
Runtime Runtime
• ターゲットごとに違うフレーム
ワーク(大きな赤枠)があって
• 「どのフレームワークならどの
クラスが使える」みたいなルー
ル(Profile)を定めてる
• 1つのインストーラーで全体の
インストール
• 多くのクラスがmscorlib.dllの中
WPF ASP.NET
※ Base Class Library

問題: Profileの種類
現状はまだそこまで多重保守になってない
 Desktop = Server
 Store = Desktopのものに小細工して使ってる
でも、これから
 .NET Native, Cloud-optimized .NET
 Xamarinとももっと協業して、Mac, Linux, iOS, Android
• (小細工でなく真に) 違うものになるかもしれない
• バリエーションも増える
• しかも、あとからどんどん追加で増える可能性も

問題: 全体をまとめて
アップデートが大変
mscorlib
例えば:
System.Xmlに脆弱性が
見つかりました！
全部のアプリがSystem.Xml使ってるわけじゃないけど
• 直接はもう使わないのに…
• 間接的にも使ってない確証得られない…
mscorlibを使っていることには違いないし
• バージョンアップしなきゃ！
• テスト全部やり直し！
• 多大な工数が！

“One .NET” (.NET Core)
 .NET Core 5 Windows
Desktop
Windows
Store Server
WinRT
Interop
WPF ASP.NET
パッケージ管理
(Ecosystem)
BCL
Runtime
Xamarin
.iOS
Xamarin
.Android …
• 細かい単位に分けて、NuGetベース
で必要な分だけ、必要なバージョ
ンを参照
• 利用者がプラットフォーム選択で
あれこれ悩む必要ない
• NuGetパッケージの仕
組みを拡大
• BCLとNuGetパッケージ
とプロジェクトを区別
しない
• 実行環境自体もパッケージ管理の
仕組みを使ってside-by-side配布
one modularity agile in control
目標: 1つのエコシステムの上で、必要とされる部分を、素早く、制御可能な形で提供

“One .NET” になることで
 .NETを利用する側として覚えておくといいのは
 ターゲット指定の改善
 ライブラリ参照管理の改善
 パッケージ単位のコード解析・補完

ターゲット指定(旧): Profile選択ベース
Portable Class Library: ターゲットを自分で選ぶ
共通部分
共通部分
これだけ使える
ターゲットを増やすと
使える部分が減る

ターゲット指定(新): 依存関係ベース
パッケージ管理: 何に依存しているかでターゲットが決まる
System.Runtime
System.Collections.Generic
System.Linq
System.Net.Http
System.Threading.Tasks
Microsoft.Win32.Registry
My App 1
My App 2
どこでもは使えなさそうな
ものを参照すると…
ターゲットに制限がかかる
ターゲット指定は1st パーティ製ライブラリだけがやればよくなるはず

ライブラリ参照(旧): .csprojプロジェクト形式
参照管理の仕組みがバラバラ
BCL参照プロジェクト参照
.csproj内NuGetパッケージ参照
<Reference/>タグ
.csproj内
<ProjectReference/>
タグ
packages.config
+
.csproj 内
<Reference/>タグ

ライブラリ参照(新): .kprojプロジェクト形式
 JSON (project.json)でプロジェクト設定を管理※
"dependencies": {
"Newtonsoft.Json": "",
"System.Console": "",
"Classlibrary1": ""
NuGetパッケージ参照
BCLアセンブリ参照
.sln内プロジェクト参照
}
"4.0.0-beta-22231",
(必要ならバージョン
を明示的に指定)
※ 補完が効くし、ツールチップヒントも出る
GUIでの参照設定もちゃんとできる

区別がなくなることで
例えばこんな開発フローが
1. 作ったアプリの中から共通利用できそうなところ抜き出す
2. 別プロジェクト化
3. それをNuGetパッケージ化して配布
4. 他のプロジェクトでMyGet越しでパッケージ参照
5. 他のプロジェクトからソースコードに手を入れる必要でてきたら
git cloneしてプロジェクト参照
プロジェクト→ NuGetパッケージ化
NuGetパッケージ参照→ プロジェクト参照

パッケージ単位のコード解析・補完
今までの問題: 文脈読まずにコード補完
 例: コードスニペット
依存関係プロパティ
• XAML系プロジェクト
• プロパティが書ける文脈でしか使わないのに
これから: パッケージ単位で配布可能
 .NET Compiler Platformを使って作ったコード解析をNuGet配布
 ライブラリにコード解析を同梱可能
 例えば…
 JSONライブラリに、文字列リテラル中のJSON解析を付ける
常に出る

パッケージ単位のコード解析・補完
NuGet配布の例
自作のコード解析
自作のコード解析
が参照されてる
コード解析が結果
(警告+ 書き替え)

まとめ
全部入りインストーラー→ 個別パッケージ配布に
 制御可能な形で、素早く提供
「パッケージ化」を意識した開発を

Open Source
.NET全体のオープンソース化

.NETのオープンソース化
 .NET全体をオープンソース化※
 .NET Home : 各プロジェクトへのリンクとドキュメント
 .NET Core
 以前からオープンだったもの
 .NET Compiler Platform
 ASP.NET
 Entity Framework
 コミュニティプロジェクトへのリンクも
 Mono Project
 JSON.NET
 …
※ といってもまだ途中。随時公開中

オープンソース化の理由
クロスプラットフォームを維持可能な形で実現
コミュニティの活性化
新しい顧客の取り込み
 既存顧客にとってもコミュニティが広がることはメリット
 「Linuxで動かせるなら.NETをもっと活かせる」という要望は多い

もちろんビジネス構造の変化もあって
Windowsの会社→ Azureの会社
 Azureのデータセンターを使っていただけるなら、その上のOSは
WindowsでもLinuxでも
パッケージ売り→ サービス売り
 Offide 365, Share Point, Dynamicsなどや、Azure上の各種サービスを使って
いただけるなら、クライアントはiOSでもAndroidでも
 Visual Studio Online
 VS Onlineを使っていただけるなら、クライアントはEclipseでもSublimeで
も

日本の業務系でも: 大手にとっても
社内フレームワークが足かせになってはいないか
 同じような機能ならオープンなものに勝てない
 「オープンだから使ったことある」って人の調達と、1から社内フレー
ムワークを覚えてもらうのと、どっちがコスト低いか
 ググって出てこないものを使えない人
 自社で作ったものもOpenな方が外注調達コスト下がってトータルで見
てお得になるかも

日本の業務系でも: 開発者個人にとっても
自分自身の身元保証
 開発者求人とか、とりあえず「コード見せろ」
中小だと法人でも同様、身元保証
 聞いたこともないような会社、中身見えなくて誰が応募するのか

業務系でも現実的なレベルになってきた
Control
 頻繁に更新されると動作保証ができない
 → バージョン管理で「変えない」こともできる
Governance
 誰がコードの責任を持つの？
 → 統制自体はマイクロソフト、.NETチームが責任持ってやってる
 Discoverability
 身元のはっきりしないコードは使えない
 → どこの製品かまで含めて検索できる
こういうソースコード管理、
パッケージ管理、開発工程管理
の仕組みがだいぶ充実してきた

まとめ
オープンソース化
 信用の獲得
 コミュニティの活性化
 いろいろあったオープン化の課題は技術で解決されつつある
 オープン化前提で成り立つビジネスモデルに移行

Every developers
Every applications
.NETをすべての開発者に

多様なアプリケーション
 .NETは元々適用範囲広いし
Server Client
On-premise Cloud
Web Site Web Service
HTTP Sockets
GUI CUI
Stand Alone Connected
Desktop Mobile
Mouse
Keyboard
Touch
Windows
Linux iOS
Mac Android
.NET Micro
Framework
「AかBか？」→ 「AもBも！」
、これからさらに広がる

過渡期
一度大きく振らないと行けないことはある
A B
 新しいチャレンジの際の過渡期
最終的には間に落ち着いたり、両方半々になったり
A AB B A & B
 成熟の証
 結局、全部ほしくなる
この状態に対して
「既存顧客を捨てるのか」とか
「そんなの流行らない」とか
言っちゃダメ
「ほらダメだった」とか
「やっぱり戻ってきた」とか
言っちゃダメ

Windows 8 → 10
Windows 10
 デスクトップ回帰
 エンタープライズ回帰
Mouse
Keyboard
Touch
制限なしWPF
審査付き
セキュアWinRT
エンタープライズ
コンシューマー
WinRT
Windows 10
Windows 10
Windows 8
Windows 8

今はターゲットを広げる時期
協業
 Xamarin, Docker
サポートOS
 Linux, Mac
 Android, iOS(Xamarin)
Web Server
 IIS
開発環境
 Visual Studio, Xamarin Studio, OmniSharp

選べる大事さ: 開発環境
Windows環境
 これからもVisual Studioは非常に強力な開発ツール
 Visual Studio Communityエディション
 非商用、学術・研究向け、オープンソースへの貢献用途には無料提供
非Windows環境
 Xamarin Studio
そもそもIDEみたいな仰々しい仕組みがいやなら
 OmniSharp - Cross platform .NET development
 Sublime, Emacs, Vimなど向けのC#プラグインを提供

補足: Xamarin Studio
VS側最近機能が結構使える※
 NuGet Package manager
 Shared Project
 T4 template
 PCL
(個人の経験で言うと)
Visual Studio以外を全く想定してなくて
割かし最近の機能をふんだんに使って
仕事用のそこそこの規模のソリューションが
普通にMac上でのXamarin Studioでビルド通せた
 ちなみに、C# 6.0は、公式サイトで仕様が出てくるたびに即座に対応
 Discussionに情報が出た数日内にはMonoに関連コミットがあったり
※ むしろLegacyな機能の方が怪しい…
フルパス指定が必要だったり、
パス中のと/ で困ったり

選べる大事さ: Runtime, Webサーバー
ASP.NET 5は階層化、モジュール化された構造
 いろいろ差し替え、選択できる
Runtime (何で.NETコードを実行するか)
.NET Core 5 .NET Framework 4.6 Mono
Web サーバー(何でHTTPを受け付けるか)
IIS (Helios) libuv (Kestrel) 自作(Self-host)
Loader (ソースコードの読み込み)
C#/VB (Roslyn Loader)
自作※
非Windows
※ 例えば、F#サポート用のLoaderのサンプルあり

選べる大事さ: OWIN※
Webサーバーとアプリケーション間のインターフェイス仕様
Func<IDictionary<string, object>, Task>
 環境変数、リクエスト、レスポンスをDictionaryを使ってやり取り
 どのキーにどの値を入れるかを規格化†
 非同期(Task)
 BCL提供の型しか使わない
どこででも、何ででも動く
• Webサーバーが何でもいいのはもちろん
HTTPである必要すらない
• アプリの下にミドルウェア挟むのも楽
※ Open Web Interface for .NET
† objectのままだと使いにくいので、適切なキーで適切な型でとりだせるラッパーライブラリあり(Microsoft.OWIN)

補足: 依存を減らす
フレームワーク、サーバー、OSへの依存を減らす
 (ASP.NET 5みたいな)差し替え可能なモジュール提供
 (OWINみたいな)標準ライブラリのみへの依存
 (MVC, MVVMなどの)分離しやすいアーキテクチャ
 Modelの比率を増やすよう頑張るべき
依存を減らすことで
 幅広いプラットフォーム対応
 変化への対応
依存を減らせる技術は
積極的に取り入れるべき
しなきゃいけない？

補足: 依存を減らす
フレームワーク、サーバー、OSへの依存を減らす
 (ASP.NET 5みたいな)差し替え可能なモジュール提供
 (OWINみたいな)標準ライブラリのみへの依存
 (MVC, MVVMなどの)分離しやすいアーキテクチャ
• 開発者は本音では新しいものを使いたい
• できないのは、入れ替えのコストが高いから
• そのコストが下がるのならば…
 Modelの比率を増やすよう頑張るべき
依存を減らすことで
 幅広いプラットフォーム対応
 変化への対応してもいい！

補足: Taskクラス
 Taskクラス(await/async)は依存切りに使いやすい
 Model中心の設計、Modelの比率向上しやすい
Model
※ StatelessなWebだとこういう処理にはなりにくいものの、
WebSocket使った双方向通信とかだと同じような処理あるはず
Taskクラスなし(イベント駆動)
UI
Click
Model
処理開始
User
void OnClick(sender, args)
View側からのClickイベントで処理を始める
UI
await
処理開始
User Task AwaitClick()
Model側から
Clickイベント待ちをする※
Taskクラス利用

まとめ
今はターゲットを広げる時期
レイヤー化、モジュール化、選べる大切さ
 パーツごとに差し替え可能な構成
 変えたいときに、変えたい場所だけ変える

Cloud
自社の開発にもCloudを
自前で物理的なものを持たない世界

Connect()にて
Connect()での発表のうち、結構な量がVisual Studio Onlineがらみ
 Release Management Service
 Application Insights
 Sneak Peak
 Web based editing
 Build service
 Code search

クラウド化
製品にCloudサービスを使うというのはもちろん
 仮想マシンもAzure VMやAWSに置いたり
 PaaSを使ったり: SQL Database, Service Bus, HDInsight, Media Services, etc.
自分達のインフラもCloudに
 MyGet
 GitHub
お客様への納品物はだいぶクラウド化したのに、
自分のことになると「医者の不摂生」してないか

Microsoft自身も
開発サービスを提供する側だけども
 Azure, Office 365 API, OneDrive API
すべてを自社でまかなわない
 GitHubでソースコード公開
 BCLパッケージ配布にMyGet※ を利用
エコシステム提供
 3rd パーティ製サービスもAzure StoreのAdd-onsに並べられる
※ NuGetパッケージのホスティング、CIサービス

まとめ
自分達のインフラもクラウド化
 医者の不摂生になっていないか
すべては一社で完結させない
 自社の得意のところは自社で
 そうでないところは外部と連携
 Gitは避けて通れないかも
 Git間の履歴移植は楽らしいので、一度以降してしまえば次は楽かも

全体まとめ
 “One .NET”
 パッケージ化、制御可能な形で個別に素早く提供
Open
 信用の獲得、コミュニティの形成
 Every developers
 広いターゲット、変えたいときに変えたいモジュールだけ変える
 Cloud
 自社の得意なところは自社で、そうでないところは外部と連携

今から始める、Windows 10＆新.NETへの移行戦略

More Related Content

今から始める、Windows 10＆新.NETへの移行戦略

Editor's Notes