※1 … 書き方によっては4.6でないと動かなくなる ※2 … 拡張メソッドの制限そのまま。拡張メソッドを2.0で動かす方法はあるので、それを使えば2.0 ※3 … 同様に、await演算子の制限。4で動かすすべあり 動かし方、補足など 前節の表で、2.0で動くとなっているものは、要は、ライブラリ依存がなくて、単純にC#コンパイラーだけの仕事で実現できる機能です。 逆に、特定のバージョンに依存しているものは、そのバージョンで追加されたクラスに依存しています。 なのに、古いバージョンの.NET Frameworkでも「動かすすべがある」というのはどういうことかというと、あるクラスに依存するといっても厳密なチェックをしているわけではなく、同じ名前・同じ機能のクラスを自前で実装すれば動きます。なので、原理的に言うと、どの機能でも.NET Framework 2.0で動かせるんですが… C#機能ご

Connect(); Microsoft Visual Studio vNext & Azureっていうイベントをオンライン配信しているわけですが。.NET界隈的にはかなり久々なレベルのでかい発表がありました。 MSDNブログでも、各チームがいろんな記事を公開。 Somasegar’s: 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 ScottGu: Announcing Open Source of .NET Core Framework, .N

twitterで見かけた話題（1, 2）。ロンドンのイベントでMads（C#のプログラム マネージャー）がC#に追加するかもしれない（したいけど、まだ文法的に確定してない）機能について話したみたいですね。 The Future of C#（イベントのページ） Channel9の掲示板での話題、同 別エントリー 早期プレビュー C#ってこれまでのノリだと、コンパイラーとか仕様書までできた段階で情報を公開していたわけですけども、今回は「ご意見求む」なレベルでの情報公開。 MSDNブログとかChannel9でなくて、ヨーロッパ ローカルなイベントで初めて公にしたのも、ブログとかでまとめるような段階でない本当に早期プレビューなせいなのかも。 C# 言語チームの開発体制自体の変化を感じたり。 新文法（候補） で、（twitter越しで見れる）スライド中の情報から読み取れる文法について。 primar

How to call WinRT APIs from .NET desktop apps Windowsストア アプリでない、通常の（デスクトップ版の）.NETアプリからWinRT APIを呼び出す方法。 WinRT利用のために、.NET Framework自体に手が入っているので、.NET 4.5を使うなら、別にWindowsストア アプリでなくたってWinRT APIを呼べるわけですが。それのやり方、というか、Visual Studio上でいろいろ（[参照の追加]ダイアログにWinRTコンポーネントの追加ペインを出したり）やるためには、csprojファイルを1行手動で書き換えないといけないというお話。 一部簡単に日本語で説明しようかというのと、元がVBなので、C#でさらっと書いてみたものを出しておこうかと。 C#ソースコード一式 WinRT APIとは WinRTは、Windows

Xamarin 2.0 のアナウンスがあったわけですが。 Xamarin 2.0 の内容 単に、メジャー バージョンアップに合わせて、ブランド名を統一したという内容。今まで、Mono Touch、Mono for Android だったものが、Xamarin.iOS、Xamarin.Android に。 メジャー バージョンアップによって、Visual Studio 使って Windows 上で iOS 開発できるようになったりも。新 IDE の Xamarin Sudio は世界で一番の Android UI ビルダーだという自信もあるそうで。 クロス プラットフォーム クロス プラットフォームというと割と夢見がちな意見と、それを警戒する意見にたどりつきがち。 Xamarin 2.0 のニュースを見て、知り合いから「こういうツールって使い物になるの？」とのご意見も求められてしまったので、

C# 5.0のasync/awaitを使うと、多くの場面ではシングル スレッド的な動作になるし、多くの場面ではlock不要（結果的に、デッドロックが起こりようなくなる）になったりします。 ただし、「多くの場面で」。「必ず」ではないのがはまりどころ。いくつかの場面では、同時実行制御が必要です（普通にマルチスレッドの平行実行になるので、同時に同じデータにアクセスされる可能性を考慮しないとバグります）。 前提知識 いくつか、C# 5.0世代の非同期処理についての前提知識は、以下のスライド（先月末の.NETラボでの発表）を参考にしてください。 5~12ページ: async/awaitの書き方 17~22ページ: スレッドとそのコスト 24~26ページ: スレッド プール 29~32ページ: I/O完了待ちと非同期API 36~40ページ: UIスレッドとディスパッチャー 41~45ページ: 同期コ

下記の文章、「こういうテーマでufcpp.net内のC#ページを更新（今の【雑記】的にやるか、新しいフォルダー掘るかして）したい」というもの。 いつ手を付けるかは未定。実際のところしばらく無理。 表題、誇張ではなく、割と真実。 ソフトウェアに求められる品質水準は非常に高くなっていて、開発者に求められる知識は年々増えています。 単純にプログラミング言語の基礎を覚えるというだけではまるっきり不足で、そこから様々なパターンを覚えて初めて実用化に足る最低水準になります。 パターン。 こういう場面ではこう書くと解かりやすい こう書かないとこんな問題が 計算速度優先ならこう、省メモリならこう 等々、いわゆる先人の知恵。 歴史を積み重ね、普通に1からたどるにはあまりにも遠い道のりに至りました。 先人と同じ手順を経ていては、追いつくことで精一杯。その先の新しい世界を目指すことも叶いません。 楽をするひつよ

