SlideShare a Scribd company logo
今から始める、Windows 10&新 
.NETへの移行戦略 
岩永信之
本日のテーマ 
Windows 10 & .NET 2015を見据えて 
今すぐに対応できること 
.NET 2015までに準備すべきこと 
おすすめの開発指針
まずなによりも、業務系において 
.NETは「変えないこと」の大切さをわかってる 
既存のアプリ 
既存の.NET 
(.NET 4.5) 
既存の.NETで動いてたなら 
だいたい※動く 
.NET vNext 
(.NET Core 5) 
• 事前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 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どころか…
.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でないと使えないことも 
多々あるかと思われます
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 
割と単純な構文糖衣ばっかり 
ライブラリ依存の機能なし 
.NET 2.0で動く 
.NET 4.5で動く 
「Windows 7だからC# 3.0」とかやめて
統制 
統制取りたいから新機能使わせたくないって? 
Privateな部分にうるさく言ってもしょうがない 
C# 6.0が影響するのはprivateなところばかり 
int X(int x) 
{ 
return x * x; 
} 
メソッドの外から見えてる情報 
はここだけ(変わってない) 
ここがレビューしにくいなら、何か別の問題あり 
 メソッド1個1個が大きすぎるとか 
 変数名がちゃんとついてないとか 
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 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
問題: 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 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つのエコシステムの上で、必要とされる部分を、素早く、制御可能な形で提供
“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参照プロジェクト参照 
.csproj内NuGetパッケージ参照 
<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パッケージ参照→ プロジェクト参照
パッケージ単位のコード解析・補完 
今までの問題: 文脈読まずにコード補完 
例: コードスニペット 
依存関係プロパティ 
• XAML系プロジェクト 
• プロパティが書ける文脈でしか使わないのに 
これから: パッケージ単位で配布可能 
.NET Compiler Platformを使って作ったコード解析をNuGet配布 
ライブラリにコード解析を同梱可能 
例えば… 
 JSONライブラリに、文字列リテラル中のJSON解析を付ける 
常に出る
パッケージ単位のコード解析・補完 
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 developers 
Every applications 
.NETをすべての開発者に
多様なアプリケーション 
.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も!」 
、これからさらに広がる
過渡期 
一度大きく振らないと行けないことはある 
A B 
新しいチャレンジの際の過渡期 
最終的には間に落ち着いたり、両方半々になったり 
A AB B A & B 
成熟の証 
結局、全部ほしくなる 
この状態に対して 
「既存顧客を捨てるのか」とか 
「そんなの流行らない」とか 
言っちゃダメ 
「ほらダメだった」とか 
「やっぱり戻ってきた」とか 
言っちゃダメ
Windows 8 → 10 
Windows 10 
デスクトップ回帰 
エンタープライズ回帰 
Mouse 
Keyboard 
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 
(個人の経験で言うと) 
Visual Studio以外を全く想定してなくて 
割かし最近の機能をふんだんに使って 
仕事用のそこそこの規模のソリューションが 
普通にMac上でのXamarin Studioでビルド通せた 
ちなみに、C# 6.0は、公式サイトで仕様が出てくるたびに即座に対応 
 Discussionに情報が出た数日内にはMonoに関連コミットがあったり 
※ むしろLegacyな機能の方が怪しい… 
フルパス指定が必要だったり、 
パス中の と/ で困ったり
選べる大事さ: 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のサンプルあり
選べる大事さ: OWIN※ 
Webサーバーとアプリケーション間のインターフェイス仕様 
Func<IDictionary<string, object>, Task> 
環境変数、リクエスト、レスポンスをDictionaryを使ってやり取り 
 どのキーにどの値を入れるかを規格化† 
非同期(Task) 
BCL提供の型しか使わない 
どこででも、何ででも動く 
• Webサーバーが何でもいいのはもちろん 
HTTPである必要すらない 
• アプリの下にミドルウェア挟むのも楽 
※ Open Web Interface for .NET 
† objectのままだと使いにくいので、適切なキーで適切な型でとりだせるラッパーライブラリあり(Microsoft.OWIN)
補足: 依存を減らす 
フレームワーク、サーバー、OSへの依存を減らす 
(ASP.NET 5みたいな)差し替え可能なモジュール提供 
(OWINみたいな)標準ライブラリのみへの依存 
(MVC, MVVMなどの)分離しやすいアーキテクチャ 
 Modelの比率を増やすよう頑張るべき 
