dotNetConf 2015 Japan 参加レポート【前編】
クロスワープの大鷲です。
去る 4/11 の土曜日、日本マイクロソフト 品川本社にて開催された dotNetConf 2015 Japan に参加してきました。
「.NET 2015」と呼ばれる一連の新しいテクノロジーに関するセッションが目白押しの一日でした。
遅ればせながら、今回はその感想などをつらつらと。
なお、黄色の文字は、当日のセッション中で言及されなかった内容を私が補足したり、感じたことを述べたりしている部分です。
Opening: .NET 2015 の全体像
スピーカーは日本マイクロソフト 井上章さん（Blog/Twitter）。
2002 年の .NET
最初に、2002 年、.NET という言葉が出始めた頃のマイクロソフト（当時は社名に「日本」とついていませんでした）のテレビ CM が紹介されました。
探したのですが、YouTube には動画が無いようです。
内容は、車を買いに来ていた顧客が、赤がいい、いややっぱり黒がいいという注文をディーラーに出すと、即座に工場に連絡が行って塗り替えが行われるというようなもの。
デバイスやクラウドといった言葉は出てきませんが、コンセプト的にはそれほど古びてはいないとは井上さんの談。
当時は .NET というネーミングからもわかるように、あらゆるアプリケーションが（SOAP による XML Web サービスを通じて）インターネット対応になるというような未来像が謳われていました。
特集：.NET Framework入門 - ＠IT
特集：Microsoft.NETが目指す次世代情報環境とは？（1/6） - ＠IT
具体的な技術はだいぶ変わりましたが、2015 年になって IoT が注目されてくるなど、やっと時代が追いついてきたと言ったところでしょうか。
マイクロソフトの方向性の変化
最近のマイクロソフトは「あらゆるアプリケーション」を開発するためのツールを提供しているとのことでした。
確かに、Windows 用だけでなく、.NET Core 5 は Linux / MacOS でも動く（のを目指している）し、Unity や Cordova によってクロスプラットフォーム アプリを開発するためのツールも提供しています。
また、Xamarin とも緊密に連携しています。
マイクロソフトの 3 代目 CEO であるサティア・ナデラは昨年、「Microsoftのビジネスとは他の人々にソフトウェアなどのプロダクトを開発する力を与えるところにある」と発言していますが、その言葉を体現しているようです。
次期 .NET Framework
次期 .NET Framework は、現行の .NET Framework 4.5 の延長線上にあり、Windows 専用である .NET Framework 4.6 と、全く新しいクロスプラットフォームの .NET Core 5 の 2 本立てで提供されます。
.NET Framework 4.6 は現在のバージョンとの互換性が確保されていますが、.NET Core 5 はそうではありません。
また、4.6 はおそらく、OS にプリインストールされるか、インストーラーが提供されると思いますが、Core 5 は、中核部分まで含めて、すべて NuGet で提供されるとのことでした。
ASP.NET 5 (MVC, Web API, Web Pages, SignalR)
ASP.NET 5 の、ランタイム等の深いところではなく、Web エンジニアが直接触るであろうアプリケーション層のお話でした。
いろいろとオープンに
.NET Framework がオープンソース路線に大きく舵を切ったのはニュースになりましたが、それ以外にもいろいろとオープンですよというお話。
ASP.NET 5 チームは YouTube に多数の動画を公開していますし、フォーラムも、英語だからこそフランクに書ける部分もあるので、参加してみてはどうでしょう、とのことでした。
K → X
これまで次期 ASP.NET には何かと「k」という文字がつく名前が多かったのですが、これが「x」に変わりました。
この k は katana （Microsoft による OWIN 実装） に由来するわけですが、MS が OWIN への注力を辞めたことの影響もあるでしょう。
このあたりの話は、芝村さんのセッションでより詳しく取り上げられますので、割愛させて頂きます。
ASP.NET 5
ASP.NET 5 は .NET Framework 4.6 と .NET Core 5 のどちらでも動きます。
ただし、Web Forms は .NET 4.6 でしかサポートされません。
また、Web Forms 以外の部分は MVC6 と呼ばれますが、これは ASP.NET MVC だけでなく、従来の Web API や Web Pages も含んだ、一種のブランドネームとなりました。
ASP.NET 5 = MVC6 (MVC + Web API + Web Pages) + Web Forms 4.6 + SignalR といったところでしょうか。
VB.NET はサポートされていないそうですが、現在はまだベータ版だからなのか、製品版でもサポートしないのかはわかりません。
また、プロジェクト構成も大きく変わりました。
プロジェクト ファイルは *.xproj というファイル（以前は *.kproj）ですが、これには、アセンブリの参照設定や、プロジェクトにどのようなファイルが含まれているかは書かれていません。
プロジェクト ディレクトリ内にファイルをコピーするだけで VS が自動的に検出して、ソリューション エクスプローラーに表示される様子がデモされました。
それでは意図しないファイルもアプリケーションに含んでしまうのではないかと思いますが、HTML や CSS、JavaScript といった静的コンテンツは wwwroot というフォルダーに入れないと Web サーバーから認識されないようになったとのことでした。
参照設定のやり方も変わりました。
これまではまず NuGet で参照を追加していましたが、今後は、project.json というファイルに書けば、その実体がどこ（ローカルなのか NuGet なのか npm や bower なのか）は VS が自動的に判断してくれるようです（もちろんインテリセンスは効きます）。
その参照先は global.json というファイルに書いておく必要があるようです。
こういったファイルを更新しても、プロジェクトをリロードしなくてよくなったのは、ストレスの軽減効果があると思います。
CLR もすべてオープンソースで提供されているので、GitHub からソースをクローンしてきてローカルディレクトリに置き、project.json を少し書き換えるだけで、コア部分のデバッグ実行や、自分用に一部カスタムした CLR を作ることもできるとのことでした。
MVC6
大きな変更点としては、コントローラーが Controller クラスから派生しなくても、***Controller という名前になっていればよいという方式になりました（設定より規約）。
Web API では、メソッド名が Get で始まるものが HTTP GET に対応するというルールは廃止されました。
コンテント ネゴシエーション（同一の内容を異なる形式で提供すること）も変更され、これまで MediaTypeFormatter でやっていた内容が、入力と出力で区別され、それぞれ IInputFormatter と IOutputFormatter というインターフェイスに分離されました。
また、JSON フォーマッターはデフォルトで含まれますが、XML フォーマッターは含まれなくなりました（簡単なコード一行で追加することはできます）。
text/plain 形式が既定でサポートされるようになりました。
View Components
これまで Partial View とか Html.RenderAction で実現していた UI の部品化を推し進めたものです。
これまでの方法では結局、UI 部品用にコントローラーのコードを書かなければなりませんでしたが、それも含めて部品化し別ディレクトリに切り出したことで、部品の再配布が容易になりました（というのが意義だと理解しています）。
Tag Helper
これまで ASP.NET MVC で動的なタグは @Html.Action("Link", "action", "controller") というようなコードで書いていましたが、これを、より自然なタグ形式で書けるようになります。
具体的には、Tag Helper というコンポーネントを使うことで、タグの内容を置き換えたり、追加したりといったことができるようです。
このあたりはすぐにでも使いたい機能だと思いました。
Tag Helper に関してはこのあたりを見るとわかるかもしれません。
https://www.jeffreyfritz.com/2014/11/get-started-with-asp-net-mvc-taghelpers/www.jeffreyfritz.com
Scaffolding
最後に Scaffolding について取り上げられました。Scaffolding とはテンプレートによるコード生成の仕組みですが、新たに Yeoman がサポートされたとのことでした。
NET Core 5 & ASP.NET 5 Open Source, DNX, Websites / Linux / Mac
https://www.slideshare.net/shibayan/net-core-dnxwww.slideshare.net
blog.shibayan.jp
「.NET Core と DNX（ダサい）は本当に未来なのか」という衝撃的なタイトルのスライドでした。
互換性問題
ASP.NET 5 は .NET 4.6 と Core 5 の両方で動くものの、互換性はないので、ASP.NET 5 向けのライブラリは 4.6 向けと Core 5 向けのものをそれぞれビルドし、両方を 1 つの NuGet パッケージに収めて提供することになります。
さらに ASP.NET 向けに限らないライブラリの場合、Xamarin 等も考慮すると、どれだけの数の環境用にそれぞれビルドしなければならないのか、頭の痛い問題です。
Roslyn による動的コンパイル
これまでの ASP.NET では、コントローラー等の純然たる C# によって書かれたコードは事前に .dll にコンパイルされ、cshtml 等に書かれたコードは実行時にコンパイルされていました。
ASP.NET 5 からは、C# コードのコンパイルも Roslyn によって動的に行われるようになります。
これの何が嬉しいかというと、実行中に C# コードを書き替えられるということです。
これまでも、cshtml や css、js といったコードは、デバッグ中にも書き換えを行って、ブラウザーでリロードすれば変更が反映されましたが、コントローラーのコードを書き替えるには、一旦デバッグを停止してビルドしなければなりませんでした。
ASP.NET 5 では、こういった変更もデバッグを止めることなく行うことができるようになります。
ただし、実行時コンパイルはパフォーマンス上のデメリットにもなります。
そのため、開発が完了してデプロイする際には、cshtml のコードもプリコンパイルして dll 化してしまうことも可能です（これまでも可能でした）。
DNX
Dot Net Executable の略です。.NET を DN としてしまったのがダサいとのことでした。
これまでは KRE とか XRE と呼ばれていたもので、元々は ASP.NET 5 の実行環境として作られたものが、コンソールアプリも含む Core 5 用の実行環境になりました。
DNX は、クロスプラットフォーム対応の必要性から出てきました。
これまで、ライブラリの参照は NuGet を使っていましたが、厳密に言うと、NuGet の仕事はライブラリをダウンロードしてきて展開するところまでで、参照設定は VS の機能でした。
VS のない環境でも開発できるようにするため、NuGet でダウンロードしただけで参照設定まで完了させる必要が出てきました。
このあたりの面倒を DNX が見てくれるようです。
NuGet の重要性は高まっており、Core 5 では .NET のコア部分である CLR 相当のライブラリも NuGet で配布されるようになりました。
各 OS 用の CLR がそれぞれ（Windows では .NET 4.6 と Core 5、Linux/MAC では Mono と Core 5）あり、それらの上に DNX が乗って、ASP.NET アプリは DNX 上で動くようです。
しかし、DNX がプラットフォームの違いを吸収する層になるのかと言うと、そうでもないようで、プラットフォーム抽象化層（Platform Abstraction Layer:PAL）は Core 5 が持っているようです。
開発状況
現時点では Windows 版の x64 のみが開発完了しており、Linux/MAC 対応は始まったばかりのようです。
さらに Windows 版の x86 用や ARM 等は完全に置き去りにされている状況とのことでした。
Core 5 も DNX も ASP.NET 5 も開発中ということで、現時点ではまだ、実用には耐えないようです。
後編に続く
長くなりましたので記事を前後編に分けさせて頂きます。
岩永さんのセッションからは後編にて。
イベントの詳細および当日の Twitter まとめは、以下のリンクからご覧ください。