Roslynの更新が。（数日前にneueccさんがRoslynの話してたなーと思ったら、これが出たからか。） New Update of ‘Roslyn’ CTP Available いくつかAPIに破壊的変更有。C#/VB共に、対応文法増加。今回からVisual Studio 2012必須（2010未対応）。 以下、Roslynをインストールするとついてくる「Getting Started」ドキュメントの、変更に関する記述の和訳。 CTP2からの変更 CTP2（2012年6月版）から、以下のような変更あり。主要なものは以下のとおり。 Compiler APIs SyntaxTree.ParseCompilationUnitがなくなって、ParseTextとParseFileに SyntaxNode.GetTextとGetFullTextがなくなって、ToStringとToFullStri

ほんと、どうしてこうなったかなぁ。 Oralceの対Google訴訟、プログラミングの将来を危うくしている 二分された世界 JVM と .NET、もろに競合なわけですが。少しレイヤーが違うとか、棲み分けできるポイントがあるならともかく、ほんとに2個あってもしょうがない状態。競争があるのはいいと思うものの、どうせ競争するなら最低ラインの仕様そろった中で性能改善とかで競って欲しく。 でも、後発の .NET だけが悪いわけでもないのは今の DalvikVM の状況を見ての通り（Oracle になってひどくなったわけでもなく、Sun の時代も大概）。このままだと仕様が違う第3の仮想マシン（VM）ができてしまってもおかしくない状況… 個人的な意見として、「もしもの話」で、一番よかっただろう道筋は、2000年前後の訴訟がなくて、Microsoft Java VM が生きている状態。.NET が生まれる

24日・25日とWDDに行ってたわけですが。 講演者の皆様、UIスレッドとディスパッチャーの話で苦労されてた印象。この辺りの仕組み、どうなんだろうなーとか、少し書いておこうかと。 UIスレッドに紐付いたクラス まず前提。 UIスレッド まず、GUIがらみのクラスは、単一スレッドからしかアクセスできないように作ってあります。スレッド安全に作ろうとするとパフォーマンスが出ないので、いっそのこと、UIスレッド以外からアクセスがあったら例外を出して止まるように作ってあります。 この、GUIコンポーネントと紐付いているスレッドがUIスレッドです。 エンド ユーザーからの入力なんかを受け付けているのもこのUIスレッドで、UIスレッド上で時間がかかる処理をすると、UIがフリーズします。 なので、時間がかかる処理をするときは、一度別スレッドで処理して、結果をUIスレッドに戻すというフローが必要です。 WP

先週、「C#にもNull非許容な型が欲しい」という話をされたものの「うん、欲しいね」としか返せなかったり。要望は昔からあるけども、実際入れようと思うと結構大変。という話、説明しておいた方がいいんだろうなぁと思ったので、ブログにしてみることに。 先に結論の要旨だけ書くと、以下のような感じ。 C#だけで完結する問題じゃなく、.NETレベルで対応するのは今からだときつい Code Contracts使って契約プログラミングするのがいいよ 以下詳細。 公式の見解 Anders Hejlsberg も、「もしもの話」として、1からの再設計が許されるなら C#/.NET をどうしたいかという質問に対して「Null 許容性の見直し」を挙げています。 一時期、結構頻繁にそういっていたと思います。少し検索して出てきたのでいうと、以下の Q&A インタビューの、1:00:00 からのくだり。 今、値型に関して

研究者肌で、ほっとくとすぐに5年・10年先のビジョンを考え出すんだ 仕事は夢を与えないと。大人がつらいつらいって言ってたら、子供が大人になりたがらないよ！ だいぶ現実的。個人レベルじゃなくて、組織全体としての短期～中期の最適解を求めるよ 仕事は意地を通す。土日も勉強！ あっ、FとかAってのは例え話ですからね。2人だけでもないんで。CLAMP辺りで例えた方が良かったか。 他との兼ね合いっ！ 僕本体がC# Advent Calendarへの登録してませんが、これは別に、1人Advent Calendarの方とは無関係です。1人の方を思いついたのが29日で、C#の方はその前にだいたい埋まってましたし。Aさんの方と協議の上、最後にC#たんを混ぜときましたが、この時点では、WordPress.comのアカウントとることすら決めてませんでした。というか、CodeZineの方書くかという話もありました。