依存を減らすことで 
幅広いプラットフォーム対応 
変化への対応 
依存を減らせる技術は 
積極的に取り入れるべき 
しなきゃいけない?
補足: 依存を減らす 
フレームワーク、サーバー、OSへの依存を減らす 
(ASP.NET 5みたいな)差し替え可能なモジュール提供 
(OWINみたいな)標準ライブラリのみへの依存 
(MVC, MVVMなどの)分離しやすいアーキテクチャ 
• 開発者は本音では新しいものを使いたい 
• できないのは、入れ替えのコストが高いから 
• そのコストが下がるのならば… 
 Modelの比率を増やすよう頑張るべき 
依存を減らすことで 
幅広いプラットフォーム対応 
変化への対応してもいい!
補足: 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クラス利用
まとめ 
今はターゲットを広げる時期 
レイヤー化、モジュール化、選べる大切さ 
パーツごとに差し替え可能な構成 
変えたいときに、変えたい場所だけ変える
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 
自社の得意なところは自社で、そうでないところは外部と連携

More Related Content

What's hot

2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー
2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー
2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー
Hub DotnetDeveloper
 
C#/.NETがやっていること 第二版
C#/.NETがやっていること 第二版C#/.NETがやっていること 第二版
C#/.NETがやっていること 第二版
信之 岩永
 
C#言語機能の作り方
C#言語機能の作り方C#言語機能の作り方
C#言語機能の作り方
信之 岩永
 
dotnetconfJP2017_netcore2
dotnetconfJP2017_netcore2dotnetconfJP2017_netcore2
dotnetconfJP2017_netcore2
Yusuke Fujiwara
 
.NET Core 2.x 時代の C#
.NET Core 2.x 時代の C#.NET Core 2.x 時代の C#
.NET Core 2.x 時代の C#
信之 岩永
 
Bluetoothでgo!
Bluetoothでgo!Bluetoothでgo!
Bluetoothでgo!
Kouji Matsui
 
Orange Cube 自社フレームワーク 2015/3
Orange Cube 自社フレームワーク 2015/3Orange Cube 自社フレームワーク 2015/3
Orange Cube 自社フレームワーク 2015/3
信之 岩永
 
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
Takaaki Suzuki
 
.NET Core とマルチプラットフォーム
.NET Core とマルチプラットフォーム.NET Core とマルチプラットフォーム
.NET Core とマルチプラットフォーム
shozon
 
動的なILの生成と編集
動的なILの生成と編集動的なILの生成と編集
動的なILの生成と編集
terurou
 
.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み
Kouji Matsui
 
基礎からのCode Contracts
基礎からのCode Contracts基礎からのCode Contracts
基礎からのCode Contracts
Yoshifumi Kawai
 
JavaScript Tips 2015(PDF 版)
JavaScript Tips 2015(PDF 版)JavaScript Tips 2015(PDF 版)
JavaScript Tips 2015(PDF 版)
taskie
 
今からでも遅くないC#開発
今からでも遅くないC#開発今からでも遅くないC#開発
今からでも遅くないC#開発
Kazunori Hamamoto
 
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
hecomi
 
Golang tokyo #7 qtpm
Golang tokyo #7 qtpmGolang tokyo #7 qtpm
Golang tokyo #7 qtpm
Yoshiki Shibukawa
 
SignalRブートキャンプ
SignalRブートキャンプSignalRブートキャンプ
SignalRブートキャンプ
Kouji Matsui
 
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
Yoshifumi Kawai
 
Introduction to NotifyPropertyChangedGenerator
Introduction to NotifyPropertyChangedGeneratorIntroduction to NotifyPropertyChangedGenerator
Introduction to NotifyPropertyChangedGenerator
Yoshifumi Kawai
 

What's hot (20)

2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー
2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー
2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー
 
C#/.NETがやっていること 第二版
C#/.NETがやっていること 第二版C#/.NETがやっていること 第二版
C#/.NETがやっていること 第二版
 
C#言語機能の作り方
C#言語機能の作り方C#言語機能の作り方
C#言語機能の作り方
 
dotnetconfJP2017_netcore2
dotnetconfJP2017_netcore2dotnetconfJP2017_netcore2
dotnetconfJP2017_netcore2
 
