++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

Archive for the ‘.NET’ Category

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

leave a comment »

第7回業開中心会議で登壇してきました。

今から始める、Windows 10&新.NETへの移行戦略 from 信之 岩永

変わらない

聞いてた方からの感想で「『変わらなくていい』なんですね(笑)」などというお言葉もいただきまして。

まあ、僕個人の意見は元々、「使いたくないやつが使う必要はない。」「LINQもvarも、使う・使わないとかで論争すること自体どうでもいい。」「でも、使いたいやつに使わせないような統制取るやつは滅びろ。」ですからね。もちろん、コードレビューなんかで「LINQ使うとこれだけシンプルになるよ」→「そっちの方がいいですね」ってような流れはあるけども、強制するものではないと思う(11ページで書いているように、privateな部分のコードはうるさく言ってもしょうがない。LINQやvarはそのprivateな部分の機能)。

選べる自由が大事。選ばせないやつは本気で滅びろ。

変えれない

開発者の声としてよく聞くのは「変えたいんですけどもなかなか大変で」ってやつです。みんなほんとは新しいもの使いたい。「あのフレームワークいいから早く滅びろ」とか呪いの言葉を吐きながら、5~10年前のアプリを保守してたりするじゃないですか。

変えたいけども変えれない理由は当然、コストで、じゃあそのコストをどうやって下げていこうってのが最近のトレンドかなぁと。

今日の講演、ishisakaさんに「なんか犠牲的アーキテクチャの話になっている感じ」なんて言われましたけど、まさにそれだと思うんですよね。僕が犠牲的アーキテクチャ(原文和訳InfoQ記事)の話を見た時に思ったのは、「.NET Coreはこれを支援できるアーキテクチャだ」でした。もちろんこれは、最近のソフトウェア開発トレンドに名前が付いただけの話で、マイクロソフト(のAzure/ASP.NETチーム)はちゃんとトレンドに乗れてるってだけの話ではあるんですが。新しい概念に名前が付くってのも大事で、その大事なタイミングで今回の登壇できたのは割とよかったのかなと思ったり。

補足記事(を書きたい)

今回の話、3点ほど補足記事を書きたいなぁと思っています。

1つ目: .NET 2.0でC# 6.0

1つ目は資料の10ページ目の内容「.NET 2.0でもC# 6.0使えます」。

まあ、実は今もう、GitHub上に、どのC#言語機能がどのバージョンの.NETで動くかに関するサンプルコードがあったりするんですけども(6.0のサンプルが未完。もうちょっとで完成)。これをベースにした話。

2つ目: NuGetパッケージとプロジェクトの区別がなくなる

2つ目は24ページ目の内容「区別がなくなることで」。

この開発フローの具体的な、プロジェクトからNuGetパッケージを作ったり、NuGet参照していたものをプロジェクト参照に差し替えたりの話。

3つ目: Xamarin Studio

3つ目は42ページ目の内容「補足: Xamarin Studio」。

これ、外注先の会社さんが、うちの作ったフレームワーク乗ることになったはいいけども、そちらの開発環境がMacしかなく、仮想マシン立てるとかWindows機買ってもらうよりも前に、まずXamarin Studioでのビルドを試みてみたという実話。半日くらいは試行錯誤があったんですけども、最終的には何の問題もなく、Mac上でビルド通ったそうです。その、半日程度の試行錯誤の話。

広告

Written by ufcpp

2014年11月29日 at 23:19

カテゴリー: .NET

.NET for every developers, every devices

with 2 comments

Connect(); Microsoft Visual Studio vNext & Azureっていうイベントをオンライン配信しているわけですが。.NET界隈的にはかなり久々なレベルのでかい発表がありました。

MSDNブログでも、各チームがいろんな記事を公開。

テーマ的には、every developers, every devices。

無料版Visual Studio

今までも、Visual StudioにはExpressエディションっていう無料版があったわけですが、

  • デスクトップ開発用、Web開発用、…というように、ターゲットごとに分かれてた
  • 拡張機能を入れれなかった

などの制限があって、ご時世的につらいものがありました。何がつらいって、

  • Devices and Services (Web + 携帯端末)なご時世にターゲットを分けられても困る
  • XamarinやUnityゲーム エンジンなどの勢いがあるご時世に、拡張を入れれないとか困る

という感じ。

なので、このたび出た新しいエディションが、Communityエディション。

