デスクトップ アプリからのWinRT API利用
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
.NET Native
.NET Nativeとかいうものが公開された模様。.NET言語（さしあたってはC#のみがサポート対象）からNativeコードを直接作る仕組み。 公式ページ: Microsoft .NET Native MSDN Library 内のヘルプ: http://msdn.microsoft.com/en-us/library/dn584397.aspx 去年の暮ぐらいから噂にはなっていたもの。//build/ の初日キーノートでは出てこなかった（初日は OS 関連。WP8.1とかの話題）ので公開明日かと思ったらもう。 概要 以下のようなもの。 WP8が使ってるMDILに基いた技術 クライアントデバイスには完全にネイティブ化した状態で配布 クライアント上で余計な電力消費しないし、初回起動も早い 当面のターゲットはストアアプリのみ。ただし、ターゲットは今後広げていきたい 前にプロ生勉強会で話した通
どうしてこうなった
ほんと、どうしてこうなったかなぁ。 Oralceの対Google訴訟、プログラミングの将来を危うくしている 二分された世界 JVM と .NET、もろに競合なわけですが。少しレイヤーが違うとか、棲み分けできるポイントがあるならともかく、ほんとに2個あってもしょうがない状態。競争があるのはいいと思うものの、どうせ競争するなら最低ラインの仕様そろった中で性能改善とかで競って欲しく。 でも、後発の .NET だけが悪いわけでもないのは今の DalvikVM の状況を見ての通り（Oracle になってひどくなったわけでもなく、Sun の時代も大概）。このままだと仕様が違う第3の仮想マシン（VM）ができてしまってもおかしくない状況… 個人的な意見として、「もしもの話」で、一番よかっただろう道筋は、2000年前後の訴訟がなくて、Microsoft Java VM が生きている状態。.NET が生まれる
Windows 8、WinRT « ++C++; // 未確認飛行 C ブログ
BUILD、まだ基調講演くらいしか見れていませんが、それだけでもなかなかに素敵。 そして、公開されて間もないWindows 8の開発者プレビュー、さっそく使ってみているわけですが。 開発者的に気になっていたのは、うわさのWinRT。 コードネームとかじゃなく、正式名称的にもこの名前でよかったわけですが、実物見るとなかなかに楽しそう。 Metroアプリ vs 既存デスクトップ 開発スタイル的には全く別系統でした。いわば、Silverlight と WPF みたいなもの。 Metro アプリ タブレット向け、タッチUI たぶん、ARM版で快適に動かそうと思ったらこっち App Storeで配布できるのはこっちだけ WinRTを使って作る（ネイティブ、.NET、JavaScriptから使える） 感覚的に、一番近いのはWindows Phone 7向けSilverlight（が、.NET 4.5相
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