.NET Core 2.x 時代の C#
.NET Core 2.x 時代の C#.NET Core 2.x 時代の C#
.NET Core 2.x 時代の C#
 
Bluetoothでgo!
Bluetoothでgo!Bluetoothでgo!
Bluetoothでgo!
 
Orange Cube 自社フレームワーク 2015/3
Orange Cube 自社フレームワーク 2015/3Orange Cube 自社フレームワーク 2015/3
Orange Cube 自社フレームワーク 2015/3
 
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
 
.NET Core とマルチプラットフォーム
.NET Core とマルチプラットフォーム.NET Core とマルチプラットフォーム
.NET Core とマルチプラットフォーム
 
C#の書き方
C#の書き方C#の書き方
C#の書き方
 
動的なILの生成と編集
動的なILの生成と編集動的なILの生成と編集
動的なILの生成と編集
 
.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み.NET Coreから概観する.NETのOSSへの取り組み
.NET Coreから概観する.NETのOSSへの取り組み
 
基礎からのCode Contracts
基礎からのCode Contracts基礎からのCode Contracts
基礎からのCode Contracts
 
JavaScript Tips 2015(PDF 版)
JavaScript Tips 2015(PDF 版)JavaScript Tips 2015(PDF 版)
JavaScript Tips 2015(PDF 版)
 
今からでも遅くないC#開発
今からでも遅くないC#開発今からでも遅くないC#開発
今からでも遅くないC#開発
 
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
 
Golang tokyo #7 qtpm
Golang tokyo #7 qtpmGolang tokyo #7 qtpm
Golang tokyo #7 qtpm
 
SignalRブートキャンプ
SignalRブートキャンプSignalRブートキャンプ
SignalRブートキャンプ
 
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
 
Introduction to NotifyPropertyChangedGenerator
Introduction to NotifyPropertyChangedGeneratorIntroduction to NotifyPropertyChangedGenerator
Introduction to NotifyPropertyChangedGenerator
 

Viewers also liked

Code Contracts in .NET 4
Code Contracts in .NET 4Code Contracts in .NET 4
Code Contracts in .NET 4
信之 岩永
 
今から始める、Windows 10&新.NETへの移行戦略
今から始める、Windows 10&新.NETへの移行戦略今から始める、Windows 10&新.NETへの移行戦略
今から始める、Windows 10&新.NETへの移行戦略
信之 岩永
 
それっぽく、適当に
それっぽく、適当にそれっぽく、適当に
それっぽく、適当に
信之 岩永
 
プログラミング .NET Framework 第4版
プログラミング .NET Framework 第4版プログラミング .NET Framework 第4版
プログラミング .NET Framework 第4版
信之 岩永
 
Keep yourself up to date
Keep yourself up to dateKeep yourself up to date
Keep yourself up to date
信之 岩永
 
.NET Compiler Platform
.NET Compiler Platform.NET Compiler Platform
.NET Compiler Platform
信之 岩永
 
C#や.NET Frameworkがやっていること
C#や.NET FrameworkがやっていることC#や.NET Frameworkがやっていること
C#や.NET Frameworkがやっていること
信之 岩永
 

Viewers also liked (7)

Code Contracts in .NET 4
Code Contracts in .NET 4Code Contracts in .NET 4
Code Contracts in .NET 4
 
今から始める、Windows 10&新.NETへの移行戦略
今から始める、Windows 10&新.NETへの移行戦略今から始める、Windows 10&新.NETへの移行戦略
今から始める、Windows 10&新.NETへの移行戦略
 
それっぽく、適当に
それっぽく、適当にそれっぽく、適当に
それっぽく、適当に
 
プログラミング .NET Framework 第4版
プログラミング .NET Framework 第4版プログラミング .NET Framework 第4版
プログラミング .NET Framework 第4版
 
Keep yourself up to date
Keep yourself up to dateKeep yourself up to date
Keep yourself up to date
 
.NET Compiler Platform
.NET Compiler Platform.NET Compiler Platform
.NET Compiler Platform
 
C#や.NET Frameworkがやっていること
C#や.NET FrameworkがやっていることC#や.NET Frameworkがやっていること
C#や.NET Frameworkがやっていること
 

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

