Weitere ähnliche Inhalte Ähnlich wie 今から始める、Windows 10&新.NETへの移行戦略 (20) Kürzlich hochgeladen (11) 今から始める、Windows 10&新.NETへの移行戦略3. まずなによりも、業務系において
.NETは「変えないこと」の大切さをわかってる
既存のアプリ
既存の.NET
(.NET 4.5)
既存の.NETで動いてたなら
だいたい※動く
.NET vNext
(.NET Core 5)
• 事前Native化
• SIMD演算対応
• モジュール化
• ソースコード配置
既存の.NETの
延長
(.NET 4.6)
.NET 2015世代の新機能
はランタイムの内部で
頑張ってるものが多い
• アプリの変更少なく
• アプリの適用範囲が広がる
※ ReflectionとかInteropとかで変なことしていなければほぼ
4. あらためて、本日のテーマ
Windows 10 & .NET 2015を見据えて
今すぐに対応できること
.NET 2015までに準備すべきこと
おすすめの開発指針
割と、
「何かやることあったっけ?」
と言いたいレベル
• Microsoftの組織変化
• .NETチームの開発体制変化
.NETを使う側も参考にすべき指針に
7. .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どころか…
8. .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でないと使えないことも
多々あるかと思われます
9. VS 2015でも、2.0, 3.5開発できます
古いバージョンのVisual Studioとの共存も可能
今はクライアントOSでもHyper-V動くし
実機開発でも、Visual Studio 2015はWindows 7に入る
「Windows 7だからVisual Studio 2008で開発」とかやめて
10. .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」とかやめて
15. “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
16. 問題: Profileの種類
現状はまだそこまで多重保守になってない
Desktop = Server
Store = Desktopのものに小細工して使ってる
でも、これから
.NET Native, Cloud-optimized .NET
Xamarinとももっと協業して、Mac, Linux, iOS, Android
• (小細工でなく真に) 違うものになるかもしれない
• バリエーションも増える
• しかも、あとからどんどん追加で増える可能性も
17. 問題: 全体をまとめて
アップデートが大変
mscorlib
例えば:
System.Xmlに脆弱性が
見つかりました!
全部のアプリがSystem.Xml使ってるわけじゃないけど
• 直接はもう使わないのに…
• 間接的にも使ってない確証得られない…
mscorlibを使っていることには違いないし
• バージョンアップしなきゃ!
• テスト全部やり直し!
• 多大な工数が!
18. “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つのエコシステムの上で、必要とされる部分を、素早く、制御可能な形で提供
19. “One .NET” になることで
.NETを利用する側として覚えておくといいのは
ターゲット指定の改善
ライブラリ参照管理の改善
パッケージ単位のコード解析・補完
21. ターゲット指定(新): 依存関係ベース
パッケージ管理: 何に依存しているかでターゲットが決まる
System.Runtime
System.Collections.Generic
System.Linq
System.Net.Http
System.Threading.Tasks
Microsoft.Win32.Registry
My App 1
My App 2
どこでもは使えなさそうな
ものを参照すると…
ターゲットに制限がかかる
ターゲット指定は1st パーティ製ライブラリだけがやればよくなるはず
23. ライブラリ参照(新): .kprojプロジェクト形式
JSON (project.json)でプロジェクト設定を管理※
"dependencies": {
"Newtonsoft.Json": "",
"System.Console": "",
"Classlibrary1": ""
NuGetパッケージ参照
BCLアセンブリ参照
.sln内プロジェクト参照
}
"4.0.0-beta-22231",
(必要ならバージョン
を明示的に指定)
※ 補完が効くし、ツールチップヒントも出る
GUIでの参照設定もちゃんとできる
24. 区別がなくなることで
例えばこんな開発フローが
1. 作ったアプリの中から共通利用できそうなところ抜き出す
2. 別プロジェクト化
3. それをNuGetパッケージ化して配布
4. 他のプロジェクトでMyGet越しでパッケージ参照
5. 他のプロジェクトからソースコードに手を入れる必要でてきたら
git cloneしてプロジェクト参照
プロジェクト→ NuGetパッケージ化
NuGetパッケージ参照→ プロジェクト参照
25. パッケージ単位のコード解析・補完
今までの問題: 文脈読まずにコード補完
例: コードスニペット
依存関係プロパティ
• XAML系プロジェクト
• プロパティが書ける文脈でしか使わないのに
これから: パッケージ単位で配布可能
.NET Compiler Platformを使って作ったコード解析をNuGet配布
ライブラリにコード解析を同梱可能
例えば…
JSONライブラリに、文字列リテラル中のJSON解析を付ける
常に出る
29. .NETのオープンソース化
.NET全体をオープンソース化※
.NET Home : 各プロジェクトへのリンクとドキュメント
.NET Core
以前からオープンだったもの
.NET Compiler Platform
ASP.NET
Entity Framework
コミュニティプロジェクトへのリンクも
Mono Project
JSON.NET
…
※ といってもまだ途中。随時公開中
31. もちろんビジネス構造の変化もあって
Windowsの会社→ Azureの会社
Azureのデータセンターを使っていただけるなら、その上のOSは
WindowsでもLinuxでも
パッケージ売り→ サービス売り
Offide 365, Share Point, Dynamicsなどや、Azure上の各種サービスを使って
いただけるなら、クライアントはiOSでもAndroidでも
Visual Studio Online
VS Onlineを使っていただけるなら、クライアントはEclipseでもSublimeで
も
34. 業務系でも現実的なレベルになってきた
Control
頻繁に更新されると動作保証ができない
→ バージョン管理で「変えない」こともできる
Governance
誰がコードの責任を持つの?
→ 統制自体はマイクロソフト、.NETチームが責任持ってやってる
Discoverability
身元のはっきりしないコードは使えない
→ どこの製品かまで含めて検索できる
こういうソースコード管理、
パッケージ管理、開発工程管理
の仕組みがだいぶ充実してきた
37. 多様なアプリケーション
.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も!」
、これからさらに広がる
38. 過渡期
一度大きく振らないと行けないことはある
A B
新しいチャレンジの際の過渡期
最終的には間に落ち着いたり、両方半々になったり
A AB B A & B
成熟の証
結局、全部ほしくなる
この状態に対して
「既存顧客を捨てるのか」とか
「そんなの流行らない」とか
言っちゃダメ
「ほらダメだった」とか
「やっぱり戻ってきた」とか
言っちゃダメ
39. Windows 8 → 10
Windows 10
デスクトップ回帰
エンタープライズ回帰
Mouse
Keyboard
Touch
制限なしWPF
審査付き
セキュアWinRT
エンタープライズ
コンシューマー
WinRT
Windows 10
Windows 10
Windows 8
Windows 8
40. 今はターゲットを広げる時期
協業
Xamarin, Docker
サポートOS
Linux, Mac
Android, iOS(Xamarin)
Web Server
IIS
開発環境
Visual Studio, Xamarin Studio, OmniSharp
41. 選べる大事さ: 開発環境
Windows環境
これからもVisual Studioは非常に強力な開発ツール
Visual Studio Communityエディション
非商用、学術・研究向け、オープンソースへの貢献用途には無料提供
非Windows環境
Xamarin Studio
そもそもIDEみたいな仰々しい仕組みがいやなら
OmniSharp - Cross platform .NET development
Sublime, Emacs, Vimなど向けのC#プラグインを提供
42. 補足: Xamarin Studio
VS側最近機能が結構使える※
NuGet Package manager
Shared Project
T4 template
PCL
(個人の経験で言うと)
Visual Studio以外を全く想定してなくて
割かし最近の機能をふんだんに使って
仕事用のそこそこの規模のソリューションが
普通にMac上でのXamarin Studioでビルド通せた
ちなみに、C# 6.0は、公式サイトで仕様が出てくるたびに即座に対応
Discussionに情報が出た数日内にはMonoに関連コミットがあったり
※ むしろLegacyな機能の方が怪しい…
フルパス指定が必要だったり、
パス中の と/ で困ったり
43. 選べる大事さ: 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のサンプルあり
44. 選べる大事さ: OWIN※
Webサーバーとアプリケーション間のインターフェイス仕様
Func<IDictionary<string, object>, Task>
環境変数、リクエスト、レスポンスをDictionaryを使ってやり取り
どのキーにどの値を入れるかを規格化†
非同期(Task)
BCL提供の型しか使わない
どこででも、何ででも動く
• Webサーバーが何でもいいのはもちろん
HTTPである必要すらない
• アプリの下にミドルウェア挟むのも楽
※ Open Web Interface for .NET
† objectのままだと使いにくいので、適切なキーで適切な型でとりだせるラッパーライブラリあり(Microsoft.OWIN)
45. 補足: 依存を減らす
フレームワーク、サーバー、OSへの依存を減らす
(ASP.NET 5みたいな)差し替え可能なモジュール提供
(OWINみたいな)標準ライブラリのみへの依存
(MVC, MVVMなどの)分離しやすいアーキテクチャ
Modelの比率を増やすよう頑張るべき
依存を減らすことで
幅広いプラットフォーム対応
変化への対応
依存を減らせる技術は
積極的に取り入れるべき
しなきゃいけない?
46. 補足: 依存を減らす
フレームワーク、サーバー、OSへの依存を減らす
(ASP.NET 5みたいな)差し替え可能なモジュール提供
(OWINみたいな)標準ライブラリのみへの依存
(MVC, MVVMなどの)分離しやすいアーキテクチャ
• 開発者は本音では新しいものを使いたい
• できないのは、入れ替えのコストが高いから
• そのコストが下がるのならば…
Modelの比率を増やすよう頑張るべき
依存を減らすことで
幅広いプラットフォーム対応
変化への対応してもいい!
47. 補足: 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クラス利用
51. クラウド化
製品にCloudサービスを使うというのはもちろん
仮想マシンもAzure VMやAWSに置いたり
PaaSを使ったり: SQL Database, Service Bus, HDInsight, Media Services, etc.
自分達のインフラもCloudに
Visual Studio Online
MyGet
GitHub
お客様への納品物はだいぶクラウド化したのに、
自分のことになると「医者の不摂生」してないか
52. Microsoft自身も
開発サービスを提供する側だけども
Azure, Office 365 API, OneDrive API
Visual Studio Online
すべてを自社でまかなわない
GitHubでソースコード公開
BCLパッケージ配布にMyGet※ を利用
エコシステム提供
3rd パーティ製サービスもAzure StoreのAdd-onsに並べられる
※ NuGetパッケージのホスティング、CIサービス
54. 全体まとめ
“One .NET”
パッケージ化、制御可能な形で個別に素早く提供
Open
信用の獲得、コミュニティの形成
Every developers
広いターゲット、変えたいときに変えたいモジュールだけ変える
Cloud
自社の得意なところは自社で、そうでないところは外部と連携
Hinweis der Redaktion 「元々打診を受けているテーマとしては」…なのだけども… 業務系の人に対してこれだけは最初に言わないといけないけども、ほんと、変えたくないなら変えなくていい。不連続のない開発体験。
「だいたい」ってのは、例えば、「.NET Native相手だと極端なReflectionコードは動かないことがまれにある」とか「Win32呼び出しとかしてると.NETの範疇外だしどこでもは動かないよ」とか、そういうレベル。 「元々打診を受けているテーマとしては」…なのだけども…
「指針」の話が中心になるかなぁと そんな最先端な話題でもなくて。
ツールとかプラクティス化が充実してきて、ちょっと前だったら小規模にしかできなかったことが、大規模にできるようになってきた。
こなれてきた。何せ、もはや、GitHubすら設立から6年とか経ってる(2008年設立)。 この辺り、近々サンプルをgithubに上げると思う。
厳密には、string interpolationのカルチャー指定可能なバージョンの文法が4.6以降専用になると思う(System.Runtime.CompilerServices.FormattedString依存)。
あと、Await in catch/finallyは.NET 4 + Bcl.Async (拡張ライブラリ)でも動く。 どっちでもいい。性能が変わらない限り、書いてる本人の好みで書かせて上げて。
で、C# 6.0の各種新文法はほんと性能も変わらないものばっかり。
もちろん、「知らないだけの人に教えてあげる」スタンスはいいんだけど。知ってて使ってない人に強制しても仕方ない。 Client Profileがある程度。Full .NET Frameworkと比べると完全なサブセット。 いつまでたっても古いバージョンから抜けれない理由もこれ。
新機能使いってだけで、バージョンは上げれない。業務だと、バージョン上げると全行程テストし直しとかで大変なんでしょ。 これまでも、この方向に向かう傾向はあった
MS公式提供品もオープンソース開発、個別NuGet配布してたり(System.Collections.Immutable, System.Reflection.Metadata, System.Numerics.Vectors, System.Reactive, System.Net.Http)
MS外のライブラリを推したり(Json.NET)
具体的な手順は別途たぶんブログ化する。
kpm build でライブラリ .kproj を .nupkg 化できる
NuGet参照をプロジェクト参照に切り替えるのは、global.jsonのパス指定書き替える or コピペでsrcフォルダー以下にソースコード持ってくるだけ 今年一番のニュースかもね
http://blogs.msdn.com/b/somasegar/archive/2014/11/12/opening-up-visual-studio-and-net-to-every-developer-any-application-net-server-core-open-source-and-cross-platform-visual-studio-community-2013-and-preview-of-visual-studio-2015-and-net-2015.aspx
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
http://blogs.msdn.com/b/dotnet/archive/2014/11/20/one-week-of-open-source.aspx 長期的に見てその方がもうかる算段なしでオープンソース化とかやらない。
といっても、日本だとOEM売りが強すぎてサブスクリプション型の収益への移行遅れがちみたいだけども。 ここ数年言われ続けてることだけども。 一時期、HTML5全振りな感じだったけども、今また結構.NETが面白い時期になってきた。
まあいったん、非Windows環境にかなり注力するフェーズになるとは思うけど、Windowsを捨てるのかみたいなことにはならないと思う。
これも、ダメだったから戻ってきたんじゃなくて、大きく振らなきゃいけなかった過渡期を過ぎた。「両方」をやれる時期に来た。
ちなみに、.NET 2015世代には、WPFのアップデートもある。 仕事用のソリューション: 社外の人との協業。外注先がMacだった。Windows機買ってもらう前にtryしてみたとか。
C# 6.0: コンパイラー担当してる人が結構仕事早いみたい
libuv: Node.jsが使ってるクロスプラットフォームなWeb Serverライブラリ HTTPである必要すらない: ゲームとかのインタラクティブな通信で、「最初とりあえずHTTP long pollingでさらっと作っちゃって、パフォーマンス的に厳しそうなら自前でTCPで通信層書こう」とかもできる
ミドルウェア挟むのも楽: ルーティングの分岐とかも楽。新旧フレームワーク混在で、あるフォルダー以下は新フレームワークで処理、みたいなことも書くの楽。段階移行とかもしやすいはず。 依存を減らす技術: データアクセス層技術で poco (Javaでいう pojo) が受けるのもそういう事情。Plain = 何にも依存してない。
幅広いプラットフォーム: 例えばの話、Webゲーからスマホゲーへの時代の変化についていけずに大変なことになってる会社もあるわけで。差し替えで別プラットフォームに移行できるってので、レイヤー化・モジュール化された構成大事
業務系のWebだって、「あの技術もう古臭いから死んでほしい…」とかぼやきながら「枯れた技術」を使い続けるわけで。 まあまだまだ「理想は」だと思うけども。
着実に進歩はしていってると思う。 2枚前のスライドで見ての通り、OWINのFuncの戻り値がTask。OWINでも、戻り値がTaskってのがポイント高くて。 http://blogs.msdn.com/b/bharry/archive/2014/11/12/news-from-connect.aspx
オープンソースに紛れ気味だけども、Connect()での発表、結構な分量がVSOがらみ。 TracとかJenkins、Gitとか使った開発管理サービスを提供してるところ結構あるし。「CIサービス」とかで検索すると出てくるサービス増えた。 あと、サービス間連携とか。VSO自体API公開してて、他のサービスが参照できる