++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

ソースコード共有と#if

leave a comment »

いわゆるifdefコードの難しさ。

昨日、クロスプラットフォームな開発をしてる人から、「universal Windows apps の共有プロジェクトって、#if を正しく認識してるの？リネームとかのリファクタリング的な意味で」という疑問をいただいたので試してみた結果。

image

ダメでした。ええ、ダメでした(とりあえずConnectに登録済み)。

クロスプラットフォーム開発してて、どうしても#if/#elseするしかない場面ってごろごろあって、「動く」という意味では全然問題ないものの、こういうリファクタリングでいつも困るそうで。手元の環境で #if の対象になってない部分のコードで、どうしても修正ミスが残って、後から問題が発覚するという。

Written by ufcpp

2014年4月12日 at 19:15

カテゴリー: .NET

RyuJIT SIMD対応

leave a comment »

なんか週明けてからもブログが。

//build/で出てた、RyuJIT CTP3のSIMD対応の話の詳細。あと、SIMD命令ってのが何なのかっていうそもそもの説明付き。

Written by ufcpp

2014年4月8日 at 23:17

カテゴリー: .NET

Universal Windows Apps

leave a comment »

ここ数日ブログに書いた話はCTP (Community Technology Preview: 要はアルファ版。リリース版は結構将来の話)なものばかりでしたが。

RC (Release Candidate: リリース間近。重大なバグフィックス除けばほぼそのままリリース)の話も1つ。

Visual Studio 2013 Update 2 RCを入れると、Windows Phone 8.1アプリの開発ができるようになります。

Windows Phone 8.1アプリは、以下で説明していくような意味でWindows 8.1アプリと“同一アプリ”として開発できて、この仕組みを「ユニバーサル アプリ」(universal Windows apps)って呼びます。

ユニバーサル アプリ

Visual Studio上で、(ユニバーサル アプリ)と付いたプロジェクト テンプレートを使って新規プロジェクトを作るか、もしくは、Windows 8.1アプリに対して「Windows Phone 8.1の追加」、Windows Phone 8.1アプリに対して「Windows 8.1の追加」という操作をすると、プロジェクトが以下のような状態になります。

この状態のアプリを「ユニバーサル アプリ」と言うみたい。

ちゃんと、JavaScript版もC++/CX版もあります。

image

image

開発者視点で言うとポイントが4つくらい。

  1. WinRTの互換性向上、Windows 8.1とWindows Phone 8.1でほぼ共通のAPI化
  2. 共有プロジェクト(.shproj)が作れるようになった
  3. PCLの利便性が向上
  4. Win8.1/WinPhone8.1アプリは、Windowsストア上で同一アプリとして扱われる

ほぼ共通のAPI

ユニバーサル アプリといいつつ、実際のところ、胆となるのはWindows 8.1アプリとWindows Phone 8.1アプリのAPI統合みたい。要するに、共通して使える.NET標準APIとWinRT APIが実用レベルに増えた。

やろうと思えばXAMLとかも完全コピペで（後述する共有プロジェクト使えば単一ソースコードで）作れそうな程度には共通っぽい。

個別にXAMLを書くモチベーションは、画面サイズの違いによる再デザインくらい。「Phone版は画面はみ出てもいいや」とか「ViewBox使って単に拡大して画面サイズ合わせればいいや」とかくらいの適当なので良ければ、ほんとうに単一ソースコードで開発できそう(それでストア審査通るかは別として)。

共有プロジェクト

新しいプロジェクト タイプとして、共有プロジェクトができたみたい。上記のスクリーンショットで言うところの、HubApp1.Sharedプロジェクト。

このプロジェクト中に追加したファイルは、Windows 8.1用プロジェクト(HubApp1.Windows)とWindows Phone 8.1用プロジェクト(HubApp1.WindowsPhone)の両方に含まれている扱いを受けるようです。PCL (Portable Class Library)と違って、ライブラリDLLができるとかではなく、ソースコードやリソースがプロジェクト内に含まれるものとしてそれぞれをビルドします。

各ファイルを「リンクとして追加」するのとかPCLとかと比べて何が嬉しいかというと、以下のような感じ。

  • 画像リソースとかのアセットも含めて共有可能
  • XAMLとかリソースのパスが狂って参照できなくなる問題もない
  • #ifdefによる条件コンパイルなども利用可能
  • 管理が楽。個別のプロジェクト側と共有プロジェクト側の間で、D&Dでファイルを移すだけで 個別⇔共有 の切り替え可能

この共有プロジェクトの仕組みを普通に使えるのは、現状ではユニバーサル アプリのみみたい。ただ、ユニバーサル アプリの.csprojファイルの中身を参考にして、自分で.csprojファイルを書き換えれば他のプロジェクトでもファイル共有くらいはできそう(IntelliSenseとかが正しく動く保証がないけども)。

PCLの利便性向上

  • Visual Studio 2013 Express for Windows (無償版、Windowsストア アプリ開発用)からPCLプロジェクトを参照できるように
  • クラス ライブラリ(単一環境用)プロジェクトとPCLプロジェクトを一本化
    • ただし、現状Windowsストア用のみ
      • 「.NET Framework 4.5」のみなPCLは作れないみたい
    • つまり、PCLプロジェクトのターゲットを「Windows 8.1」のみ/「Windows Phone 8.1」のみに設定可能に
      • 代わりに、ターゲットが「Windows 8.1」のみ/「Windows Phone 8.1」のみなプロジェクト テンプレートは廃止
  • PCLプロジェクト内でWinRTを参照可能に
    • プロジェクト テンプレートで「クラス ライブラリ(ユニバーサル アプリ用ポータブル)」を選ぶと、WinRTが参照されてる状態のPCLができる
    • WinRT XAMLコントロールなんかもPCLとして作れるように

現状ではやたらと「Windowsストア用のみ」状態ですけども、「計画としては対応プラットフォームを広げていきたい」とのことらしいので今後に期待。

Windowsストア上では1つのアプリ扱い

上記スクリーンショットの通り、内部的には「2つのプロジェクトでソースコード共有」で、「パッケージ(appx)も2つ作られる」わけですが、これをWindowsストアに上げる際には1つのアプリとして扱ってもらえるそうです。

「1つ」ってのは、以下のような意味合い。

  • 同じアプリIDが割り当てられる
  • 課金の口が共通。有料アプリなら、片方で買えばもう片方でも使える
  • ローミング(OneDrive経由のデータ同期)が共通
  • プッシュ通知(Windows Notification Service)が共通

※

みんな、「※」と書いただけで「※ただし日本は除く」って意味にとってくれるのはどういうことなの。

Visual Studio 2013 Update 2 RCをインストールすると、Windows Phone 8.1のエミュレーターもついてくるわけですが。エミュレーターでアプリが動いても、実機が世の中に出回ってないことにはねぇ…

とりあえず、de:codeを期待して待っていればいいんでしょうか…

ちなみに、Visual Studio 2013 Update 2 RC自体は日本語対応済みです。各種プロジェクト テンプレート・項目テンプレートもちゃんと日本語。

Written by ufcpp

2014年4月6日 at 20:53

カテゴリー: .NET, C#

« 古い記事