ADO.NET Entity Framework
ADO.NET Entity Framework ADO.NET Entity Framework
ADO.NET Entity Framework
Microsoft
 
.NETクロスプラットフォーム
.NETクロスプラットフォーム.NETクロスプラットフォーム
.NETクロスプラットフォーム
Yasushi Kato
 
Intalio japan special cloud workshop
Intalio japan special cloud workshopIntalio japan special cloud workshop
Intalio japan special cloud workshop
Daisuke Sugai
 
20160709 .NET Core on RHEL
20160709  .NET Core on RHEL20160709  .NET Core on RHEL
20160709 .NET Core on RHEL
Takayoshi Tanaka
 
The Twelve-Factor (A|M)pp with C#
The Twelve-Factor (A|M)pp with C#The Twelve-Factor (A|M)pp with C#
The Twelve-Factor (A|M)pp with C#
Yuta Matsumura
 
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Codeどっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
Takashi Okawa
 
どうなる?Windows 8時代の業務アプリ開発
どうなる?Windows 8時代の業務アプリ開発どうなる?Windows 8時代の業務アプリ開発
どうなる?Windows 8時代の業務アプリ開発
Yuya Yamaki
 
.NET Coreとツール類の今
.NET Coreとツール類の今.NET Coreとツール類の今
.NET Coreとツール類の今
Yuki Igarashi
 
.NETラボ2021年10月 .NETの過去と現在
.NETラボ2021年10月 .NETの過去と現在.NETラボ2021年10月 .NETの過去と現在
.NETラボ2021年10月 .NETの過去と現在
TomomitsuKusaba
 
.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~
.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~
.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~
Akira Inoue
 
20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux
Takayoshi Tanaka
 
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Daizen Ikehara
 
Visual Studio による開発環境・プログラミングの進化
Visual Studio による開発環境・プログラミングの進化Visual Studio による開発環境・プログラミングの進化
Visual Studio による開発環境・プログラミングの進化
Fujio Kojima
 
デスクトップ アプリ開発における Visual Studio の進化
デスクトップ アプリ開発における Visual Studio の進化デスクトップ アプリ開発における Visual Studio の進化
デスクトップ アプリ開発における Visual Studio の進化
Katsuhiro Aizawa
 
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
日本マイクロソフト株式会社
 
新しい Visual Studio & .NET と新時代のアーキテクチャ
新しい Visual Studio & .NET と新時代のアーキテクチャ新しい Visual Studio & .NET と新時代のアーキテクチャ
新しい Visual Studio & .NET と新時代のアーキテクチャ
慎一 古賀
 
WPF & Windows Forms on .NET Core 3.0
WPF & Windows Forms on .NET Core 3.0WPF & Windows Forms on .NET Core 3.0
WPF & Windows Forms on .NET Core 3.0
ShinichiAoyagi
 
Hardware control by .NET Core 3.1
Hardware control by .NET Core 3.1Hardware control by .NET Core 3.1
Hardware control by .NET Core 3.1
Atomu Hidaka
 

Similar to 今から始める、Windows 10&新.NETへの移行戦略 (20)

ADO.NET Entity Framework
ADO.NET Entity Framework ADO.NET Entity Framework
ADO.NET Entity Framework
 
.NETクロスプラットフォーム
.NETクロスプラットフォーム.NETクロスプラットフォーム
.NETクロスプラットフォーム
 
Intalio japan special cloud workshop
Intalio japan special cloud workshopIntalio japan special cloud workshop
Intalio japan special cloud workshop
 
20160709 .NET Core on RHEL
20160709  .NET Core on RHEL20160709  .NET Core on RHEL
20160709 .NET Core on RHEL
 
The Twelve-Factor (A|M)pp with C#
The Twelve-Factor (A|M)pp with C#The Twelve-Factor (A|M)pp with C#
The Twelve-Factor (A|M)pp with C#
 
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Codeどっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
 
どうなる?Windows 8時代の業務アプリ開発
どうなる?Windows 8時代の業務アプリ開発どうなる?Windows 8時代の業務アプリ開発
どうなる?Windows 8時代の業務アプリ開発
 
20021007
2002100720021007
20021007
 
.NET Coreとツール類の今
.NET Coreとツール類の今.NET Coreとツール類の今
.NET Coreとツール類の今
 
