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

岩永信之

本日のテーマ

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

まずなによりも、業務系において

.NETは「変えないこと」の大切さをわかってる

既存の.NET

(.NET 4.5).NET vNext

(.NET Core 5)

既存のアプリ

既存の.NETで動いてたならだいたい※動く

• 事前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 FrameworkASP.NET 5ASP.NET 4.6WPFWindows Forms

.NET CoreASP.NET 5.NET Native

ASP.NET 5 for Mac and Linux

CommonRuntimeNext gen JITSIMD

Compilers.NET Compiler PlatformLanguage innovation

NuGet packages.NET Core 5 Libraries.NET Framework 4.6 Libraries

Innovation• モジュール化• オープンソース• Agileリリース• エコシステム• クロスプラットフォーム

Compatibility• 既存デスクトップ• 既存サーバー

ポイント既存のものには下手に手を入れない

ポイント既存環境にも最新のアプリ開発モデルを ポイント

可能な限り旧環境にもオープンソースの成果を

pull-req受付

back porting

とはいえ、4.6どころか…

.NETのサポートOS

OS サポート期限 .NETのバージョン

Windows Server 2003 R2

2010/7/132015/7/14

2.04

Windows 7 / WindowsServer 2008 R2

2015/1/132020/1/14

3.5.14.6

Windows 8 /Windows Server 2012

2018/1/92023/1/10

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

「Windows 7だからC# 3.0」とかやめて

.NET 2.0で動く

.NET 4.5で動く

割と単純な構文糖衣ばっかりライブラリ依存の機能なし

統制

統制取りたいから新機能使わせたくないって？

Privateな部分にうるさく言ってもしょうがない C# 6.0が影響するのはprivateなところばかり

ここがレビューしにくいなら、何か別の問題あり メソッド1個1個が大きすぎるとか

変数名がちゃんとついてないとか

int X(int x){

return x * x;}

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 forWindowsDesktop

.NET forWindows

Store

.NET forServer

Runtime

BCL※

BCL

RuntimeRuntime

BCL

• ターゲットごとに違うフレームワーク(大きな赤枠)があって

• 「どのフレームワークならどのクラスが使える」みたいなルール(Profile)を定めてる

• 1つのインストーラーで全体のインストール

• 多くのクラスがmscorlib.dllの中

WPF ASP.NETWinRTInterop

※ 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 5WindowsDesktop

WindowsStore Server

パッケージ管理

(Ecosystem)

Runtime

BCL

WPF ASP.NETWinRTInterop

Xamarin.iOS

Xamarin.Android …

• 細かい単位に分けて、NuGetベースで必要な分だけ、必要なバージョンを参照

• 利用者がプラットフォーム選択であれこれ悩む必要ない

• NuGetパッケージの仕組みを拡大

• BCLとNuGetパッケージとプロジェクトを区別しない

• 実行環境自体もパッケージ管理の仕組みを使ってside-by-side配布

目標: 1つのエコシステムの上で、必要とされる部分を、素早く、制御可能な形で提供

one modularity agile in control

“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参照 プロジェクト参照

NuGetパッケージ参照.csproj内<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パッケージ参照→ プロジェクト参照

パッケージ単位のコード解析・補完

今までの問題: 文脈読まずにコード補完例:コードスニペット

これから:パッケージ単位で配布可能 .NET Compiler Platformを使って作ったコード解析をNuGet配布ライブラリにコード解析を同梱可能例えば…

JSONライブラリに、文字列リテラル中のJSON解析を付ける

依存関係プロパティ• XAML系プロジェクト• プロパティが書ける文脈 でしか使わないのに

常に出る

パッケージ単位のコード解析・補完

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 developersEvery applications.NETをすべての開発者に

多様なアプリケーション

.NETは元々適用範囲広いし

Server Client

On-premise Cloud

Web Site Web Service

HTTP Sockets

MouseKeyboard

Touch

GUI CUI

Desktop Mobile

Stand Alone Connected

Windows

Linux iOS

Mac Android

.NET Micro Framework

「AかBか？」→ 「AもBも！」

、これからさらに広がる

過渡期

一度大きく振らないと行けないことはある

新しいチャレンジの際の過渡期

最終的には間に落ち着いたり、両方半々になったり

成熟の証結局、全部ほしくなる

A B

A B&A BAB

この状態に対して「既存顧客を捨てるのか」とか「そんなの流行らない」とか

言っちゃダメ