上記のようなターゲット分割・拡張面での制限がなくなった版(有償エディションでいうとProfessional相当の機能っぽい)。使える条件は以下の通り。

  • PC 250台以下・年商100万ドル以下(non-enterprise)の会社で、5ユーザー分まで
  • 非商用利用、教育、研究、オープンソースへの貢献で無制限

同時に、Xamarin との提携で、Xamarin StarterでもVisual Studio拡張が使えるようになったらしくて、それと組み合わせれば、上記条件下だとVisual Studioを使ったAndroid/iOS開発も無償でできるみたいです。

.NETのオープンソース化

今までも、だいぶオープン化していたわけですが

ついに.NET自体もオープンソースになりました。

まだ、オープンになっている部分はそんなに多くないんですが、.NET Coreのランタイム自体のオープンかも含めて、これから随時足していく(作業中)だそうです。Windows以外のプラットフォーム(MacとかLinux)でのビルド・実行に関しても作業中。

.NET Coreなので、要は、Win32 API依存なところは一切なしな部分。プレス リリースなんかでは、「.NETのserver stackをオープン化」とか説明されています。要は、Azure方面が頑張った結果のオープン化。

.NET Core上で使えるクラス ライブラリは、現状のストア アプリ向け.NETがベースのはず。で、.NET Nativeもこの.NET Coreがベース(なので、server stackとは言いつつ、クライアント向けも今後はこの.NET Coreを基礎として作られるはず)。

.NET 2015

最近もう、「一斉にバージョン5としてリリースします!」みたいな時代じゃなくて、バージョン番号がパーツごとにばらばらになっています。

  • .NET
    • .NET Framework 4.6: 現状のデスクトップ.NETの新バージョン
    • .NET Core 5: ASP.NET vNext (cloud-optimizedモード)とか.NET Nativeが使ってるモジュラー性を高めたバージョンの.NET
  • .NET Compiler Platform (旧codename “Roslyn”): できたてほやほや。当然バージョン1
    • C# 6.0
    • VB 14
  • RyuJIT: 新しいJITコンパイラー
  • ASP.NET 4.6
  • Visual Studio 2015

この辺りを総称して、「.NET 2015」と呼んでいくみたい。

Every developers, every devices

要するに、誰でも、何の上で動くアプリでも、すべての人に.NETを。

Written by ufcpp

2014年11月13日 at 02:31

カテゴリー: .NET

.NET vNext

leave a comment »

先月の夏サミのコミュニティオープンジャムと、こないだのこみゅぷらすで.NET vNextの話ちょこっとしてきた。

4月の//build/と5月のTechEd NAの内容がベースなので、旬は外し気味。

.NET vNext from 信之 岩永

Written by ufcpp

2014年8月28日 at 01:14

カテゴリー: .NET

C#/.NET Framework がやっていること 第二版

leave a comment »

CLR/H in Tokyo 第3回に登壇。

C#/.NETがやっていること 第二版 from 信之 岩永

OnDrive: http://1drv.ms/1yYjUNf

前に、Boost勉強会で話した内容の焼き直し。その時は180ページ近い資料を1時間(通常の3倍速)で話したわけですが、それを3時間かけてちゃんと話したいとか言っていたら、CLR/Hにお呼ばれしたもの。本当に3時間(というか、ちょっと時間オーバーしたんで3時間以上)話してきました。

時間があるのと求める前提知識をだいぶ緩くしたのとで、追記が結構ある。あと、5月の非同期勉強会の内容も少しマージしたのと、.NET vNextがらみの話題も足して、最終的には210ページ超。

Written by ufcpp

2014年6月29日 at 12:06

カテゴリー: .NET, C#

Visual Studio 2014 CTP

with one comment

Visual Studio 2014 CTPのプレビュー版出てた。

2013とside-by-sideで入らないとのことでちょっとさすがに触れずにいたものの、1日遅れでAzure VM Galleryに並ぶようになったんでそちらを使ってVM上で試すことに。

MSDNブログ情報

MSの各製品チームとかから一斉に情報が。

side-by-side不可

もちろん最終的には他のバージョンのVisual Studioと共存できるようにするつもりだけども、今回は不具合が残っててできないということみたい。そのうち治るはず。

今は、そもそも別のバージョンが入っていたらインストーラーが警告出して止まる。回避方法もあるものの、VS 2014 CTPをインストールしてアンインストールすると、VS 2013とかに悪影響を残すとか。