.NETラボ2021年10月 .NETの過去と現在
.NETラボ2021年10月 .NETの過去と現在.NETラボ2021年10月 .NETの過去と現在
.NETラボ2021年10月 .NETの過去と現在
 
.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~
.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~
.NET Core 5 ~ Windows, Linux, OS X そして Docker まで ~
 
20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux
 
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
Net advantage 2012 volume2 最新情報 Windows Forms / ASP.NET 編
 
Visual Studio による開発環境・プログラミングの進化
Visual Studio による開発環境・プログラミングの進化Visual Studio による開発環境・プログラミングの進化
Visual Studio による開発環境・プログラミングの進化
 
ZendStudioのご紹介
ZendStudioのご紹介ZendStudioのご紹介
ZendStudioのご紹介
 
デスクトップ アプリ開発における Visual Studio の進化
デスクトップ アプリ開発における Visual Studio の進化デスクトップ アプリ開発における Visual Studio の進化
デスクトップ アプリ開発における Visual Studio の進化
 
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
 
新しい Visual Studio & .NET と新時代のアーキテクチャ
新しい Visual Studio & .NET と新時代のアーキテクチャ新しい Visual Studio & .NET と新時代のアーキテクチャ
新しい Visual Studio & .NET と新時代のアーキテクチャ
 
WPF & Windows Forms on .NET Core 3.0
WPF & Windows Forms on .NET Core 3.0WPF & Windows Forms on .NET Core 3.0
WPF & Windows Forms on .NET Core 3.0
 
Hardware control by .NET Core 3.1
Hardware control by .NET Core 3.1Hardware control by .NET Core 3.1
Hardware control by .NET Core 3.1
 

More from 信之 岩永

YouTube ライブ配信するようになった話
YouTube ライブ配信するようになった話YouTube ライブ配信するようになった話
YouTube ライブ配信するようになった話
信之 岩永
 
C# 9.0 / .NET 5.0
C# 9.0 / .NET 5.0C# 9.0 / .NET 5.0
C# 9.0 / .NET 5.0
信之 岩永
 
C# コンパイラーの書き換え作業の話
C# コンパイラーの書き換え作業の話C# コンパイラーの書き換え作業の話
C# コンパイラーの書き換え作業の話
信之 岩永
 
Unicode文字列処理
Unicode文字列処理Unicode文字列処理
Unicode文字列処理
信之 岩永
 
C# 8.0 null許容参照型
C# 8.0 null許容参照型C# 8.0 null許容参照型
C# 8.0 null許容参照型
信之 岩永
 
C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)
信之 岩永
 
async/await のしくみ
async/await のしくみasync/await のしくみ
async/await のしくみ
信之 岩永
 
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
信之 岩永
 
Coding Interview
Coding InterviewCoding Interview
Coding Interview
信之 岩永
 
非同期処理の基礎
非同期処理の基礎非同期処理の基礎
非同期処理の基礎
信之 岩永
 
C#とILとネイティブと
C#とILとネイティブとC#とILとネイティブと
C#とILとネイティブと
信之 岩永
 
Anders Hejlsberg Q & A
Anders Hejlsberg Q & AAnders Hejlsberg Q & A
Anders Hejlsberg Q & A
信之 岩永
 
C#マスコット(公開用)
C#マスコット(公開用)C#マスコット(公開用)
C#マスコット(公開用)
信之 岩永
 

More from 信之 岩永 (13)

YouTube ライブ配信するようになった話
YouTube ライブ配信するようになった話YouTube ライブ配信するようになった話
YouTube ライブ配信するようになった話
 
C# 9.0 / .NET 5.0
C# 9.0 / .NET 5.0C# 9.0 / .NET 5.0
C# 9.0 / .NET 5.0
 
C# コンパイラーの書き換え作業の話
C# コンパイラーの書き換え作業の話C# コンパイラーの書き換え作業の話
C# コンパイラーの書き換え作業の話
 
Unicode文字列処理
Unicode文字列処理Unicode文字列処理
Unicode文字列処理
 
C# 8.0 null許容参照型
C# 8.0 null許容参照型C# 8.0 null許容参照型
C# 8.0 null許容参照型
 
C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)
 
async/await のしくみ
async/await のしくみasync/await のしくみ
async/await のしくみ
 
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
 
Coding Interview
Coding InterviewCoding Interview
Coding Interview
 
