Upload
-
View
726
Download
1
Embed Size (px)
DESCRIPTION
2014/11/29 第7回 業開中心会議 にて https://itmedia.smartseminar.jp/public/seminar/view/663
Citation preview
今から始める、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.0Getter-only auto-propertyExpression bodied functionUsing staticNull-conditional operatorsString interpolationnameofIndex initializersException filtersAwait 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 = ServerStore = Desktopのものに小細工して使ってる
でも、これから.NET Native, Cloud-optimized .NETXamarinとももっと協業して、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 OnlineVS 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
サポートOSLinux, MacAndroid, iOS(Xamarin)
Web ServerIIS
開発環境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 managerShared ProjectT4 templatePCL
ちなみに、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 ServiceApplication InsightsSneak Peak
Web based editing
Build service
Code search
クラウド化
製品にCloudサービスを使うというのはもちろん仮想マシンもAzure VMやAWSに置いたりPaaSを使ったり: SQL Database, Service Bus, HDInsight, Media Services, etc.
自分達のインフラもCloudにVisual Studio OnlineMyGetGitHub
お客様への納品物はだいぶクラウド化したのに、自分のことになると「医者の不摂生」してないか
Microsoft自身も
開発サービスを提供する側だけどもAzure, Office 365 API, OneDrive APIVisual Studio Online
すべてを自社でまかなわないGitHubでソースコード公開BCLパッケージ配布にMyGet※を利用
エコシステム提供3rd パーティ製サービスもAzure StoreのAdd-onsに並べられる
※ NuGetパッケージのホスティング、CIサービス
まとめ
自分達のインフラもクラウド化医者の不摂生になっていないか
すべては一社で完結させない自社の得意のところは自社でそうでないところは外部と連携
Gitは避けて通れないかもGit間の履歴移植は楽らしいので、一度以降してしまえば次は楽かも
全体まとめ
“One .NET”パッケージ化、制御可能な形で個別に素早く提供
Open信用の獲得、コミュニティの形成
Every developers広いターゲット、変えたいときに変えたいモジュールだけ変える
Cloud自社の得意なところは自社で、そうでないところは外部と連携