C# 6.0 experimental

//build/ の前後で出た状態のRoslyn CTP以降、null伝搬 . 演算子が実装されたみたいですね。

null伝搬

以下のようなもの。要するに、p == null ? null : p.Name の短縮形。

using System;

 

class Program

{

        static void Main(string[] args)

        {

                X(null);

                X(new Point(1, 2, null));

                X(new Point(1, 2, "aaa"));

        }

 

        static int? X(Point p)

        {

                try

                {

                        var len = p?.Name.Length;

                        Console.WriteLine("no error " + len);

                        return len;

                }

                catch

                {

                        Console.WriteLine("error");

                        return null;

                }

        }

}

 

class Point(int x, int y, string name)

{

        public int X { get; } = x;

        public int Y { get; } = y;

        public string Name { get; } = name;

}

 

実行結果は以下の通り。

image

ちなみに、VS 2014 CTPを使ってみる他、Roslynのソースコードをgithubから最新版とってきてビルドすればVS 2013でも試せるはず。

null伝搬のショートサーキット

前にフォーラムをのぞいてみたところ、null伝搬演算子を左結合にするか右結合(ショートサーキット評価)にするか悩んでたはずですけども、上記の結果を見る限り、とりあえず現状では右結合(ショートサーキット評価)で実装されてるみたいですね。

右か左かっていうのは以下のような話。

  左結合 右結合(ショートサーキットあり)
a?.b?.c の解釈順 (a?.b)?.c a?.(b?.c)
a?.b?.c と同じ結果になるコード var b = a == null ? null : a.b;
var c = b == null ? null : b.c;
return c;
if (a == null) return null;
var b = a.b;
if (b == null) return null;
var c = b.c;
return c;
a?.b.c で、aがnullだったら (a?.b) の結果がnullなので、.c の時点でぬるぽ例外。 a == null 判定の時点でもう .c を見ないので、例外は出ずに null が返る。
判定順をあえて変えたい時は a?.(b?.c) という式がC#としては不自然で、1つの式では書けない (a?.b)?.c
採用の根拠 演算子はほとんどが左結合なので自然といえば自然。 条件演算子 ? : や null 結合演算子 ?? はショートサーキット評価なので、それと合わせるならこちらの方が自然。

 

C# 6.0 (試験実装)を使いたいなら

この機能、まだ正式にC# 6.0になったわけではないので、ビルド オプションで「C# 6.0」を選んでも使えません。というか、Visual StudioのUI上から設定できる場所はなくて、 .csproj を直接メモ帳とかで編集する必要があります。

C#チーム ブログで書かれてますが、<LangVersion>タグの中身を experimental に変えます。

cs-experimental

Written by ufcpp

2014年6月6日 at 22:07

カテゴリー: .NET

.NET vNext

leave a comment »

ようやくTechEd NA 2014関連の話を見れているところ。

TechEdなのでやっぱり話題の中心はAzureとかASP.NETなわけですが、その辺りはまあ、

やっぱ、しばやん雑記とかブチザッキですわね。

で、自分が気になるのは.NET vNextの方。

.NET vNext

まず、.NET Frameworkの次期バージョンといえば、先月の//build/とかで出てた内容:

そして今回、ASP.NET vNextに伴って出てきた話題:

  • ASP.NET vNext: the future of .NET on the Server
    • (.NET自体に関係するところだけまとめると)
    • side-by-sideな(同一サーバー内で、アプリごとに別バージョンを使える).NET Framework実行
    • NuGetパッケージを使った自動依存解決(BCLすらNuGet配布)
    • Roslynを使った動的な実行(ソースコードを置いておくだけでOK。コードを書き換えて、ブラウザーの更新をするだけで変更が反映される)
    • 適切な粒度でのフレームワークの分割

いろんな実行方法

.NET vNextには、大まかにいうと3系統の成果があります。

  • (これまで通りの)JIT
    • デスクトップ環境だとこれまで通りで大丈夫
    • これまで通りの部分も引き続き投資されていて、性能改善などがある
  • .NET Native
    • モバイル端末向け
    • 事前に(サーバー上で)アプリをネイティブ化してから、モバイル端末に配布
  • .NET on the Server
    • サーバー、特にクラウド向け
    • アプリ単位でランタイムを切り替えれる
    • サーバー上にC#(など)のソースコードを配置するだけでWebアプリが稼働