非同期処理の基礎
非同期処理の基礎非同期処理の基礎
非同期処理の基礎
 
C#とILとネイティブと
C#とILとネイティブとC#とILとネイティブと
C#とILとネイティブと
 
Anders Hejlsberg Q & A
Anders Hejlsberg Q & AAnders Hejlsberg Q & A
Anders Hejlsberg Q & A
 
C#マスコット(公開用)
C#マスコット(公開用)C#マスコット(公開用)
C#マスコット(公開用)
 

Recently uploaded

Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit IntroductionMatsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo Lab
 
Kyndryl Developer Services のご紹介 2024年7月
Kyndryl Developer Services のご紹介  2024年7月Kyndryl Developer Services のご紹介  2024年7月
Kyndryl Developer Services のご紹介 2024年7月
Takayuki Nakayama
 
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツールMOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
TsuyoshiSaito7
 
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
TsuyoshiSaito7
 
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
shogotaguchi
 
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit IntroductionMatsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo Lab
 
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
Takuya Minagawa
 
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
Hironori Washizaki
 
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
Sony - Neural Network Libraries
 
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
iPride Co., Ltd.
 

Recently uploaded (10)

Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit IntroductionMatsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit Introduction
 
Kyndryl Developer Services のご紹介 2024年7月
Kyndryl Developer Services のご紹介  2024年7月Kyndryl Developer Services のご紹介  2024年7月
Kyndryl Developer Services のご紹介 2024年7月
 
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツールMOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
 
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
 
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
 
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit IntroductionMatsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit Introduction
 
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
 
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
 
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
 
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
 

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

  • 2. 本日のテーマ Windows 10 & .NET 2015を見据えて 今すぐに対応できること .NET 2015までに準備すべきこと おすすめの開発指針
  • 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を使う側も参考にすべき指針に
  • 5. キーワード “One .NET” Open Every developers Cloud
  • 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」とかやめて
  • 11. 統制 統制取りたいから新機能使わせたくないって? Privateな部分にうるさく言ってもしょうがない C# 6.0が影響するのはprivateなところばかり int X(int x) { return x * x; } メソッドの外から見えてる情報 はここだけ(変わってない) ここがレビューしにくいなら、何か別の問題あり  メソッド1個1個が大きすぎるとか  変数名がちゃんとついてないとか int X(int x) => x * x;
  • 13. “One .NET” 「縦割り」の改善 1つのエコシステム
  • 14. “One” 今年に入ってから、“One”(1つになろう)を標語にしてる “One Microsoft”  縦割り組織の改善  PC向けOSとモバイル向けOSで社内で争ってる場合じゃない  1つのOSコアに  1つの開発モデルに  1つのストアに .NETも“One .NET”
  • 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を利用する側として覚えておくといいのは ターゲット指定の改善 ライブラリ参照管理の改善 パッケージ単位のコード解析・補完
  • 20. ターゲット指定(旧): Profile選択ベース Portable Class Library: ターゲットを自分で選ぶ 共通部分 共通部分 これだけ使える ターゲットを増やすと 使える部分が減る
  • 21. ターゲット指定(新): 依存関係ベース パッケージ管理: 何に依存しているかでターゲットが決まる System.Runtime System.Collections.Generic System.Linq System.Net.Http System.Threading.Tasks Microsoft.Win32.Registry My App 1 My App 2 どこでもは使えなさそうな ものを参照すると… ターゲットに制限がかかる ターゲット指定は1st パーティ製ライブラリだけがやればよくなるはず
  • 22. ライブラリ参照(旧): .csprojプロジェクト形式 参照管理の仕組みがバラバラ BCL参照プロジェクト参照 .csproj内NuGetパッケージ参照 <Reference/>タグ .csproj内 <ProjectReference/> タグ packages.config + .csproj 内 <Reference/>タグ
  • 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解析を付ける 常に出る
  • 26. パッケージ単位のコード解析・補完 NuGet配布の例 自作のコード解析 自作のコード解析 が参照されてる コード解析が結果 (警告+ 書き替え)
  • 27. まとめ 全部入りインストーラー→ 個別パッケージ配布に 制御可能な形で、素早く提供 「パッケージ化」を意識した開発を
  • 29. .NETのオープンソース化 .NET全体をオープンソース化※ .NET Home : 各プロジェクトへのリンクとドキュメント .NET Core 以前からオープンだったもの  .NET Compiler Platform  ASP.NET  Entity Framework コミュニティプロジェクトへのリンクも  Mono Project  JSON.NET  … ※ といってもまだ途中。随時公開中
  • 30. オープンソース化の理由 クロスプラットフォームを維持可能な形で実現 コミュニティの活性化 新しい顧客の取り込み 既存顧客にとってもコミュニティが広がることはメリット 「Linuxで動かせるなら.NETをもっと活かせる」という要望は多い
  • 31. もちろんビジネス構造の変化もあって Windowsの会社→ Azureの会社 Azureのデータセンターを使っていただけるなら、その上のOSは WindowsでもLinuxでも パッケージ売り→ サービス売り Offide 365, Share Point, Dynamicsなどや、Azure上の各種サービスを使って いただけるなら、クライアントはiOSでもAndroidでも Visual Studio Online VS Onlineを使っていただけるなら、クライアントはEclipseでもSublimeで も
  • 32. 日本の業務系でも: 大手にとっても 社内フレームワークが足かせになってはいないか 同じような機能ならオープンなものに勝てない 「オープンだから使ったことある」って人の調達と、1から社内フレー ムワークを覚えてもらうのと、どっちがコスト低いか ググって出てこないものを使えない人 自社で作ったものもOpenな方が外注調達コスト下がってトータルで見 てお得になるかも
  • 33. 日本の業務系でも: 開発者個人にとっても 自分自身の身元保証 開発者求人とか、とりあえず「コード見せろ」 中小だと法人でも同様、身元保証 聞いたこともないような会社、中身見えなくて誰が応募するのか
  • 34. 業務系でも現実的なレベルになってきた Control 頻繁に更新されると動作保証ができない → バージョン管理で「変えない」こともできる Governance 誰がコードの責任を持つの? → 統制自体はマイクロソフト、.NETチームが責任持ってやってる Discoverability 身元のはっきりしないコードは使えない → どこの製品かまで含めて検索できる こういうソースコード管理、 パッケージ管理、開発工程管理 の仕組みがだいぶ充実してきた
  • 35. まとめ オープンソース化 信用の獲得 コミュニティの活性化 いろいろあったオープン化の課題は技術で解決されつつある オープン化前提で成り立つビジネスモデルに移行
  • 36. Every developers Every applications .NETをすべての開発者に
  • 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クラス利用
  • 48. まとめ 今はターゲットを広げる時期 レイヤー化、モジュール化、選べる大切さ パーツごとに差し替え可能な構成 変えたいときに、変えたい場所だけ変える
  • 50. Connect()にて Connect()での発表のうち、結構な量がVisual Studio Onlineがらみ Release Management Service Application Insights Sneak Peak Web based editing  Build service  Code search
  • 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サービス
  • 53. まとめ 自分達のインフラもクラウド化 医者の不摂生になっていないか すべては一社で完結させない 自社の得意のところは自社で そうでないところは外部と連携 Gitは避けて通れないかも Git間の履歴移植は楽らしいので、一度以降してしまえば次は楽かも
  • 54. 全体まとめ “One .NET” パッケージ化、制御可能な形で個別に素早く提供 Open 信用の獲得、コミュニティの形成 Every developers 広いターゲット、変えたいときに変えたいモジュールだけ変える Cloud 自社の得意なところは自社で、そうでないところは外部と連携

