「.NET Conf 2020 Online - .NET 5 リリース記念 パーティートークへようこそ」のまとめ #dotnetconf
面白く、ためになったので、文字起こししてみました。
- 告知内容
- .NET Conf 2020 Online - .NET 5 リリース記念
- 自己紹介と推し機能
- 祝 .NET 5 リリース！
- NET 5 / BCL / C# 9
- ASP.NET Core Blazor
- Entity Framework Core
- Cloud native / Microservices
- Xamarin / .NET MAUI Preview
- Windows 向け機能 / その他
- 番外編
- 今後開催される .NET Conf 関連イベント
- 資料
- 感想
告知内容
.NET Conf 2020 Online - .NET 5 リリース記念パーティートーク
.NET をこよなく愛するエンジニアによる .NET 5のリリース記念パーティートーク
はじめに
今年の 11 月 10～12 日に渡って開催される .NET Conf 2020 では、大注目の.NET 5 のローンチが予定されています！
https://www.dotnetconf.net/
.NET 5 では .NET Core / .NET Framework (の一部機能) / Mono (Xamarin) の統合が行われ、デスクトップアプリの開発からクラウドそしてはモバイル向け、はたまた IoTや機械学習向けの開発など、非常に幅広い領域をサポートしますが、一人で全てを把握するのは非常に難しいですね。
そこで、今回は .NET をこよなく愛するメンバーによって .NET 5の注目機能、個人的に推したい！という機能やアップデートについて話しちゃいます！トーク以外にもライブコーディングもあるかも！？
もちろん Twitter でハッシュタグを付けて質問で参加出来ます。一緒に .NET 5のリリースをお祝いしつつ、疑問点を 解消しちゃいましょう！
スピーカーのみなさま（敬称略）
今回はオンライン開催の利点を生かし、日本各地から .NETを愛するエンジニアが集まりました！この豪華メンバーでのトークは二度と聞けないかも！？
Akira Inoue (チャック)
@chack411 .NET (ASP.NET) が好きが高じてそのまま MS に入ったエンジニア https://www.youtube.com/channel/UCTVaMV_epqpsEkpWuB_FfTQjsakamoto (北海道)
@jsakamoto ASP.NET Core Blazor をこよなく愛するエンジニア https://jsakamoto.github.io/Yuta Matsumura (福岡)
@tsubakimoto_s .NET Coreとクラウドの組み合わせなら何でも来いなエンジニア https://tsubalog.hatenablog.com/mitsuba yu (大阪)
@mitsuba_yu 最近 ASP.NET Coreに浮気してるクライアント系エンジニア/デザイナー https://c-mitsuba.hatenablog.com/shibayan (東京)
@shibayan .NET Core の ARM64 対応などニッチな部分ばかりに気になるエンジニア https://blog.shibayan.jp/
#dotnetconf
.NET Conf 2020 Online - .NET 5 リリース記念
自己紹介と推し機能
- チャック
- Swagger/Open APIが最初から入ってくる OpenAPI Specification on by default
- HttpRepl バックエンドをデバッグする時に便利
- さかもと
- まつむら
- Project Tye
- みつば
- WPF
- ZAML周りのデザインビュー
- しばやん
- Entity Framework Core
- many to manyがついに復活
- EF Coreのチームは透明性の高い開発をしてるので推したい
- Entity Framework Core
祝 .NET 5 リリース！
スライド
- NET 5 / BCL / C# 9
- ASP.NET Core / Blazor WebAssembly
- Entity Framework Core
- Cloud native / Microservices
- Xamarin / .NET MAUI Preview
- Windows 向け機能 / その他
動画
https://youtu.be/HJ802p3syTw?t=444
NET 5 / BCL / C# 9
し「 バージョンについては.NET Frameworkの4.8からシムーレスにアップグレートできるという言い訳のために、.NET 5にしたという噂 Coreをはずしたのはそういう理由。」
チ「.NET Frameworkは4どまり、次は5だ、Coreも統合して、Coreという名称もとって、.NET、シンプルに.NET5でいこう流れですよね・・・知らないけど。」
？「よく聞かれるますよね、4は？って.NET Core 4じゃないんだって。」
？「Windows 9 がなかったですよね。」
？「触れてはいけない部分。」
し「.NET Framework から.NET Coreになって、開発できる領域が広がった結果、単に.NET5にバージョン1個あがりましたじゃなくて、中身のフレームワークがアップデートされているので今回、この会はどれかに特化するんじゃなくて、それぞれのフレームワークの部分を触れていきたい。」
し「.NETのランタイム自体がアップデートされた。あまりBCLって言わなくなったかもしれない。最近はRutimeというリポジトリが追加された。」
し「C# 9へのアップデート」
C# 9.0の新機能
ASP.NET Core / Blazor WebAssembly
し「ASP.NET Core、3.0からWPF、WinFormのクライアント系が追加されたが、メインはWeb、ASP.NET Core、Blazar。」
し「WebAssembly版が5月に正式版になったが、5へのアップデートのときに、ライブラリがmonoから.NET 5版に統合されたり パフォーマンスがめちゃくちゃあっがっている。」
チ「.NET 5は、パフォーマンスを結構推している。実際速く早くなっているし、期待値は高い。」
し「ASP.NET Core、Blazorがこの2つがC#でのWebアプリケーション開発のメインフレームワーク。」
Entity Framework Core
し「推しているEntity Framewokr Core。昔のEntity Frameworkは重厚なフレームワーク、EF Coreになってライトに使える。フルのORMではあるが、気軽に、設定も少なく使えて便利。」
チ「EFはパフォーマンスもなんだかんだ言われてて課題だった。EF Coreになって軽量化されたのはいいこと。」
し「未だにEFを恨んでいる。なぞのEDMX fileとか、EFはSQLじゃなくてEntity SQLで書いたり、Microsoftの悪いところが全部でていた。 EF Coreはシンプルなプロバイダーになった。」
し「パフォーマンスだと、テストのTechEmpower のベンチマークテストでは、DBも同時にテストされるが、DBを立ててプロバイダー周りもチューニングが進んでて、全体的にパフォーマンスが底上げされている。もちろん、Entity Framework Coreもパフォーマンスが結構あがっているらしい。」
Cloud native / Microservices
し「Cloud Native。あまり、Cloud Nativeって言わなくなった気がする。個人的に。」
チ「一時期のバズワード的ななにかだった？私のチーム名はCloud Nativeなんですけど。」
し「あたりまえになってきたかな。」
し「MicroServicesに.NETは注力している。」
チ「裏事情がいろいろあるが、ここでは話さない(後で？)。」
Xamarin / .NET MAUI Preview
し「クライアント系Xamarin、Xamrin Forms 5のデモがあった、MAUIはアップデートが進んでなさそう。後ほどじっくりと。」
Windows 向け機能 / その他
し「MSがやっているので、Windows OST向けアプリケーションに特化した機能もちょこちょこ入っている。」
チ「Windows向けで、ClickOnceみたいな話は後半にありましたっけ？」
し「ClickOnceはさかもとさんが大好きなので。」
さ「(ClickOnece)あれ死ぬかと思って、閉めようと思ってた案件があるですけど、機会があれば話しましょう。」
NET 5 / BCL / C# 9
スライド
- Announcing .NET 5.0
- アップグレード向けドキュメント
- 今後の .NET Standard の扱い
- C# 9 リリース（NRT 改善 / Record types / Code Generator など）
- What\'s new in C# 9.0
- @ufcpp の⼈が今後のイベントで詳しく話すはず
動画
https://youtu.be/HJ802p3syTw?t=1008
Announcing .NET 5.0
し「Annoucingのblog見ました？めっちゃ長い。プロローグ？(聞き取れない)がこんな小さいと思うぐらい、長くなっている。」
チ「こんだけよくまとめたな、細かいところも全部リンク含めてまとまっている。これを見ながらリンク1つずつ見ていくだけでも理解が深まる。」
し「結構重いたい、僕らがその中で気にあるものをピックアップしていく。」
.NET 5.0 Highlights
し「Performance is greatly improved素晴らしいことですねパフォーマンスは速いほうがよいライブラリ、GCのアップデートだったり、 ClickOnceの話も書いてある。」
チ「single-file apps、reduced container image size、うん、そうですね 。」
し「コンテナのイメージも劇的にサイズが小さくなったらしい。」
し「Windows Arm64 とWebAssembly。WebAssemblyはBlazorのWebAssemblyで超重要な機能。」
し「あくまでOverviewがまとまっている。」
Tools
し「Tools系だとWindows Forms designerが出ている。」
ま「意外にこれでFormが作りやすくなるよね。アプリが。」
し「でも、それVS 2005のころからできてたよな。」
み「Formsのdesignerなかったんや。」
チ「.NET Core来て、WPFのdesignerの方が先にきた。最初はなかった。VSのアップデート出てきた。」
み「未だにFormsを作ったことがないなー。」
チ「.NET Confのキーノートで、Scott HanselmanがWindows FormsでWebview2コントロールを使っているデモって見ました？」
し「 Scott Hunter、Scott Hanselman、Scott Guthrieの3人を選べ。」
チ「話が脱線してしまうけど、私的にはあの3人が並んだのはすごい。でも日本人的にみると、なんでScott Guthrieが一番したなんだと、日本時的には、上司を一番上にあげないといけないのにと思って見てた 。」
Native exports
し「最近パフォーマンスを意識した結果Native系のサポートとか、COM参照のメニューが増えてる。令和になってもCOMを使わないといけないのかなと。」
チ「COMって今知ってる人ってどれだけいるのかな、知らない人の方が多い気がする。Componet Object Modle。」
み「聞かれたら説明できひんな。」
し「そういうものがあると知っておけばよい。」
チ「でも、WindowsはCOMの塊ですからね。今でも。まぁいいや行きましょう。.NETの話ですから。」
P95+ Latency
し「(P95+ Latencyを見ながら)requests per second (RPS) はStack Overflowの人が適用したときにこんだけCPU使用率が下がった。劇的に効果が出ていた。リクエストが多いとこだと効果ある。」
し「他言語対応のライブラリICU、UnicodeがWindowsに標準で入ったのでまともになったのかなと。」
チ「このブログを入口として見てください。」
Breaking changes for migration from version 3.1 to 5.0
し「最近Docsを見るようにしている。Breaking changesがあって全部まとまっている。マイグレーションガイドもある。」
ま「これは3.1から5.0へのマイグレーションガイドですか？」
し「そうです。よく見るとBlazorが多い。サイドでカテゴリごとにまとまっている。軽く目を通しておく、こういうドキュメントがあることを知っておくとよい。」
チ「そうでですね。3.1から5.0へ自分のソースコード、プロジェクトをアップデートしたけど、ビルドでエラーになって、なんだろう？という時に、こういうドキュメントがあると覚えておくと解決として使えると思う、これはいい。」
さ「このドキュメントいいわ、この会ためになります。」
The future of .NET Standard
チ「その動画7秒だけど」
し「.NET になる。全部まとまっている。以上。」
し「頭だけ読むといい。どのTFMを使うかが書かれている。基本は一番新しいのを使えと書かれている。」
- net5.0. This is for code that runs everywhere. It combines and replaces the netcoreapp and netstandard names. This TFM will generally only include technologies that work cross-platform (except for pragmatic concessions, like we already did in .NET Standard).
- net5.0-windows (and later net6.0-android and net6.0-ios). These TFMs represent OS-specific flavors of .NET 5 that include net5.0 plus OS-specific functionality.
し「ライブラリでだすかアプリのコンポーネントでだすか、どれを使うべきかがまとめられている。」
チ「互換性を考えるなら、.NET Standardで、仮に.NET Framworkでも使えるようにとなると、.NET Standard 2.0でと書いてある。」
- Use netstandard2.0 to share code between .NET Framework and all other platforms.
- Use netstandard2.1 to share code between Mono, Xamarin, and .NET Core 3.x.
- Use net5.0 for code sharing moving forward.
チ「これからは5.0だよ。」
C# 9
し 「別のイベントで C#で有名な人 @ufcppさんが話すので、そちらを聞くのが正解です。」 Visual Studio Users Community Japan 勉強会 #6
ASP.NET Core
スライド
- Announcing ASP.NET Core in .NET 5
- アップグレード向けドキュメント
- gRPC サポート改善とパフォーマンス向上
動画
https://youtu.be/HJ802p3syTw?t=1555
Announcing ASP.NET Core in .NET 5
し「こっちは割とさらっとしている。フォーマンスはめちゃくちゃ上がっている。」
し「2.1から3.1であがっていたが、5.0でさらによくなっている。なにも考えずアップデートするだけでパフォーマスがこれだけ改善するのはおいしい。」
チ「.NET coreとか新しいのがでてくると、.NET の世界では、パフォーマンス、パフォーマンスと出てくるが、毎回これだけ上がってくるというのはやっぱりすごいな。中の人ががんばっている。」
し「この辺は、クラウド上だと、サーバー台数の削減とかで、コスト削減につながるからモチベーションにもつながるかなと。」
し「新機能はほぼBlazorのだったする。新機能はblogにはまとまっていなかったが、Docの方にまとまっている。」
- Migrate from ASP.NET Core 3.1 to 5.0
Migrate from ASP.NET Core 3.1 to 5.0
し「これもマイグレーションガイドがある、マイグレーションははがんばる。差分付きで書いてあるから分かりやすい。」
し「Blazorは今回SDKも変わっているんですね。」
チ「Microsoft.NET.Sdk.BlazorWebAssembly。」
し「アップデートはこの通りに従うと、スムーズにいけるかなと。」
し「正直、ASP.NET Coreの新機能というのはあまりないんですよね。だいぶ枯れてきたなと。」
み「うらやましいねぇ、それ、クライアント民からすると。」
し「コメントに困る。」
し「なんだんかんだで、それまでの資産の積み重ねで、パフォーマンスもだいぶ上がって、機能もだいぶFIXしてきた。バグも少なくなってきた。」
し「最近gRPCがすごくよさそう。」
チ「gRPCをみなさん使ってますか？」
ま「使ってないですねー。」
チ「そうでもない。」
し「使うところがあまりない。」
ま「ちなみに、名前って、ASP.NET はCoreが残るんですか？」
し「残ってますね」
チ「そう、そんな感じです。今は。CoreがないASP.NET 5は一時期存在していたから。たぶんそのせい。名前も混沌してた時期があってネーミング、バージョンは苦労してつけている。」
チ「今のdotnetというCLIのコマンド名が、前は、dnxだったり、その前はkと言ってた時代にASP.NET 5と言ってた時期がありましたね。」
し「当時はvNextと呼ばれていましたもんね。」
チ「Coreは、ASP.NET Coreはそのまま残る気がします。」
し「たぶんこれはそのまま行きますね。Entity Framework Coreもそのまま。」
し「gRPCに話を戻すと、Webアプリケーション、ブラウザ系からだあまり触る機会がない。」
チ「前に関係していたお客様の案件だと、バックエンドにKubernetes、AKS(Azure Kubernetes Service)を使って、バックエンドのサービス間の通信にgRPCを使っていますね。」
し「MicroServiceの通信だったら、同時接続、低レイテンシー、gRPCが好まれるかなとは思います。」
さ「gRPCやりたいけど、やれてないという立場の人です。自分は。型が付くのがすごく気になっています。」
チ「1つは、WCFが.NET Fraomeworkで終わり。.NET Core、.NET 5にはWCFはこないので、その辺の置き換えとして、gRPCに注力している。」
チ「.NET 5って、.NET Frameworkと.NET CoreとXamarinが統合されるよという話はあるんですが、厳密に言うと、.NET Frameworkのところは 少し切られている捨てられている部分がある。WCF、Web From、WFだったり、全部来るわけではない。」
ま「Web FromはBlazorと言われてますよね。」
し「一応扱いそうらしいですね。」
チ「概念的にははBlazorで、HTML、JavaScriptをあまり書かなくてもC#で書けますよというコンセプトだとBlazorが置き換え。厳密に言うと全然違うもの。」
ま「Web FormはBlaozrに移植しよという書籍もある。 ASP.NET Core ApplicationArchitecture 、ASP.NET Web Forms 開発者向け Blazor 、PDFだと英語だとけど、Webだと日本語もある。」
チ「アーキテクチャの比較 も書いてあるじゃないですか、多分これ見ていただけると、ちょっと移行しようかなと考えてる人はいい感じですね。」
し「『既存の ASP.NET Web Forms アプリケーションを最新式にするための計画を立てる際に役立ちます。』結構危険なことを書いてある。」
チ「ほぼ書き直しにはなると思うんで、そこだけだけは。」
チ「こういう使えなくなるフレームワークもあるんで、gRPCに話を戻しますけど、そういったところでは注力してるところですよね、gRPCは。 ASP.NET Core gRPC for WCFDevelopers というのもある。」
し「WCFは現役のときにに全然使う機会がなかった。」
チ「最近あまり話聞かないが、まだ動いてるシステムもある。今後そういうをどうするかは、1つ課題にはなってくるでしょうけど。」
ASP.NET Core Blazor
スライド
- What\'s new in ASP.NET Core 5.0 - Blazor
- Static Web Apps でのサポート
- Mobile Blazor Bindings
動画
https://youtu.be/HJ802p3syTw?t=
Blazor
し「この辺の知識全然ないんで。」
チ「ここは、さかもとさんで。」
し「新機能はまとまっていました。さっきのページなんですけど。」
チ「私もBlazorのデモアプリがあるんですが、.NET 5に書き換えようと思いつつ、また後でがんばろうと、今日はさかもとさんの話をちゃんと聞いて勉強してから帰ろうと。」
し「さかもとさん、もう仕事でふつうにはBlazorを使っているんですか？」
さ「バリバリまではいかないですけど、立ち上がりのタイミングなんで、今後やるのは全部Blazorで行くよね。」
さ「3.1から正式になったタイミングから使い始めている。」
チ「そこで質問、実際に使っているBlazorですけど、サーバーサイドを使ってますか？WebAssemblyを使ってますか？」
さ「あー、良い質もですね。両方です。」
さ「もっぱら、WebAssembly側を中心に考えている。サーバーサイドでやった方がいい案件もあったりして選んでます。」
チ「そのいい案系という理由は？どんなところにあるんですか？」
さ「ブラウザで処理させるのには重いたいのを、サーバ連携でできるですけどもUIとのイントラクションも多いので、みたいな、特殊な話ですね。」
さ「ただ、基本的にはサーバーサイドだと、切れたらおしまいってのがあって、ブラウザーとサーバーサイドとぷつんと切れたら真っ白になちゃうというのもあって個人的には気に食わないので、そいうこともあって、WebAssembly側を優先にしている。」
タブレット画面を開いて使ってもうらケースが多いんですけど、工場内でWifiが弱かったりして切れたりするので、WebAssemblyなら多少調子悪くても、電波届くところまで言って、ボタンタップしてと言えばよいので。そんな感じでやっている。」
し「Nativeアプリとような感覚で使える感じ。オフラインサポートってあるんですか？」
さ「あります。結局Webなので、PWAとして。」
し「あぁ、普通に。」
チ「プロジェクトテンプレートにPWAがあるのでPWAにするのは楽。ただオフラインの時の実装はしっかりとしないといけない。」
チ「あと最近、Visual Studio、Visual Studio Codeで、WEbAssembly側もデバッグできるようになっているし、ブラウザ開発ツールでデバッグしやすくなっている。そういのもあって、使えるところだであれば使いたい Azure Web Static Apps でもBlazor対応してきている。」
Azure Static Web Apps with .NET and Blazor
し「デプロイ先悩むかなと。Azure Web Static Appsにデプロイできるということは完全に静的サイトになるということですか？」
チ「WebAssembly版でやると基本静的サイトとしてできる。」
さ「私のポートフォリオページが、Github Pageにあがっていますね。」
チ「かっこいい！！」
さ「これは函館未来大学の学生さんがやった作品を真似たというかパクっただけなんですけどね。」
さ「実装は実際やりましたけど、このコンセプト、このアイディアで。」
し「これが完全にWebAssemblyで動いている。」
さ「サーバサイドじゃないです。staticなコンテンツだけです。」
ま「サーバー側に.NETのランタイムがいらないといことですか？」
さ「いらないです。」
し「若干はいるのかなと思ってたんですけど、そういうわけじゃないんですね。」
さ「全然違いますね。httpサーバさえあればいい。」
し「僕が知ってるのだとDLLが降ってきたと思うんですけど。」
チ「Application のCache > Chache Storageにキャッシュされる。」
さ「一旦は吸い上げに時間がかかるんですよ。」
し「(一旦クリアーしてリロードすると)一応圧縮されてるんですね。」
チ「今回のアップデートでさらアセンブリのlazy loadingの機能もでてきて、ロード時にじゃなくて、必要な時にロードするように設定できるようになった。」
し「なんだかんだでアセンブリのサイズが大きい。」
チ「そうそう、その辺懸念されてる方だと、サーバーサイドという選択肢もあったんですけど、なんとなくこなれてきているのと。」
さ「サイズ問題はどうしよもないので、サイズが飲めない方はBlazorやってはだめなんだと思う。JavaScriptの方がいいと思います。 React、Vue、Angular。」
チ「一つの選択肢として、React、VueでJavaScriptベースで行くのか、C#でシングルページの形式で組んでくのか考えて選んでもらっていけばいいのかなと。」
し「WebAssembly系でここまで作り込んだやつってないらしいんで。」
さ「アンテナ貼ってるつもりですけど、WebAssemblyでSPAが作れるというのは見ていない。Goで近いのはあったと思うんですけど。」
し「JS派の人からも注目視されいるというのは聞きましたね。」
チ「完成度高いですよね。いい感じで。」
さ「Steve Sandersonさんがすごすぎる。こんな物作ってしまった。恐ろしい人です。」
し「j.Sakamotoのサイトは、ただ表示してるだけじゃなくて、インタラクティブに動くんですね。」
jsakamoto$ runtimeinformation
Framework Description - .NET 5.0.0
Process Architecture - Wasm
OS Architecture - Wasm
OS Description - Browser
OS Platform - Other
OS Version - 1.0.0.0
OS Version ServicePack -
し「もう、.NET 5.0に更新したということですね。」
さ「はい。」
し「WebAssemblyは、数年後一気にきてそうだな。」
チ「WebブラウザがWebAssemblyを対応してきている。環境というところが整っているので一気にいい感じに来ましたよね。」
さ「他の言語も来たらいいのにね。」
し「案外来ないんですよね。C++のコードをWebAssemblyでコンパイルしてという話はよく見るんですけど、なかなかそれより先に進まない。フルスタックのアプリケーションフレームワークが出てこない。難しいんでしょうね。」
チ「個人的にはさらにAzure Static Web Appに対応してきたんで、ホスティング環境としてもいい感じとして整ってきたなと。 Azure Static Web Appはまだプレビューですけど、バックエンドをAzure Functionsで組んでRESTのAPIみたいな構成だと面白いなと、今風だなと。 」
し「前に、今後のロードマップみたいなので、Electronで組み込んだり、Nativeに近いアプリにするみたいな、そういう話もありましたよね。今回のデモとかそいうのでは語られなかったんですけど。」
し「Electronで配信する系であれば、サイズ制限とか全然ないのでそこは全然ありな気がします。」
チ「面白いのは、徐々に、WebAssembly、Webの技術ですけど、ブラウザからNativeにだんだん来ている。Webの技術でNativeアプリを作ろうというのが動きが出てきているのが面白いところ。」
し「正式リリースになっている。途中で諦めるんじゃないかと、SilverLightっぽくなんじゃないかと。」
？「今も言われますもんねSilverlightかーって。」
さ「SilverLightの捨て方ひどかったんですよね。MSのね。あんだけやっておいて、やーめたって。」
チ「AzureのポータルさえSilverLightで組んでた時代があったんですよね、知ってますか、みなさん。前の前の世代です。」
チ「SilverLightはプラグイン依存してたところが、BlazorはプラグインではなくWeb標準のWebAssemblyというところが、そもそもブラウザが対応してるという環境が整っているというところがぜんぜん違う。」
し「最近のASP.NETチームは、Blazarしかやってない、MVCとかは放置されている。」
チ「MVCよりはBlazor、API周りに注力するというのは今の流れとしては妥当だと思います。」
チ「バックエンドを作るのにAPI周りの充実とフロントエンドはBlazorもそうだし、注力ポイントは今のトレンドを踏まえた流れにはなっていますね。」
Entity Framework Core
スライド
- Announcing the Release of EF Core 5.0
- アップグレード向けドキュメント
- EF Core 5.0 は .NET Standard 2.1 をサポート
動画
https://youtu.be/HJ802p3syTw?t=3009
Announcing the Release of EF Core 5.0
し「ここのチームは何をやったかというのをすごい書いてある。ついに、Many-to-many が戻ってきました。」
し「さかもとさんはどれかの機能について言ってたんですが。」
さ「Required 1:1 dependents かな」
し「微妙に挙動が変わったみたいな。」
し「EF Core のリリースと計画 で リリース計画がある」
し「Entity Framework Core 5.0のおおまかな計画 で誰がやって、規模がどのくらいか、Github上でやってのが転記されている。すごいオープン。何をやったか、リーダーが誰かも書いてある。」
し「新機能もPreview 1からRCまで細かく書いてある。新機能を追うには最適です。」
し「互換性 に関しては、破壊的変更が多少あるので、移行の際には、この辺を気をつけていただければよいです。」
し「一番最後(RC1)で入ったのがMany to Manyです。めちゃくちゃ時間掛かって、実装も大変だんったみたい。」
し「でも、Entity Framework 6よりか確実に良くなっている。最近なんだかんだで、DapperのマイクロORMが便利だし、Queryを書くときもさっと書いてさっと使えるのも便利ですけど、業務ロジックでJOINとかいろいろ複雑なものになってくると、Entity FrameworkでLINQで書くというのが便利なことも多い」
し「この辺りは使い分けて、どちらか片方によるんじゃなくて必要なものを選んで行けたらいい。」
し「パフォーマンスもものによってはDapperに近いくらい出るという話が挙がっている。」
チ「昔は、パファオーマンスで悩まされた方々も多いEntity Framework。Coreじゃない前のころだよね。Coreになってかなり軽量化されていい感じですよね。」
し「しかもRuntimeがパフォーマンスも上がっているんで、同時に？？？ってます。」
し「Entity Framework Core 5.0は、.NET Standaer 2.1なんです。」
し「ASP.NET Core 5.0は、.NET 5.0なんです。TMFが。」
し「Entity Framework Core 5.0はちょっと広く使えます。.NET Core 3.1でも使えます。広く使うという意味では重要なポイント。」
し「Azure Functionsが怪しんで、なにも話がでなかったじゃないですか。」
チ「私、追えてないんですけど、Azure App Serviceは、.NET 5が来てるじゃないですか。」
し「来てます。」
チ「Azure Functionsってどうなんですか？」
し「3.1。たぶん、無理やりランタイムを5.0にしたら落ちると思います。」
し「なので、Entity Framework Coreは、.NET Standar 2.のままじゃないと、Azure Functionsで使えなくなる。」
し「この辺りは情報待ち。」
Cloud native / Microservices
スライド
動画
https://youtu.be/HJ802p3syTw?t=3280
.NET 5.0 Release - dotnet-docker
し「dockerの命名規約が変わっている。Breaking Change: .NET Docker Repo Name Change」
ま「ちょくちょくありますね。」
チ「そうだよね。」
し「こないだも変わっただろうって。」
し「dotnet/coreからdonetへ変更でcoreがなくなった。」
チ「シンプルにはなった。5でね。」
し「今使ってる方はアップデートの時に要注意かな。」
し「Docker images サイズは、嘘みたいに小さくなって、5KB。嘘みたいですけどね。」
チ「manifest onlyなんだ。」
し「MicroServiceとKubernetesとかに展開するのに使いやすくなっている。pullのコストが大きいですからね。」
チ「なので、コンテナで移行を考えている方は、Windows Containerに、.NET Coreなり.NET 5にした方がいいと思います。」
し「Windows Containerで.NET Coreを動かす人はいないんで。」
チ「まぁ、.NET Frameworkをどうしよう。.NET Coreに移行しようかな、いや、.NET Framewokrのままで。」
し「そこは無理くり.NET Coreに移行して。」
ま「.NET Coreに移行して欲しいですよね。」
し「.NET Frameworkから移行するプロフェッショナルのまつむらさんがいるので。」
ま「お待ちしております。」
Introducing Project Tye
し「読み方に自信ないんで松村さんいいですか？」
ま「は、プロジェクトタイ。これ、Project Typeなのか.NET TyeなのかTyeだけなのか。表記がバラバラなので、僕も分からないです。Project Tyeって言葉が一番多く出ていましたね。」
ま「MicroServiceの開発を支援するツール。デプロイメントをサポートしているオーケストレーションツールですね。」
し「基本はデプロイをやってくれるということなんですか？？ASP.NETの方にライブラリに入れたりする？」
ま「ライブラリには入れなくて、csprojには入れなくてよくて、Tyeというグロバールツールを環境にインストールする。ローカルでも、例えばバックエンド用のAPI、ASP.net core Web APIとフロントサービス用のRazor Pageとか2つ置いておいて、ローカルでTyeでrunすると、ローカル環境でMicroServiceの環境を動かすことができるコマンドですね。」
ま「それをAKS(Azure KubernetesService)とか、Azureの環境にデプロイする機能も入っています。」
し「基本はKubernetes用なんですかね？」
ま「そうですね。サンプルもAKS(Azure Kubernetes Service)用が一番多いですね。」
し「やっぱそういう形になるんですね。自社でオンプレでkuberntesをやるかわからないですけど、そういうのにも行けるかもしれないですね。」
ま「そこはですね、デプロイする時にAKS(Azure Kubernetes Service)のcredentialがいるんですよ。」
し「なるほど」
ま「ローカルでAzure CLIとかでAKS(Azure Kubernetes Service)とつなげておいて、デプロイする形ですね。」
チ「コンテナレジストリも指定するんですよね？」
ま「そうですね。Docker HubかAzure Container Registryのどっちか。その2つが使えます。」
チ「デプロイするときって、DockerfileとかKubernetesのconfig、YAMLのdeploy configとかは別になくてもいいという認識であってます？」
ま「Dockerfileいらないんですよ。」
し「いらないんですか？」
ま「Tye用のYAMLファイルをルートに置いておいて、そこに構成を書くんですよね。」
チ「勝手にその辺りは作ってうまい感じでDockerコンテナにビルドして、ACR(Azure Container Registry)なりにpushして、Kubernetesまで走らせてくれる便利ツールですね。」
し「Dockerのイメージのビルドは必要なですね？」
ま「Dockerをインストールして置かなければならなかったはずです。」
チ「ローカル環境にDockerはいないといけないですね。」
ま「これが構成を定義しているYAMLです。バックエンド用とフロントエンド用に定義しておいて。」
ま「それぞれサービスですという感じで登録していて。」
services: - name: backend project: backend/backend.csproj - name: frontend project: frontedn/frontend.csproj
ま「レジストリですね。Docker HubかACR(Azure Container Registry)に」
registory: acrpojecttye.azurecr.io
ま「あと必要な別のサービスredisとか書いておいて。」
- name: redis image: redis bindings: - port: 6379 connectionString: "${host}:${port}" - name: redis-cli image: redis args: "redis-cli -h redis MONITOR"
- 全体
name: microservice registory: acrpojecttye.azurecr.io services: - name: backend project: backend/backend.csproj - name: frontend project: frontedn/frontend.csproj env: - name:YOUR_NAME value: "YUTA in YAML" - name: redis image: redis bindings: - port: 6379 connectionString: "${host}:${port}" - name: redis-cli image: redis args: "redis-cli -h redis MONITOR"
ま「これをローカルで tye run する 」
ま「新鮮です。Visual Studioでいいじゃんと言われたらそれまでなんですけど。」
し「いや、結構俺は好きですね。Dockefileをやっても、正直Dockerfileってだいたい同じになるじゃないですか。」
ま「うんうん」
し「なんでそこらへんも自動でよしなにやってくれた方がと思うんで。」
チ「.NETベースで複数サービス、このケースだとフロントエンドとバックエンドが1対1ですけど、いろいろバックエンドが複数のサービスが動いてくるときに例えばデバッグする時に、全部1つずつ順番を追っていくサービスを立ち上げて、フロント立ち上げて、デバッグみたいなところも依存関係も全部やってくれるですよね。」
ま「なので、ローカルにデプロイするときもYAMLを変えなくていいんですよ。そのままデプロイのコマンド打つだけで、デプロイすることができる。」
ま「5月ぐらいに発表されたですけど、見た時新鮮でしたね。あまりこういうのなかったから.NETに。」
チ「Fukutenとかでハンズオンとかやってますよね、たしか。」
ま「そうそう、はい。私がやってるコミュニティ(Fukuoka.NET？)でもProject Tyeのハンズオンはやってますよ。オンラインでやってるのでぜひぜひ参加してください。」
さ「実際画面見たら分かりやすいですね。」
ま「これまだ、プレビューにすらまだなっていないツール、試験的ツールなんですけど、一昨日ぐらいにVersion 0.5がでてきて、ようやく.NET 5に対応したんですよ。 それまで、.NET Coreの3.1しか動かなかったんですけど。一番新しいバージョンだと、.NET 5で動作できると、今日確認しました。」
し「Kubernetesを利用している話を聞くと、このYAMLってきつし、Dockerのビルドから含めてCIをするのって話を聞くだけもつらそうだなというイメージだったんですが、これは結構わかりやすい感じになっている。」
チ「アプリケーション開発者が、このケースだと、APS.NETでフロントエンドとハックエンドを作るのに、その人が更にDockerfileまでならまだしも、Kubernetesのデプロイ用のYAML書きますか？たぶんそこまでなかなか手が回らない。辛いと思う。だからどうしてもそこの専任の人が必要なケースがあると思うんですよ。」
チ「あとデバッグ環境ですよね。MicroServiceで作られているような複数サービスがあるようなときにをどういうふうにデバッグするのか、実施Kubernetesにデプロイするにしても、デバッグ用のKubernetesのクラスタを作ってというところも含めて、結構大変なので。」
チ「.NETをやられる方だと、Tyeみたいなツールがあると、とりあえず手元でデバッグする、勝手に依存関係持って立ち上げてデバッグできるし、そのままTyeでKubernetes、AKS(Azure Kubernetes Service)までデプロイしてくれる。ある意味楽は楽ですよね。」
ま「Tye用のパッケージある。YAMLで環境変数を設定するんで、それを参照するようなライブラリ。これだけ入れれば大丈夫です。」
- tye.yaml
- name: frontend project: frontedn/frontend.csproj env: - name:YOUR_NAME value: "YUTA in YAML"
- frontend.csproj
<ItemGroup> <PackageRefernece Include="Microsoft.Tye.Extentions.Configuration" Version="0.4.0-*" /> <ItemGroup>
し「これはよくあるASP.NET というか、.NET CoreのConfigureationの拡張ということなんですね。」
ま「appsettings.jsonに見るのかyamlの方を見るのか、確かyamlの方が優先。」
し「かなりシンプルですね。」
し「僕が勉強になって最高って感じです。」
ま「プレビューになって欲しいので、みんなで使ってフィードバックしましょう。」
Introducing YARP Preview 1
し「.NET Confの中で、新しいリバースプロキシーが出てきたと、C#で書かれた構成のプロキシ、YARP(ヤープ)。」
し「ちなみにまだベンチマークが公開されてないので、まだハイパフォーマンスかどうかは分からないですけど。」
し「少なくても、ARR(Application Request Routing)よりかは速いだろうという。」
チ「結構、ドキュメント、サンプルコードは揃ってましたね、いろいろ」
し「開発も進んでいて、性能も明らかに悪くはないだろうという感じですね。」
し「最近はもうHealth Cheksとか、本番で使うのに必要な開発に移ってきたかなと。」
チ「もうプレビューを取る方向で」
し「ちょっと前までは、認証がーとか、Session Affinityとか、リバースプロキシーの基本的な機能だった。最近は変わってきました。」
チ「Health Cheksの機能が入ってくるとかなり本番を意識した実装が進んでる感じですね。」
し「この辺りをMicorsoftがやっている理由というのが、Cloud Native時代というか、KubernetesからIngerssとかで外部からのリクエストを内部のコンテナに流し込む部分が必要。そこがリバースプロキシが何かしら動く必要があるという話ですよね。」
し「よく見るのはNginxのIngressとかをApplication Gatewayとして使うみたいな。でもあいつが遅いですよね。」
これは、Azureの Application Gateway イングレスコントローラーのことかしら？
チ「Application Gateway単体で使うのはいいんですけど、Ingressコントローラーとして使うことはできますけど、個人的には、私が言うのもなんですけど、NginxのIngerssコントローラを使いたいなという感じはします。」
し「僕もそう思います。」
チ「Application Gatewayも、ロードマップ的なところを見るとアップデートの予定もあるんで、いろいろ改善はされてくると思います。」
し「一応、あれV2にはなっていて、V1ってWindows+ARRだったのが、V2になってLinuxとNginxにになったんですよ。なので、ましになっって、オートスケールとかも対応してきてるですが、ちょっと重量級ですよね。」
チ「そうですよね。」
し「今リバースプロキシーを作るというのは、IIS捨てられるのかなってという気持ちも若干しつつ。」
チ (笑)
し「正直最近のAzure系の開発だと、IISを使う理由はARR(Application Request Routing)のリバースプロキシという感じ。」
チ「そうですね。まぁ、そもそも、.NET Coreが出てきて、kestreで動くという流れでは、もちろん、IIS依存をなくしていこうという動きはもちろんあるのでこういう段階でYARPみたいなC#、ASP.NET Coreベースで、こういう実装が進んできてるということは、やっぱりもっとより依存を、Windows、IIS一本のてをできなくしていこうというのは明らかなところだと思います。」
し「リバースプロキシはAzure Functionsのプロキシとか細かい部分で使われているので、App ServiceもARRとか、なんだかんだで、PaaSとかSaaSの実装に必要な部分なので、このYARPは、僕らが気軽に使うというよりも、実は、社内で勝手に使っていくために作ってるんじゃないかって思ってますね。」
し「アップデートとサービスに取り込まれて、自然にその辺のハイパフォーマンスさの恩恵を受けることができる時代を期待している。」
チ「いいところに目をつけていると思います。たしかにその通りかもしれないですね。」
チ「このYARPが出てきました。普通に開発されてる方が実際YARPを使って、自分で買う言うところを実装していくかと多分やる人も濃い人はいるとは思います。」
チ「実施のAPS.NET Coreのパイプラインをもっと高速にいろいろ作りたいというのがあるかもしれないですけど、でも、たしかに、多分、MS側でいろいろ、これを使った軽量なものをしっかり作るという土台にはなっていく気がしますね。私もそんな気がします。」
し「そういった意味でもすごく注目をしています。」
Xamarin / .NET MAUI Preview
スライド
- Xamarin.Forms 5
- MAUI は .NET 6 での正式リリースに向けて開発中
- Introducing .NET Multi-platform App UI (MAUI)
- なんと .NET 5 のリリースタイミングでプレビューが出なかった
動画
https://youtu.be/HJ802p3syTw?t=4363
Recapping Xamarin Highlights from .NET Conf
し「みつばさんお待たせしました。」
み「Windowsかと言われるとちょっと違うからね。でもどうなんですかねFormsって、Monoをやってるところでも、XamarinはXamarin.Formsとは違うよ。逆にしても Xmarin.FormsはXamrinとは違うよと結構言われている。」
み「MicrosoftのデモってFormsのものが多いので、では、実際、Formsってどうなのというのは昔から思ってるところではあるんですけど。やっぱりForms、Formsって言われてるのってなんなんでしょうねみたいな。」
み「やっぱりいろんなところで動くのは嬉しいのかなどうなんかなとか、あとやっぱり、UIをXAMLで書きたい人たちがいるのかなーみたいなのは気になってはいます。」
み「で、そのタイミングでMAUIでしょみたいな。」
チ「でも、本命は.NET 5、6でのMAUIな流れだと思うんですけどね。」
み「そうですよね。」
し「何が変わるかというのがまだ明確に見えてこない。」
み「まだあんまり情報がないというか。」
し「ただ、開発自体はすごくがんばっているのはわかる。」
し「最近クロスプラットフォームのUIフレームワークが多くなってきたなっていう。いろんな言語で。」
し「だから、みんなそこに目をつけ始めた。Xamarin.Formsはちょっと先に進んでたのかもしれないですけど、追い抜かれそうなのでもうちょっとがんばってほしい。」
チ「Introducing .NET Multi-platform App UI(blog)今ちょうどでてますけど、たぶんこの辺、Xamarin.Formsとかでもある程度プロジェクトがiOS、Androidみたいな感じでどうしても依存してる部分が残っている部分があったと思うんですけど。」
チ「実際この辺がどのくらいの形で、出てくるのか、これ見る限りだと分からない。もうちょっとシンプルに1プロジェクトみたいなシンプルな形でいくといいな。」
チ「まだ実体が分からないというところが正直なところ。」
し「このMVUが気にあってはいるんですよ。」
し「Model-View-Updateパターン。最近他のフレームワーク。りんごのフレームワークだとちょいちょい見るパターン。」
し「iOSのSwiftじゃなくて、Swift UIだっけ、その辺がこういうパターンだった気がするけど。」
み「そうですね。コードででUIが作れます。」
し「みなさん、MVVMかコードビハインドかどっちかだったのが、新しいパターンが増えるというのは興味があり。」
チ「最近のトレンドをちゃんと入れてきている感じはありますね。」
し「Roadmapのページもちゃんとありました。」
み「個人的には、Uno Platformにすごい興味があって、今ちょっと調べた感じ、Uno Platformが.NET 5に完全対応するぜって言っちゃってる。」
み「僕は、いわゆるWebの人間なくて、XAMLプラットフォームの人間なので、ちょっとこっちの方が興味ある。」
み「基本Mono Platformって、XAMLでUIを書いて、WindowsとWebとモバイルとなんやかんやで動きますみたいなやつなんですけど、それが一応Monoの上に乗ってたかな、WASMの上に乗ってて、それが.NET 5に移行するぜみたいなPlatformなんです。」
み「どうやらMicorsoftもいろいろお手伝いをしてるみたいです。」
チ「それは聞いてますね。多分、結構入っていると思います。」
し「High Level Architectureにあった。.NET 5で動かす。」
み「最初から興味をもって、最近ちょっとされてなかったんだけど。」
チ「割とこっちの方が進んでいる感じ、もちろん、すでに使えるものがあるわけですし。」
み「UIとかも割と揃っていて、Uno Gallary にWebなり、モバイルなりで、Material とFluent のUIを使い分けれたりとかダークモードとかブラシもあったりとか。」
み「なんかこの辺ってもしかしてMAUIと競合とかになってくるのかなと、ちょっと思いながら見てますね。」
し「同じC#で書けるクロスプラットフォームなUIをフレームワークという観点だと完全に一緒ですね。」
し「僕は、どこまで共通化ができるのかみたいなのがちょっと気になる。」
み「どうやらMVPが作ってるらいしいのね。」
み「ワンちゃん、買収してくれへんかなと思ってたりする。」
チ「ね。MAUIのロードマップとか含めても、十分なかまだこの辺は動きがありそうですね。Uno Platform含めて、どんでん返しがあるような気もしないでもないです。」
み「.NET 5もそうだし、.NET 6もそうだし、その間でチェックしておくと面白いかな。今は。」
し「ちょっとやっぱ、このMAUIは進みの悪さに。」
み「もうそうだから、Webは羨ましいなって。」
し「なぜかねー、MicrosoftはNative系のUIを作るのが苦っていうね。」
み「.NET CoreとかもWebが先で、がんがんいろんなね、それこそAsyncEnumerableとか使えたのもWebが先だったんで。」
み「そういう機能がC#の言語機能だったりとか.NET 5のSKDのなんやかが、UIライブラリとかクライアント系とかライブラリとかに使えてくるようになると今後ちょっとおもしろくなってくるのかぁという感じかなと静観しています。」
チ「ちょっと注目ですね。確かに。」
み「言い方変えればまだ注目ぐらいでよいかなって。」
し「まだいじろうにも、今回、.NET 5のリリースのタイミングでMAUIのプレビューがでるかと思ったんですよね。late2020って書いてあるんで。」
し「アメリカの人たちにとってのlate2020というのは11月だと思ったんですけど、12月はお休みでみんな仕事しないはずなんで。」
し「と思ってたんですけど、なんとプレビューが出なかったという。正直この瞬間、不安を。」
チ「で、キーノートでXamarin.Forms 5のデモしてただけでしょ。」
し「MAUIの一言も言ってなかった気がしますね。」
チ「でなかった気がする。」
し「Xamarin.Forms 5だけ出てて。」
チ「そうそっちでしたね完全に。」
し「MAUIはそういや話がなかったなって。」
み「ちょっとそっとしてあげておいた方がいいじゃない。」
チ「みなさん動向は注目しつつ、今のところはそっとしておいいてあげてくださいという感じでしょうね。」
し「まーフェードアウトしている可能性もある。個人的にはnamespaceをSystemから始めるのは失敗の雰囲気がする。」
一同 (爆笑)
チ「なるほどね。」
し「だいたい、後で、大幅なリネームとか発生して、ぐちゃぐちゃになるみたいな予感がする。ちょっと怖いなっていう。」
み「なんかあくまで僕の周りあるいはお仕事の観点ですけど、やっぱりクライアントって最近下火で、今まで作ってたクライアントアプリをWebに持っていきたいみたいな仕事も多いし。」
み「正直そうですね、やっぱりWebで作りたいあるいは社内のインフラからWebから見せるようにしたいよみたいなお客様はいるので、どちらかというとクライアントをバリバリやるというのはあんまりお仕事ではないかな。」
み「僕としては手慣れているのでまずスクラッチとかプロトタイプをクライアントでパッと作ってって、WPFとかもそうですけど、.NET Coreが来て、.NET 5がきて、なんでほぼMVVMとかをつかったりするとメソッド単位では、ASP.NET とWPFと共存できたりしちゃったりするし。」
み「同じnugetのプロジェクトで使えたりするので、プロトタイプをWPFで手慣れてるから作っちゃって、同じコードを使って、APS.NETで本番作り直すみたいなことはしてますね。」
チ「そうなってくるとC#ベースでまずクライアントを先にプロトタイプ作っていきます。じゃ、完成しましょうというときに、それこそさっき言ったBlazorとかを使ってそのままWebに移行していきます。メインはC#のままいけますみたいのは、その流れというのは1つトレンドとしてあるんでしょうね。」
み「ようやくバージョンがそろって共通化されて、書き捨てるコードが減ったというのは嬉しいですね。」
チ「なるほど。」
し「Uno PlatformさっきWebAssemblyもあるって書いてある。」
み「あるよ。」
し「ブラウザに移るにも。」
み「Uno Gallary自体がすでにUnoでブラウザで作られているんじゃないかな。WebAssemblyベースなんで。」
し「えっ！？」
み「あと、Windowsで動いている電卓を丸々移植したぜってというのがあって、移植されたWindowsの電卓はWebでmacでもiOSでもAndroidでも動くというデモはそれぞれのストアーに公開されてたりします。」
チ「うん。」
し「結構、案外使われていたりする。」
み「案外いろいろできる。映画のチケットとかも、ナショナルジオグラフィックのラーニングにも使われてるらしい。」
チ「Channel 9のアプリにも。」
み「へーそれしらんかった。」
し「これは、Unoが作ったサンプルアプリですよね。」
み「勝手に作ったやつかな。」
し「やばいな、Microsoftがこれやってたらどうしようかなって。」
し「これか、Calculator。」
み「Google Playにも、App Storeにも。」
チ「くりそつじゃないですか。」
ま「この見覚えのある。」
チ「見覚えのある。」
さ「なぜかWindowsの電卓のソースコードが公開されてるからですよね。」
み「そうなんですよね。そそそ。公開されてるんですよね。」
み「モバイル版だとちゃんと横に向けると関数電卓になったりとかするんじゃないかな。」
し「すごい、これ普通にちゃんと日本語出ているのがポイント高いな。」
し「かなり広がってきて、楽しいなー。」
し「プロトタイプとかで、ライブラリとが全部共通化できて。」
み「最初Wikiに触った感じだと、若干安定していない、こういうことは書けないみたいのがあったんですけど、もしかしたら、バージョンが上がって、安定性も上がってるかもしれないですよね。」
し「ちゃんとダークモードにも対応してる。」
し「ちょっとUno Platform買収かな。」
一同 (爆笑）
し「半年後ぐらいに買収されてきそうな気がしてきましたね。」
し「で、MAUIがそのまま入れ替えるみたいな。そういう未来もありそうな気がします。」
し「今回クライアントの話あまり聞けないかなと思ったんですけど、話がでてきて面白い。」
し「Uno Platform、自分で触ろう遊ぼうとは全然思ってなかった。」
チ「私も勉強になりました。名前ぐらいしか聞いてなかったので。実際、状況として勉強になりました。」
チ「MAUIがどうなるかはちょっとノーコメントとさせていただけたらと思いますけれども。」
Windows 向け機能 / その他
スライド
動画
https://youtu.be/HJ802p3syTw?t=5294
ARM64 Performance in .NET 5
し「Windows 10のARM64、Surface Pro Xというパソコンですね。それで、Nativeでで動くようになったんですけど、SDKも公開されて、Suraface Pro X上で、ASP.NET Coreアプリケーションとかも動くようになっているす。」
し「でも、一番欲しかったWPFが入ってなくて。」
チ「そっか。」
み「でも、UWPは動くでしょ？」
し「UWPはNativeにビルドするから、.NET Coreと関係なくて。」
し「ちなみに、UWPは最後に更新されたのが1年くらい前だと思う。」
み「大丈夫なのか？」
し「実質死んだでしょ。これね。」
一同 (爆笑)
チ「ノーコメントで行きましょう。」
し「これ死んだなと思う。と思ってます。」
み「今日はじめてUWPと言ったけどね。」
し「だからUWPがくると思ってなかった。」
し「これは死ぬんじゃないかな、正直。」
し「でもこれで、WindowsのARM64サポートで.NET CoreのコードジェネレーターとかJITコンパイラーとかがARM64のコードを普通に吐くようになってたので、LinuxのARM64、Linux ARM32に対応したんですが、この間、発表になったApple SiliconのMacBookとかのサポートが徐々に始まっているらしい。」
し「Pull Requestもいくつか出てて、そこへのサポートがひょっとして、6では普通に入ってくるかもしれないな。」
し「その辺りでクロスプラットフォームUIフレームワークの価値も出てくるかもしれないですね。」
チ「そうですね、確かに。」
し「Nativeアプリで動くって超重要だと思う。その辺りはあのARM64、あのMacがどのくらい売れるか分からないんですけど、結構主流となってくる可能性もあるかなっていう思い。」
し「デバイス適当に買って、Windowsですけど、買って遊んでるという感じです。」
チ「しばやん買ったんですか？」
し「僕はPro Xを持ってます。」
し「結構、電池持ちもいいし、パフォーマンスも悪くないし、結構いい。」
Announcing C#/WinRT Version 1.0 with the .NET 5 GA Release
し「唯一UWPっぽい話題がこのWinRT APIを利用する機能がついたってやつ。」
し「僕も最初全然知らなくて、Microsoftの太田かずきさんのツイートとかブログ見て、こういう書き方できたんだって思ったんですよ。」
し「今日、度々出てくるTFMって、昔、Target Framework Monikersだったのが、Target Framework Names
になってます。ここでは、Monikersって書いてあるんですけど。微妙に名前が変更されてて。」
し「UWPといかWinRTのAPIを叩くのってめんどくさかったんですけど、nugetで謎のパッケージ入れないと使えなかった。」
し「そこのTFMに-Windowsとバージョンを入れるとそれだけで、トーストとかのAPIも普通に叩けるようになる。」
チ「これは知らなかったな、私も。」
し「これはちょっと便利。」
し「でも、それだけなんですよね。」
一同 (爆笑)
チ「ちなみに私もWinRT周りについて詳しくないですけど、実際に.NET側からWinRTのAPIを叩くケースって結構あるんですか？」
し「実はそれあるんですよ。」
し「スタートアップ起動とか常駐アプリケーションとかだと今だとSlacとか普通にWindowsと上がってくるじゃないですか。タスクマネージャーでスタートアップとかいうタブ増えてて、そこから選べるんですが、あれって登録するAPIがWinRTにしかない。」
チ「なるほどね。」
し「常駐するアプリケーションとかは、普通にWPFを作りたいですが、今まではレジストリとか直接いじるとかしないといけなかったのが、APIだと一発なんです。」
し「あと、他にもセンサー系のAPIとか、いろいろいいですよね、デバイスいじる時。」
し「便利ちゃ、便利なんですけど、ちょっと使い勝手が悪かったです。なぞSDK入れたり。」
し「だから、公式サンプルは新しい書き方と、古い書き方と、もっと古い書き方がごちゃまぜになっていて、何が最新か分からないです。」
チ「ありがちな部分。」
し「だいぶこういうふうな感じマシになったなと。」
し「WinRTのAPIも正直どこまで使えるｋわからないですけど。」
し「ちょっとこの辺りは普通に書こうっていうには便利です。」
Announcing Version 1.0 of .NET for Apache Spark
し「最後、その他というので、微妙に関係があるようでない、.NET for Apache Sparkがですね。 .NET Standard 2.0 で。」
し「Apache Spark、今だとやっぱりPythonか、元がJavaなんで、バインディグでPythonとかで書く世界なんですよ。やっぱりなれたC#で書きたい。」
し「2週間ぐらい前に、別のイベントで、Azure Synapse Analyticsとかやったんですが、やっぱりPythonも読めるけど、やっぱりC#で書きたい。型とか欲しい。とかあったんで。」
し「この辺1.0で正式リリースになったんで。Azureのサービスとかで組み込まれていくとかなり個人的にはうれしい感じです。」
チ「.NETもいろんなアプリケーションも作れますし、AIという要素もずっと謳われてて、ご存知のお方もいると思いますが、ML.NETがあるじゃないですか。.NETでモデル作って、C#の中で使っていけるのような。それを合わせて、Sparkベースで、C#で書いてける。」
チ「その辺も含めてちゃんとやってるよというのはこういうところに出てますよね。1.0になったというのは。いいことだと思います。」
Project Reunion
し「Twitter見てると、かずきさんがProject Reunionとつぶやいてくださってるんですが、完全にわすてました。」
チ「Project ReunionってWin UIのとこでしたっけ？」
し「ですね。分断されたAPIを統合するまで。」
し「本当にProject Reunionのリポジトリ ってあるんですね。CIが落ちてるのは、不吉な予感がしますけど。」
し「成功を祈ります。」
し「ちょっと不安、いやちょっとじゃない、だいぶ不安ではあるです。」
し「なんかこういうWin RTをまとめた人もWin 32とかWPFがとかの統合とかいう話をしてた気がするんですよね。UWPとかも。」
し「そういう統合するという壮大な計画はだいたいオチが見えるみたいな。」
し「リリースされるのを一応待ちます。」
し「一応これでスライドは全てです。予定してた時間はこれで終わり、本当だったらこのあとQ&Aとかを入れようと思ったんスけど都度入れつつ、Twitterとかで拾いつつやったので、Twitterも見てたんですけど、特にめちゃくちゃ多かったというわけでもなかったので」
み「コメントが多いですね。」
し「そう、コメントが多い。」
し「MAUIはちょっと評判悪くしてしちゃかもしれないですね。」
一同 (爆笑)
XAML Standard
み「あー、なんか、XAML Standardと言ってる。」
チ「XAML Standard！！」
し「XAML Islandとか言っちゃダメだと思う。」
チ「XAML Standardを知ってる方がいらっしゃいましたか。」
し「あれ、結局、リポジトリがほぼ空っぽのまま終わったという。」
チ「終わりましたねー。XamarinのXAMLとXamarin.FormsのXAMLとWPFと全部統合しましょうってやつです。」
み「Reunionにも似た雰囲気あるよな。」
チ「そんだけ統合というのは難しいということなんですよね。」
し「難しいのは分かるんで、いつか成功して欲しい気持ちはあるんですが、当分無理な気がします。」
し「一応枠的には22時までとっているのでそこまでは僕らで。」
番外編
動画
https://youtu.be/HJ802p3syTw?t=5940
LTS
み「あと、楽屋裏でちらっと話してたLTSの話はする？」
し「あー、LTSの話はしておかないといけない。」
チ「あーそうですよね。あれ楽屋裏で話してたやつですよね。」
し「確か、それまつむらさんが、.NETのライフサイクルについてQiitaでしたっけ？」
し「確かに、TLSの話しはしておかないと、XAML StandardとかXAML Islandはなかったいいねみたいな感じで。」
し「お笑い担当にみたいになって本当はよくないと思う。変えてって欲しい。」
チ「大事。大事。」
ま「 .NET Coreのサポートポリシーをまとめた これね。」
チ「サポートポリシー大事ですね。」
し「サポートポリシー超重要。」
ま「一応がんばってアップデートしているつもりです。」
し「超重要ですよね。」
ま「これ結構大事なんですよね。」
し「結構、みんな油断するのがこのCurrentとかがLTSがリリースされた後の3ヶ月間とか、後続のやつがリリースされた3ヶ月間とか結構短いですよね。」
チ「LTSは3年。次のLTSが出てから1年という話がだいたい。」
し「今は、LTSとCurrentしかないですよね。他全部EOLになってる。」
ま「はい。」
ま「カレント使ったらがんばって3ヶ月ごとのアップデートとか、アップデートにアンテナ貼っておく必要があって。」
ま「それを気にしたくないんだったら、LTSを選ぶとかそんな感じじゃないですかね。」
し「この辺りは難しいですよね。常時開発してて、どんどん良くしていこうという形だと、新しいものを突っ込んでいって常時アップデートがされているという状況であれば全然Currentに追いつくのは簡単だと思う。」
し「LTSの絡みで面白い話があったの思い出しました。Azure FnctionsnのV2ってやつ、.NET Coreの2世代なんですが、あいつ一時、runtimeが.NET Core 2.2だったんですよ。」
ま「そうそう」
チ「あー、あったあった。」
し「2.2ということは、とっくにサポートが終わっている。(2019年12月23日)。公式が提供してるものが、サポート切れしているランタイム上でずっと動いてた。」
チ「あったね、あったね。」
し「なので、今、2.1に落としたんです。」
チ「あー、そっか。」
し「2.1に途中で落として、今は、実は、11月の頭に、Azure Function V2に関しても自動的に3.1を使うようにアップデートが走ったはずなので、3.1で動くようになっています。」
チ「一時期巷では話題になっていましたね。」
し「なんで、Azure Functionsは、2.1と3.1で動いてる状況なんですが、やっぱり、LTSを狙っているなという印象ですね。」
し「5がLTSにならないのは、ちょっとどうなるんだろう。」
チ「あー、6が出るまで動かないかも。」
し「LTSがまで1年って長いなっていう。」
チ「うんうん、そうですね。どちらを選ぶかみなさんが考える中で、LTSでとなるとしばらく3.1のままでしょうしね。そういったところでもAzure Functionsの 流れ的には.NET 6まで上がらない可能性はありそうな気もしますけど。」
し「Functionsチームが、ちゃんとCurrentに追いついてくれれえばいいんですけどね。」
チ「うんうんうん。」
し「.NET Confで話とかちょっとでなかったんですよ。」
し「Docker imageサポートとか、Docker imageとか残るんで、結構サポート切れても気が付かない。」
チ「そうですね。」
し「まとめていただいてるのはすごい助かる。」
チ「「これいいです。」
チ「サポートされるOS。」
ま「その辺もちょくちょく変わっている。サポート範囲というか。」
チ「.NET 5がでて、この辺少しアップデートがありましたね。確か一部切り捨てられたのもあったと思います。」
ま「確か、Windows Serverの古いやつとか切られたんですよね。たしか。あと、UbuntuのLTSがじゃないやつとかも気づいたら外れたたりしますね。」
し「確かに、ちょっと、Ubuntuはこの辺り(20.04, 18.04,16.04)は、LTSですもんね。」
み「.NET 6って来年の今頃に出るんや。」
チ「予定だと、そう、1年後の11月。」
まつ「1年間隔になった。」
み「また、その1年後に7、その翌年に8が出て。」
チ「奇数年に出てくるやつがLTSという一応定義になってますね。2021、2023、2025年のバージョンアップで出てくるのがLTS。予定としてはそういう形で組まれています。」
し「個人的には、5.1とかいうのがリリースされるのかというのがちょっと気になるんですけど。」
チ「あり得ると思いますよ。今言ってるロードマップのやつはメージャーバージョンアップって言ってるので、マイナーだったりリビジョンが変わったり、するてのは十分あると思います。」
し「リビジョンが変わるのは想像がつくですけどね、マイナーの話は全然出てこないんで。」
チ「そうね、マイナーとか、まそうね、可能性はあるかもしれないですね。」
し「アップデートに関しては非常に気になる。」
し「確かに、マイナーとかはどこかでリリースするかもってどこかで見たと思うんですけど。」
チ「そう、あの、そう、マイナーとかは必要であれば、その都度リリースしますみたいな記述は間違いなくあったと思います。」
チ「もしかしたら5.1というかちょくちょくでる可能性はあると思います。」
し「その辺りで、正直LTSになって欲しかったんですけど。」
チ「まぁ、そういう感じではありますね。1年というのは、長い感じはありますけどもね。」
チ「みなさんが.NET 5が出た中で、実際にどのバージョンを、もちろん試したりするんだったら5を使ってガンガン使っていただいて構わないんですけど、実際のプロダクション環境でどのバージョンを選ぶかは結構悩まれる方も多いもしれないですね。」
チ「いろいろ、会社を含めて、LTSだってのを重視される方は3.1のまま、しばらくは本番環境は3.1になるとは思いますけど。」
チ「さっき、楽屋裏でも話していましたけど、やっぱり最新のを常にバージョンアップをしていく流れの中で、CI、CD、自動化のパイプラインを作ってビルドテスト含めて組んでいけば、最小の変更だけで、常に最新のものが使える。それはそれですごいメリットではあると思う。」
チ「実際、みなさんがどういう選択をするのか、プロジェクトのリクワイアメントにもよってくる部分もあると思いますけども。」
チ「やはり、そういうなんで今のトレンドじゃ、んで、CI、CD、DevOpsみたいな話が出ているかというと、そういったところで常に最新のを使って最新のパッチ当たって、セキュアであって、そういったライブラリ、パフォーマンスの面も含めたところも向上されている。」
チ「そういったところをしっかりメリットと捉えて、まぁLTSは関係なく、アップデートがあれば、すぐにアップデート当てられる。」
チ「少ない変更で、すぐアップデートができるような環境を整えるのも、1つの今の開発環境を整えるのも大事だと思う。」
チ「そういったことをみなさん考えていって、環境を整えていってだいただけるといいのかなと思いますね。」
し「なんかもう締めに向かって話している。」
チ「だって、大事なところですから。」
し「すごい重要ですよね。」
し「なんだかんだLTSを選ぶイコール3年間はまぁあんま面倒見ませんみたいな。」
チ「塩漬け。」
し「感じがしちゃうんで。」
し「新しいものはそれなりにいろんな機能が入ってくるで、その辺楽しんでこうアップデートできるぐらいの方がいい。」
チ「仮に3.1のままいって、6がでてアップデートしようとした時の変更点を考えるとやっぱりすこしずつアップデートしていった方が、私は今の状況を見ると楽かなと思うんです。」
ま「3.1から6には一気にはアップデートには大変な部分があるとおもうから、1回5にアップデートしてから6にあげるというステップがあると思う。」
し「そこもアップグレードのドキュメントも、1個ずつしか書いてない。 3.0 to3.1、3.1 to 5.0。」
チ「そうだよね。」
し「基本的に一足飛びにに、例えば2.0から5.0に行きますという都合のいいドキュメントは世の中には存在しないですよね。」
し「地道に1つずつ、この時期にやった方がいい。」
し「2.1で塩漬けしてたら、5.0に追いつくためには、ここのステップ（2.1 to 2.2、2.2 to 3.0、3.0 to 3.1、3.1 to 5.0）からやると。」
チ「大変ですね。」
み「そうそうそう。」
し「それは正直大変です。」
し「だいたいそういう風に塩漬けしちゃうプロジェクトだとCIとかもちゃんとテストとかも、たぶん回せない。」
チ「回ってない、回ってないときもありますよ。」
し「そういう時に一足飛びにやるというのはかなりリスクになっちゃいますよね。」
し「こまめににアップデートで、楽しくやっていけたらいいなと思うんですよね。」
チ「開発エンジニアとしては、やっぱり最新のものを使いたいと思いませんかね、みなさん。」
し「趣味プログラミングだとホント、普通に最新をやりたいんですけど、業務だとちょっと難しい部分がありますよね。」
し「でもruntimeに関しては、僕は基本、最新を使うし。」
チ「最新ですね。まぁ大事だな。今の流れだと特に大事だと思いますね。」
ま「結構Azureとかも.NETのアップデートにリアルタイムじゃないけど、結構近いタイミングでアップデート入って最新のランタイムが動作するというのいいですよね。」
チ「今回のAzure App Service早く来ましたよね。」
し「今回は、そういう謎テクロジーが導入されて。」
一同 (爆笑)
し「Early Access Runtime という。」
チ「たしかにすぐ分かるからね。」
し「ちょっとこの辺りブログ に書いたんで、適当に見てもらえればいいです。」
し「なんか入ってないランタイムをアプリケーションの起動時というか初期化時に自動的にいれちゃうという。」
し「なかなか過激な実装だなと思う。」
チ「すごい。」
し「平均でなんか30秒くらいで終わるようなみたいなこと言ってたんですけど、僕が試した時には1分ぐらいかかってましたね。」
し「ちょっとまぁ不安なんですが、最初の1回だけなんで全然いいかなと。」
し「まぁこれぐらいだと、Azure App Serviceってだいたい2ヶ月に1回OSのリイメージ、クラウドサービスのOSのアップデート入ってるんで、だいたいそこのタイミングまで待たないといけなかったんですけど、Early Access Runtimeだと実行時に入れちゃうんで、他の環境に影響でないです。だから素早くできる。」
し「僕も今いくつかプロジェクトを持ってますけど、速攻で5.0への対応を入れてます。もう、あとリリース待つみたいな。」
み「すげー」
し「はい、もうそれ、Eacly Accessです。」
ま「Early Access RutimeってAuzre App Serviceのサービスプランの種類の制限とかあるんですか？フリーがダメとか。」
し「種類はなかったです。たしか。」
し「すべてのパブリックリージョンのすべてで使えるみたいなことが書いてあったと思う。」
し「でもちょっとフリーは分からないですね。」
し「Windowsはちょっと特殊なんですが、Linuxの方は、ベースのDocker imageがキャシュされていないってだけなんで。」
し「今回、5.0のDocker imageはだいぶ小さくなったって言ってるんで、全然影響ないんじゃないかなっていう印象ですね。この辺りは普通に使って。」
し「だんだんアップデートできない理由がAzure App Serviceの対応待ちみたいになっている。」
チ「うんうん、ありますねー。」
し「チャットとか見てると、結構業務の闇が。」
し「VBの話、今回全くしなかったんです。」
チ「昨日、一昨日とお客さん先のセミナーで.NET アップデートみたいな話を2時間ぐらいしてたんですけど、その時の質問でやっぱりVBの話が出ましたね。」
チ「みなさんなんだかんだで、今C#ばっかりなんで、実際VBどうなのなのと言われて、うんそうだよねーって思って、ちょっと答えたんですけど。」
し「一応、VBはもう新機能が足されない、追加しないというのは発表されてましたよね。」
チ「言語仕様、言語的にはそうですね。基本的にはプライマリー言語としては、C#ですよね。」
チ「プロジェクトとしてはVBは.NET 5のSDKで、ちゃんと、WinFroms、WPFとかのプロジェクトはVBでも作れるようになってますけど。」
チ「まぁこれから今から新規にとか作っていくのにどの言語を選ぶかって言ったらほぼC#一択だと思いますね。現状、正直なところ。」
し「一応今回、F# 5もリリースはされているですが、ちょっとあのまぁ気軽にそこを言えない。」
し「知識がない人間が偉そうに言うのも全然良くないと思うんで。」
し「なんで、今はC#とF#の2つって感じですよね。」
チ「一応VBも使えますが、そういう状況ですということを把握した上で、VBの既存のVB.NETみたいなコードがあって、まぁそれを上手く使ってまだやりたいっていうケースはもちろんVBでそういうWPFだ、WinFormsだという特にそういうニーズはあるかもしれないですね。」
チ「WinFormsだったら結構あるかもしれないですけど、移行は可能ではあります。」
チ「新規になんかを作ろうとしたら、もちろん.NET 5ベースでWinForms、WPFを選んでくれていんですけど、ただ言語はC#にしておいた方がたぶんいいですね。」
チ「今回のC# 9も含めてやっぱり言語仕様的なところでもいろいろ日々改善が加えられ、新機能も入ってきているので。そういったところを考えるとC#がいいと思います。」
し「ちょっと質問で、Azure App Serivceに.NET 5が来た時に、Early Access Runtimeってどうなるんだろうというのがあったんですが、それは、勝手にEarly Access Runtimeではなくなります。」
チ「うん。」
し「だから気にしなくていいんですね。」
し「OS側にインストールされたら、プリインストール状態のままになるんです。」
し「なので設定しておけば勝手にコールドを使ったらパフォマーンスがよくなる話。」
ま「デプロイのし直しとかしなくていいんですね？」
し「いらないです。いらないです。勝手に。Azure App Serviceって常になんだかんだで、インスタンスって変わってるんで、1ヶ月に10回ぐらい変わったときもあった。」
さ「.NET 5 RCのころに、self-containedであげたんですけど、self-containedじゃないほうがいいとかその辺の違いってどういう風に考えたらいいのか。」
し「self-containedは、ASP.NETだとどのくらいだろ、100MBぐらいになります？ならないですよね。」
さ「60～70MBとか。」
し「そうですよね。そいつらをマウントして、ライブラリを全部読み込んでっていうところのAzure App SeriveってI/Oが遅いんですよ。読み込むファイル数は明らかに減らした方がいいんで。」
し「今回、Early Access Runtimeを使えるようになったタイミングなので、そこでself-containedのまま、Early Access Runtimeを有効にしても、self-containedそのまま動くんで、そのあとデプロイしなおして上げればいいかなと思う。」
し「いい感じに残り2分となってので、最後のスライドに。」
今後開催される .NET Conf 関連イベント
- 11/27(金) 19:00～21:00 .NET 5 リリース記念 C# Tokyo イベント
- 12/05(土) 13:00～15:30 Visual Studio Users Community Japan 勉強会 #6 .NET 5 launch / .NET Conf 2020
- 12/19(土）14:00～16:30 .NET 5 技術セミナー！最新の技術情報を共有しよう！# .NET Conf2020
し「今日は、平日のよるに長いイベントにみなさん参加頂いて、ありがとうございます。」
し「今後、僕らは、.NET Confが終わってすぐ、.NETが好きな人間が自分が好きなことをしゃべっていたんですが、今後いろんなイベントが開催される予定です。」
し「直近だと今月27日にC# Tokyoというコミュニティーでリリース記念のイベントがあります。」
し「来月、12/05にVisual Studio Users Community Japanのイベントで、ここであの@ufcppさん、C#でググれの人がC#9について話してくれます。ディープな話が 聞けると思うので見逃せない。」
し「12/19の.NET 技術セミナーは、IoT ALGYANですかね、チャックさんが.NETについていろいろしゃべる予定になています。」
し「これらのイベントとか、ブログとかTwitterとかいろいろ、とさらに個人とかYoutubeとか配信とかあると思うんですが、こういったものをいろいろ参加して、さらに.NETを楽しく勉強して使っていければいいなと思います。」
し「それのキックオフみたいな感じで、この会が役になってもらえば、今回行った甲斐があったなと思います。」
し「イベントとしてはこれで以上になります。」
チ「こういうトーク面白いですよね。今まであまりこういう形でやってなかったんですけど、なんかこういうラフにこういう話をして、.NET周りのアップデートが知れるといのは、みなさんとしても結構面白かったんじゃないかーっていう。」
チ「参加してる側もなんか普通に気楽にいろいろあーだ、こーだー喋ってる。勉強になるところもたくさんありました。」
チ「なんか定期にこういう感じでフリートークやるのも面白かなとちょっと思っちゃいましたね。」
し「.NET 5リリース記念パーティートークは以上になります。Youtubeで参加されてたみなさん、あとスピーカのみなさん、今日はありがとうございました。」
資料
スライド
speakerdeck.com動画
youtu.betoggetter togetter.com
感想
機能内容や背景、目指すものものなどを含めての話だったので、大変興味深く視聴させてもらいました。
ちょくちょく小ネタが入ってきて面白かったです。
ドキュメントもどういったものがあるのか、新機能や非互換情報をどうやってたどればいいのかと、.NETの地図を手にいれたような感じです。
.NET、Azureは疎いので、文字起こしするには、用語、略語が厳しい。。。(もうやらない。)