.NETが世に出た当時と比べて、いろんな環境が出てきたので、それに合わせて最適な実行方法も多様化しています。.NET vNextでは、その多様性に対応していこうということみたいです。

アプリの配布方法

  • JIT
    • これまで通り、IL(中間言語)での配布
    • 参照しているライブラリの依存解決とかもJIT時に行う
  • .NET Native
    • Windows Storeのサーバー上でクラウド コンパイル(compile in the cloud)
    • 参照しているライブラリの依存解決とかはすべてサーバー上で行う
    • モバイル端末にはネイティブ化した状態で配布
  • .NET on the Server
    • C#などの高級言語で書かれたソースコードをサーバーにアップロードするだけ(Roslynを使った動的な実行)
    • ソースコードを書き替えるだけでアプリの挙動が更新される

.NETランタイム

  • JIT
    • OSに.NET Frameworkがインストールされている必要あり
    • Windows 7/8/8.1にはそれぞれ.NET 4/4.5/4.5.1が標準で入ってるものの…
      • Windows前提
      • 新機能の利用にはアップデートが必要
  • .NET Native
    • モバイル端末側に.NET Frameworkがインストールされていなくてもいい
    • クラウド コンパイル時に、(.NETの標準ライブラリ中の機能も含めて)必要なものはすべて静的にリンクして、アプリに同梱
  • .NET on the Server
    • サーバーOS自体に.NET Frameworkがインストールされていなくてもいい
    • バージョン マネージャーを介して必要なバージョンのランタイムをダウンロードしてくる
      • アプリ単位で別バージョンを利用可能
    • 依存しているライブラリも、すべてバージョン マネージャーが管理・必要な分をダウンロード

実行性能

  • JIT
    • 次世代のJIT(コードネーム RyuJIT)でいろいろ性能改善
      • 起動時間短縮
      • SIMD命令対応
  • .NET Native
    • クラウド コンパイルなのでコンパイル時にしっかりと最適化(C++コンパイラーと最適化コードを共有)
  • .NET on the Server
    • 実行自体はJITだと思うので、RyuJITの成果次第

適切な粒度に分割

あと、.NET vNextとかASP.NET vNextとかでは、一枚岩なシステムだった.NETを適切な粒度に分割しているのも大きなポイント。

そういう動き自体は.NET 4.5の頃からあったんですが、引き続き.NETの整理が進みそうです。この辺りは、

  • .NET 4.5の時の成果
    • BCLのアセンブリ整理
    • Auto-Ngen
  • NuGetパッケージ
    • myget.org
  • 今回出た話題
    • コードネーム “Project K”とか“K Runtime”なんて呼ばれてるもの

なんかも絡んでくるので一度整理してブログ化してみたい(ものの、いつやるか)。

Written by ufcpp

2014年5月20日 at 02:00

カテゴリー: .NET

非同期処理の基礎知識

leave a comment »

そういえば先週の非同期勉強会の話題、ブログに書いてなかった。

自分の資料:

非同期処理の基礎 from 信之 岩永
OneDriveにもアップロード
 
「CPUとかOSレベルな話から」という意味で「基礎知識」。べたに、「『こう書け』とだけ言われても、中の仕組みを知らないと納得いかないですよね」という話。
CPUの構造がどうとかいう話だけとか、OSスレッドの話だけとか、I/Oの話だけとか、個別にはちらほら見るものの、非同期処理って観点からこの辺りを通して説明してる資料って少ないなぁと常々思っていたので。「こう書いた方がいいよ」事例サンプルはC#ですけども、他の言語、他のOSでも通じる話だと思います。
ぶっちゃけ、C# 5.0のasync/awaitを使うとほとんど内部で解決してくれるような話ではあります。ただ、もちろん、「async/await使えば同期っぽく書けるといっても、非同期特有のはまりどころにははまるでしょ?」といわれるとその通り。でも、じゃあ、非同期処理を避けれるかというといまどき無理な話で、「非同期処理が避けようないんだったら自分で書くよりはasync/awaitに頼る方がマシ」という感じ。ということで、async/awaitのあたりの話でなく、こういう基礎部分の話をしないといけないなぁと思って作ったものです。

Written by ufcpp

2014年5月20日 at 01:48

カテゴリー: .NET

Tagged with