Editor's Notes

  1. 「元々打診を受けているテーマとしては」…なのだけども…
  2. 業務系の人に対してこれだけは最初に言わないといけないけども、ほんと、変えたくないなら変えなくていい。不連続のない開発体験。 「だいたい」ってのは、例えば、「.NET Native相手だと極端なReflectionコードは動かないことがまれにある」とか「Win32呼び出しとかしてると.NETの範疇外だしどこでもは動かないよ」とか、そういうレベル。
  3. 「元々打診を受けているテーマとしては」…なのだけども… 「指針」の話が中心になるかなぁと
  4. そんな最先端な話題でもなくて。 ツールとかプラクティス化が充実してきて、ちょっと前だったら小規模にしかできなかったことが、大規模にできるようになってきた。 こなれてきた。何せ、もはや、GitHubすら設立から6年とか経ってる(2008年設立)。
  5. この辺り、近々サンプルをgithubに上げると思う。 厳密には、string interpolationのカルチャー指定可能なバージョンの文法が4.6以降専用になると思う(System.Runtime.CompilerServices.FormattedString依存)。 あと、Await in catch/finallyは.NET 4 + Bcl.Async (拡張ライブラリ)でも動く。
  6. どっちでもいい。性能が変わらない限り、書いてる本人の好みで書かせて上げて。 で、C# 6.0の各種新文法はほんと性能も変わらないものばっかり。 もちろん、「知らないだけの人に教えてあげる」スタンスはいいんだけど。知ってて使ってない人に強制しても仕方ない。
  7. Client Profileがある程度。Full .NET Frameworkと比べると完全なサブセット。
  8. いつまでたっても古いバージョンから抜けれない理由もこれ。 新機能使いってだけで、バージョンは上げれない。業務だと、バージョン上げると全行程テストし直しとかで大変なんでしょ。
  9. これまでも、この方向に向かう傾向はあった MS公式提供品もオープンソース開発、個別NuGet配布してたり(System.Collections.Immutable, System.Reflection.Metadata, System.Numerics.Vectors, System.Reactive, System.Net.Http) MS外のライブラリを推したり(Json.NET)
  10. 具体的な手順は別途たぶんブログ化する。 kpm build でライブラリ .kproj を .nupkg 化できる NuGet参照をプロジェクト参照に切り替えるのは、global.jsonのパス指定書き替える or コピペでsrcフォルダー以下にソースコード持ってくるだけ
  11. 今年一番のニュースかもね 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
  12. 長期的に見てその方がもうかる算段なしでオープンソース化とかやらない。 といっても、日本だとOEM売りが強すぎてサブスクリプション型の収益への移行遅れがちみたいだけども。
  13. ここ数年言われ続けてることだけども。
  14. 一時期、HTML5全振りな感じだったけども、今また結構.NETが面白い時期になってきた。 まあいったん、非Windows環境にかなり注力するフェーズになるとは思うけど、Windowsを捨てるのかみたいなことにはならないと思う。
  15. これも、ダメだったから戻ってきたんじゃなくて、大きく振らなきゃいけなかった過渡期を過ぎた。「両方」をやれる時期に来た。 ちなみに、.NET 2015世代には、WPFのアップデートもある。
  16. 仕事用のソリューション: 社外の人との協業。外注先がMacだった。Windows機買ってもらう前にtryしてみたとか。 C# 6.0: コンパイラー担当してる人が結構仕事早いみたい
  17. libuv: Node.jsが使ってるクロスプラットフォームなWeb Serverライブラリ
  18. HTTPである必要すらない: ゲームとかのインタラクティブな通信で、「最初とりあえずHTTP long pollingでさらっと作っちゃって、パフォーマンス的に厳しそうなら自前でTCPで通信層書こう」とかもできる ミドルウェア挟むのも楽: ルーティングの分岐とかも楽。新旧フレームワーク混在で、あるフォルダー以下は新フレームワークで処理、みたいなことも書くの楽。段階移行とかもしやすいはず。
  19. 依存を減らす技術: データアクセス層技術で poco (Javaでいう pojo) が受けるのもそういう事情。Plain = 何にも依存してない。 幅広いプラットフォーム: 例えばの話、Webゲーからスマホゲーへの時代の変化についていけずに大変なことになってる会社もあるわけで。差し替えで別プラットフォームに移行できるってので、レイヤー化・モジュール化された構成大事 業務系のWebだって、「あの技術もう古臭いから死んでほしい…」とかぼやきながら「枯れた技術」を使い続けるわけで。
  20. まあまだまだ「理想は」だと思うけども。 着実に進歩はしていってると思う。
  21. 2枚前のスライドで見ての通り、OWINのFuncの戻り値がTask。OWINでも、戻り値がTaskってのがポイント高くて。
  22. http://blogs.msdn.com/b/bharry/archive/2014/11/12/news-from-connect.aspx オープンソースに紛れ気味だけども、Connect()での発表、結構な分量がVSOがらみ。
  23. TracとかJenkins、Gitとか使った開発管理サービスを提供してるところ結構あるし。「CIサービス」とかで検索すると出てくるサービス増えた。
  24. あと、サービス間連携とか。VSO自体API公開してて、他のサービスが参照できる