「ほらダメだった」とか「やっぱり戻ってきた」とか

言っちゃダメ

Windows 8 → 10

Windows 10デスクトップ回帰エンタープライズ回帰

MouseKeyboard

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

ちなみに、C# 6.0は、公式サイトで仕様が出てくるたびに即座に対応 Discussionに情報が出た数日内にはMonoに関連コミットがあったり

※むしろLegacyな機能の方が怪しい…フルパス指定が必要だったり、パス中の \と /で困ったり

(個人の経験で言うと)Visual Studio以外を全く想定してなくて割かし最近の機能をふんだんに使って仕事用のそこそこの規模のソリューションが普通にMac上でのXamarin Studioでビルド通せた

選べる大事さ: Runtime, Webサーバー

ASP.NET 5は階層化、モジュール化された構造いろいろ差し替え、選択できる

.NET Core 5 .NET Framework 4.6 Mono

Runtime (何で.NETコードを実行するか)

IIS (Helios) libuv (Kestrel) 自作 (Self-host)

Webサーバー(何でHTTPを受け付けるか)

C#/VB (Roslyn Loader)

Loader (ソースコードの読み込み)

自作※

※例えば、F#サポート用のLoaderのサンプルあり

非Windows

選べる大事さ: OWIN※

Webサーバーとアプリケーション間のインターフェイス仕様

環境変数、リクエスト、レスポンスをDictionaryを使ってやり取り どのキーにどの値を入れるかを規格化†

非同期(Task) BCL提供の型しか使わない

† objectのままだと使いにくいので、適切なキーで適切な型でとりだせるラッパーライブラリあり(Microsoft.OWIN)

Func<IDictionary<string, object>, Task>

どこででも、何ででも動く• Webサーバーが何でもいいのはもちろん

HTTPである必要すらない• アプリの下にミドルウェア挟むのも楽

※ Open Web Interface for .NET

補足: 依存を減らす

フレームワーク、サーバー、OSへの依存を減らす (ASP.NET 5みたいな)差し替え可能なモジュール提供 (OWINみたいな)標準ライブラリのみへの依存 (MVC, MVVMなどの)分離しやすいアーキテクチャ

Modelの比率を増やすよう頑張るべき

依存を減らすことで幅広いプラットフォーム対応変化への対応

依存を減らせる技術は積極的に取り入れるべき

しなきゃいけない？

補足: 依存を減らす

フレームワーク、サーバー、OSへの依存を減らす (ASP.NET 5みたいな)差し替え可能なモジュール提供 (OWINみたいな)標準ライブラリのみへの依存 (MVC, MVVMなどの)分離しやすいアーキテクチャ

Modelの比率を増やすよう頑張るべき

依存を減らすことで幅広いプラットフォーム対応変化への対応してもいい！

• 開発者は本音では新しいものを使いたい• できないのは、入れ替えのコストが高いから• そのコストが下がるのならば…

補足: Taskクラス

Taskクラス(await/async)は依存切りに使いやすい Model中心の設計、Modelの比率向上しやすい

※ StatelessなWebだとこういう処理にはなりにくいものの、WebSocket使った双方向通信とかだと同じような処理あるはず

UI

Click処理開始

Model

User

void OnClick(sender, args)

View側からのClickイベントで処理を始める

Taskクラスなし(イベント駆動)

UI

await

処理開始

Model

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に Visual Studio Online MyGet GitHub

お客様への納品物はだいぶクラウド化したのに、自分のことになると「医者の不摂生」してないか

Microsoft自身も

開発サービスを提供する側だけども Azure, Office 365 API, OneDrive API Visual Studio Online

すべてを自社でまかなわない GitHubでソースコード公開 BCLパッケージ配布にMyGet※を利用

エコシステム提供 3rd パーティ製サービスもAzure StoreのAdd-onsに並べられる

※ NuGetパッケージのホスティング、CIサービス

まとめ

自分達のインフラもクラウド化医者の不摂生になっていないか

すべては一社で完結させない自社の得意のところは自社でそうでないところは外部と連携

Gitは避けて通れないかも Git間の履歴移植は楽らしいので、一度以降してしまえば次は楽かも

全体まとめ

“One .NET”パッケージ化、制御可能な形で個別に素早く提供

Open信用の獲得、コミュニティの形成

Every developers広いターゲット、変えたいときに変えたいモジュールだけ変える

Cloud自社の得意なところは自社で、そうでないところは外部と連携