追記： 色々更新した 前々から気になってはいたんだけども。 MVVMパターンのViewModelで、INotifyPropertyChangedをいちいち実装すんのかったるい。かといって、AbstractなViewModelBaseは継承したくないでござるよ。 ちょっとイケてるINotifyPropertyChangedの実装 今の C# だと、手書きだけで INotifyPropertyChanged の実装をうまくやろうと頑張るのは厳しいと思うんですよね。コードスニペット使うのを前提に考えるのが一番いい妥協だと思います。 ということで、以下のようなものを作成。 ヘルパークラス（C#） とりあえず同じプロジェクトにぶち込むなりライブラリ化するなり コードスニペット マイドキュメントの下の、Visual Studio のフォルダー以下、Code SnippetsVisual C#My Co

先日インストールしたRoslyn、ちらほら見始めています。公式サンプル、ドキュメント、Walk-Throughや、フォーラム、twitter（ハッシュタグ #RoslynCTP）等々。 Codename “Roslyn”とは Roslynは、C#とVBのコンパイラーをManagedコードで書き直して、コンパイラー内部の中間的な情報に誰でもアクセスできるようにします。 今までは、文字列のC#ソース コードを与えて、バイナリの.NET Assemblyを出力する一枚板（monolithicな）ブラック ボックスでした。一方、Roslynでは構文パーサー、意味解析エンジン、ILコード生成部、スクリプト エンジンなどを公開していて、ソース コードの静的解析やリファクタリング ツールなどを作りやすくなります。 Roslynの最終目標 Roslynの説明でよく使われるのが以下の絵。 「BUILD 20

フォーラムに↓このようなものを投稿するなど。 アルファベット混じりのアプリが複数言語混在問題で審査に落ちる （立てたの自分じゃないけど、user voiceの方にも） App Hub登録審査に日本人、もしくは日本文化に精通している人を少なくとも一人は配置してほしい で、これに関して、ちょっと知っておいてもらいたい事柄をいくつか。 数字を伴うこと大事 日本と比べると米国自体がというのもありますけども、その中でも、マイクロソフトは数字を伴ったフィードバックを非常に重要視します。 よく問題になるのは、日本人は製品版が出てからバグを見つけて文句を言うとか、フォーラムが盛り上がらないから問題ないと思っていたとかそういうのです。 今まだ IS12T しか出てないし…とか、変な遠慮をしてちゃダメで、問題は早期に伝えないといけません。また、数字を伴うっていうのは、立ったトピックに対して「投票」とか「△」み

非同期だらけだった BUILD の後というのもあって、MSDN Blog も MSDN Magazine も非同期だらけですねぇ、ほんと。 というか、BUILD のセッション内容がそのまま記事になった感じ。 いくつかの記事に関して、概要をメモ書き程度に： Easier Asynchronous Programming with the New Visual Studio Async CTP http://msdn.microsoft.com/en-us/magazine/hh456401.aspx そもそも async が必要とされる理由に関して。応答性良くするために他にどういう手段が考えられて、その手段だと何が問題かを説明。 解1: スレッドたくさん作る 確かに応答性は改善 リソース無駄食い （ほとんどは待ち時間なのに）客の数だけウェイター雇い、オーダーごとに2名ずつコック雇うような無駄

@IT 向けに書いた記事が公開されました。 フリーズしないアプリケーションの作り方 これもまた、裏ではいろいろと思うところあり。 タイミングよかった いやー、題材が題材だけに、C# 5.0 とか .NET Framework 4.5、VS11 の正式版が出る頃に出そうかなーなどと思って書き貯めてあった文章だったり。 諸事情あって、実は意図せず今月完成させて出すことになって、今日の公開だったわけですが、意図せずいいタイミングになったなぁ。 BUILD での発表内容がもうほんと非同期処理だらけで。「WinRT では50ミリ秒以上かかる処理は非同期APIにします」とか、C# 5.0 の async/await 構文の再説明も多々入っていたり。 ついかっとなってやった。後悔なんてあるわけない。 まあ、非同期処理は一応、年々ホットな話題になってきているので、他にも記事はあるにはあります。 ただ、自分

まあ、ます先に、ダウンロード リンク一覧を Microsoft Visual Studio 11 Developer Preview (ISO) http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=415c1589-a7b1-4b25-93fa-11bb6f29a5be Microsoft Visual Studio 11 Developer Preview (Web インストーラー) http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=99a58e56-fcb2-4264-bce7-3311cf0d1806 Microsoft Visual Studio Team Foundation Server 11 Developer Preview

BUILD、まだ基調講演くらいしか見れていませんが、それだけでもなかなかに素敵。 そして、公開されて間もないWindows 8の開発者プレビュー、さっそく使ってみているわけですが。 開発者的に気になっていたのは、うわさのWinRT。 コードネームとかじゃなく、正式名称的にもこの名前でよかったわけですが、実物見るとなかなかに楽しそう。 Metroアプリ vs 既存デスクトップ 開発スタイル的には全く別系統でした。いわば、Silverlight と WPF みたいなもの。 Metro アプリ タブレット向け、タッチUI たぶん、ARM版で快適に動かそうと思ったらこっち App Storeで配布できるのはこっちだけ WinRTを使って作る（ネイティブ、.NET、JavaScriptから使える） 感覚的に、一番近いのはWindows Phone 7向けSilverlight（が、.NET 4.5相