Visual C++ で Windows フォームアプリケーションを作ることはすでに推奨されていない

Visual C++ 2012 の Break Changes にも書かれていたようですが、Visual C++ 2012 から Windows フォームアプリケーション関連のプロジェクトテンプレートの削除、そして以下のような内容が掲載されています。

Although we recommend that you do not create Windows Forms applications in C++/CLI, maintenance of existing C++/CLI UI applications is supported. If you have to create a Windows Forms application, or any other .NET UI application, use C# or Visual Basic. Use C++/CLI for interoperability purposes only.

つまり、「既存のメンテナンスを除いて、Windows フォームアプリケーションを C++/CLI で書くな」ということです。
「C++/CLI はネイティブ資産との相互運用目的に使う」とも書かれているので、これで C++/CLI の役割ははっきりしたと言えますね。

なお、最近、KB(Microsoft のサポート情報)にも同様のコメントが公開されています。
問い合わせがあったのかもしれませんね。

https://support2.microsoft.com/kb/3001686

Windows 10 Technical Preview における .NET 3.5 の扱い

ご注意:Windows 10 は Technical Preview というプレリリースソフトウェアの段階です。製品版までの間に仕様変更が行われる可能性が高く、この記事はあくまで現時点の状態について語るものです。この記事の内容を信じて行動した結果、最終的に被害・損失などにつながったとしても筆者は保証しません。

 

Windows 10 Technical Preview の現状を確認する意味で Hyper-V 上にクリーンインストールしました。
個人的に気になっていた、.NET Framework 3.5 の扱いですが、Windows 8/8.1 と同様のようです。
つまり、デフォルトではインストールされておらず、インストールを選ぶとオンラインからダウンロードしようとする振る舞いのままと言うことです。

image

image

image

 

あえて、ネットワークアダプタを無効にすると失敗します。
(dism を使う方法がまだ有効かは試していません)

 

このまま方針が変わらなければ、「.NET Framework 2.0 ~ 3.5 ベースのアプリはインストールしただけでは使えない」となります。(Windows 8/8.1 も同様)
Windows 8/8.1 には正式対応していないが、Windows 10 のタイミングでは何とかしたいというベンダーの方々は、.NET Framework 4 以上への移行を計画的に進めた方が良いでしょう。

(オフラインの環境だけど使いたいというエンドユーザーに説明して、dism コマンドを使ってもらうのは大変ですし、使えないクレームは自分たちベンダーに来るということを考えると、移行は必要でしょう)

.NET 2.0-3.5として作られたアプリを.NET 4ランタイムで動かせるか?

.NET 4からCLRが新しくなったことで、基本的に.NET 3.5で作られたアプリのプラグイン、アドインを.NET 4で作ることはできません。
これを回避するためにはいくつかの方法が考えられます。

  1. 対象アプリを.NET 4で動かす。
  2. .NET 3.5でプラグイン、アドインを作り、.NET 4のアプリと通信する。
  3. .NET 4で作ろうとしていた部分をネイティブ、COMで作って利用する。

まっとうな方法は2や3になるかと思いますが、.NET 4で無理矢理動かす方法を少し見てみましょう。

対象のアプリがhogehoge.exeだとすると、hogehoge.exe.configに以下のような記述を作ります。

<configuration>
   <startup useLegacyV2RuntimeActivationPolicy="true">
      <supportedRuntime version="v4.0"/>
   </startup>
</configuration>

参考URL:http://msdn.microsoft.com/ja-jp/library/jj152935(v=vs.110).aspx

これでたいていのアプリは.NET 4で動きます。
ただし、勝手に.NET 4で動かしているので無保証となる点にご留意いただき、利用者の自己責任で使うことを前提としてください。

なお、プラグイン・アドイン方式でセキュリティ問題をケアしている場合、CAS周りでNotSupportedExceptionが発生する可能性があります。
loadFromRemoteSourcesを使って脆弱にして動かすか、素直に2や3のアプローチを採るか、よく考えましょう。

修正された?:Windows8.1開発者用ライセンスを取得できませんでした エラー 0xC03F1014

先月、MSDN フォーラムで「Windows8.1開発者用ライセンスを取得できませんでした エラー 0xC03F1014」と表示されて開発者用ライセンスが取得できないという質問 が挙がっていた。

今月に入って、KB2913270 を適用すると改善する という情報が Microsoft の担当者から寄せられているので、もし、お困りの方は試してみてはいかがでしょうか。

http://support.microsoft.com/kb/2913270

Microsoft Help Viewer 2.1でローカルストアパスがアクセスできなくなった場合のリカバリー

Visual Studio 2013 などに標準で付属している Microsoft Help Viewer 2.1(ヘルプビューア)はコンテンツの管理画面からローカルストアを変更することができます。

image

この時に指定したフォルダー・ドライブが何らかの事情でアクセスできなくなると、エラーメッセージとして「ヘルプ コンテンツのインストール先に指定した場所が無効か、アクセス許可がありません。」というエラーを表示し、即座に終了するという回復不能な状態に陥ります。

image

そこで、この状態からの回復をトライしてみた記事を取り上げてみます。
手順の途上にレジストリを触る箇所があります。レジストリは取り扱いを間違えると Windows が起動しなくなるなどの深刻な事態を招く可能性があります ので、十分にお気をつけください。

  1. レジストリエディタで以下の場所を開く。(Visual Studio 2013 の場合)
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Help\v2.1\Catalogs\VisualStudio12(64bit 環境)
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Help\v2.1\Catalogs\VisualStudio12 (32bit 環境)
  2. LocationPath にアクセスできなくなったフォルダーパスが入っているので、新しく保存先としたいフォルダー名を指定する。
    image
  3. これだけでは足りないので、指定したフォルダーに空のファイルでよいので「CatalogType.xml」という名前を持つファイルを作る。
    たとえば、新規テキスト文書で作ってこの名前に変えてもよい。拡張子を変えるため、拡張子を表示しておいた方がやりやすいです。
  4. ここまでで準備完了で、また Visual Studio 2013 からヘルプを表示しましょう。

今回、試した Windows 7 (x64) 環境では回復できました。
環境やバージョンによってはうまくいかないかもしれませんので、自己責任で試してください。

VS2013 リリース後の VS2012 言語パックの入手方法

Visual Studio 2013 がリリースされたことにより、Visual Studio のダウンロードページから Visual Studio 2012 の言語パックのダウンロードリンクがなくなっていそうだったので、ダウンロード方法をメモしておく。

http://www.microsoft.com/ja-jp/download/details.aspx?id=30681

このページに飛んだ上で、「言語を選んでください」から対象の言語を選べばよい。試しに「英語」を選んだ先のダウンロードリンクから英語の言語パックのダウンロード・インストールができた。

MSDN サブスクリプション契約者であれば、サブスクライバーダウンロードから「Visual Studio 2012 Language Pack」で検索すれば出てくる。検索対象言語でインストールしたい言語を選ぶのを忘れないようにしましょう。
検索で出てくるのは「Visual Studio 2012 Language Pack (x86) – Web Installer (English)」といった名称です。

(Visual Studio 2012 から海外版の Visual Studio をインストールすることなく、別言語の IDE を使えるようになっており、Visual Studio 2013 でも踏襲されている模様)

WebClient トラブル調査:ヘッダーの差異を調べる

わんくま同盟さんの質問掲示板の「C++.NetでWebClientのOpenReadについて」からのネタです。

今回の事例では、IE からは閲覧できて、WebClient では 503 エラーとなるものでした。
そこで、かんたんにコードを書いて実験することにします。

var wc = new WebClient();
using (var stream = wc.OpenRead(url))
{
}

※url はリクエストを投げる URL を示す文字列変数。

実際に質問に上がっていた URL で試すと、確かに 503 エラーを内包する Exception がスローされます。

ここで、Fiddler を使って差分を見ることにします。

まずは、上記のサンプルコードで試したときの通信内容です。

左側でセッションを選択すると右側に詳細が表示されますので上のビューの Headers を確認します。

非常にシンプルなリクエストになっていることがわかります。

image

次に IE で同じ URL にアクセスしてみて、多数のセッションが表示される中で、同じ URL に対するリクエストを選択して、同じように上のビューの Headers を確認します。

(掲載画像は関係ない部分をモザイクでつぶしています)

image

Accept, Accept-Encoding, Accept-Language, User-Agent などが増えていることがわかります。

1 つのヘッダーを追加するだけで足りるかもしれませんし、複数のヘッダーを追加しないとダメなケースもあるかもしれません。組み合わせを考えて試してみましょう。

今回の事例では User-Agent を何か指定すれば OK だったみたいですので、1 個ずつ試していけばそのうち解決しますね。

なお、この方法でわかるのは、その時点の相手のページがどのようなヘッダー、値を条件にしているかだけであり、将来的に変更される恐れがあります。これは相手の方針やメンテナンス・リニューアルなどの事情によるので不確か(リスク)です。

もしも、相手側がブラウザー以外の閲覧を好ましく思っていないのであれば、無理にやらない方がいいかと思います。

unsigned short型配列からBitmapを作る

ありふれたネタかもしれませんが、コミュニティでそれらしい質問が上がっていたのでざっと書いてみました。

http://wp.me/a19AcI-5U
(Visual Studio 2010 / .NET 4 プロジェクト)

鍵となるのは Bitmap クラス、BitmapData クラスです。(WriteUInt16ToIndexed8Bitmap や WriteUInt16ToRgb24Bitmap あたり)
Bitmap クラスをサイズ・ピクセルフォーマットを指定してインスタンスを生成し、そのインスタンスの LockBits メソッドで書き込み先のメモリを用意します。
このメモリに必要な変換を書けたデータを 1 bytes / pixel や 3 bytes / pixel で Marshal.Copy や unsafe のポインタで書き込んで、UnlockBits メソッドで閉じるだけ。

ただし、Format8bppIndexed の場合はカラーパレットの設定も必要なのでお忘れなく。

※上記サンプルを .NET 3.5 以前で実行する場合、currentPointer 変数周りでコンパイルエラーになりますので、一旦 long 型にキャストして足し算してから、IntPtr 型にキャストし直してください。(currentPointer = (IntPtr)((long)currentPointer + stride); みたいな形)

カテゴリー: C#