Azure SDK v2.7 で ローカルの SQL Server を使いたい

何度目かの更新ですが、最新の Storage Emulator v4.1 データベースの初期化方法です。
今は、AzureStorageEmulator.exe を使うようになっています。

C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator

に AzureStorageEmulator.exe があります。

開発とテストのための Azure のストレージ エミュレーター使用
https://azure.microsoft.com/ja-jp/documentation/articles/storage-use-emulator/

を見ると、ストレージ エミュレーター コマンド ライン ツールのリファレンスがあるのですが…。
次のコマンドでローカルの SQL Server インスタンス内にデータベースを作成して初期化してくれます。
-sqlinstance の後ろに「 . 」があるので注意。

AzureStorageEmulator.exe init -server コンピューター名 -sqlinstance . -forcecreate -inprocess

AzureStorageEmulator_初期化

エミュレーターのバージョンでちょくちょくコマンドが変わっているような気がしている。
なお、2015/10/11 時点の最新の SDK は v2.7.1 になっていて、ストレージエミュレーターは v4.2 ですが、方法は同じです。

広告

Win10: OS のバージョン

Windows 10 RTM が目前に迫ってきました。
常に付きまとうバージョン問題。ここらで、一度、Windows 10 のバージョン値を確認しておこうと思います。
バージョン番号を取得する際、お約束の GetVersion() と GetVersionEx() になりますが、実は
Windows 8.1 以降では、GetVersion() および GetVersionEx() は推奨されない API になっていて
versionhelpers.h で定義されている Version Helper 関数を使うように推奨されています。
ただ、Version Helper 関数だと、具体的なメジャーバージョン、マイナーバージョンの値を取ることができず
Windows 10 以降とか、Windows 7 以降とか、そういう判定しかできない。
おそらく、Microsoft としては、もうメジャーバージョンとかマイナーバージョンで判断するのは辞めれって
メッセージなのでしょう。
実際、Windows 10 以降、OS メジャーアップグーレードの概念を変えるとアナウンスされていますし。

MSDN によると、OS のバージョン番号を取るにはシステム DLL に対して、GetFileVersionInfo() で見なさいと
言っているので、ちと面倒だ。DllGetVersion() という API ものがあるのですが、これは Shell 系の API なので
サービスからは使えないので、やはり、GetFileVersionInfo() を使うことになるのか。

試したところ、Windows 10 でも、まだ、GetVersionEx() が使えるようなので、こっちを使ってバージョン値を
調べてみますが、いつ何時消えるかもしれないので、製品開発では使わない方がいいと思います。

OSVERSIONINFOEX osvi;
BOOL bOsVersionInfoEx;

// OSVERSIONINFOEX構造体を用いて、GetVersionEx()を呼び出してみる
ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);

bOsVersionInfoEx = GetVersionEx((OSVERSIONINFO *)&osvi);
if (!bOsVersionInfoEx)
{
    osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
    if (!GetVersionEx((OSVERSIONINFO *)&osvi))
    {
        return GetLastError();
    }
}

Windows 8.1 / Windows Server 2012 R2 では、アプリケーションマニフェストの SupportedOS で
明示的な 8.1 宣言をしないと、GetVersionEx() は Windows 8 の 6.2 を返すという互換性処理がありました。
Windows 10 はどうなのかな…というわけでやってみます。
なお、Windows 10 の supportedOS の guid は MSDN ですでに公開されています。

<!– Windows 10 –>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!– Windows 8.1 –>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!– Windows 8 –>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!– Windows 7 –>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!– Windows Vista –>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>

まずは、マニフェストで supportedOS を記述しなかった場合は…

マニフェストなし

内部バージョンは 6.2 で返します。 ということは、Windows 8 ってことか。
次にマニフェストで supportedOS に Windows 8 を記述してみると…

Win8マニフェスト

まぁ、当然ですが、6.2 を返すわけです。
では、supportedOS に Windows 8.1 を記述してみると…

Win81マニフェスト

あー、6.3 ですか。そうですか。
では、最後に supportedOS に Windows 10 を記述してみると…

Win10マニフェスト

おー、きたきた!! バージョン情報が大きく上がった!!
では、まとめます。

OS 名称 バージョン値#1 バージョン値#2 バージョン値#3
Windows 10 10.0
supportedOS に Win10
6.3
supportedOS に Win8.1
6.2
Windows 8.1 / Windows Server 2012 R2 6.3
supportedOS に Win8.1
6.2 N/A
Windows 8 / Windows Server 2012 6.2 
N/A N/A
Windows 7 / Windows Server 2008 R2 6.1 N/A N/A
Windows Vista / Windows Server 2008 6.0 N/A N/A

MSDN に記載がある通りの結果になりました。
Windows 8 まではマニフェストの supportedOS への記述では OS モードだけの差異でしたが、Windows 8.1 以降は
OS バージョンと ビルド番号も変更しています。
しかし、Windows 10 で内部バージョンが一気に上がりましたねぇ。

Visual Studio 2012 以降には MAPI ヘッダーが無い

何とも肩身が狭い MAPI です。
Visual Studio 2012 以降には標準で MAPI ヘッダーはありません(インストールされません)。
SDK v8.0 や v8.1 にも入っていません。
MAPI プログラミングをする際には別途、MAPI 関連のヘッダーをダウンロードする必要があります。

なんだかねぇ。

Win8 & 2012: アプリケーション マニフェストの SupportedOS

Windows 7 & Windows Server 2008 R2 で追加になった Compatibility セクションの SupportedOS ですが
Windows 8 & Windows Server 2012 用に GUID が追加されています。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!–Windows 8 Mode–>
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!–Windows 7 Mode–>
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /
      <!–Windows Vista Mode–>
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
    </application>
  </compatibility>
</assembly>

  • Compatibility セクションは Windows 7 からサポートされる
  • Compatibility セクションがないアプリケーションは Windows Vista モードで動作する
  • Windows 7 以降の OS では、Compatibility セクション内の最も新しい OS レベルで実行モードを決定する

OS 実行モードの違いは次のようになります。

項目 Windows 8 Windows 7 Windows Vista
RPC の既定スレッドプール NT スレッドプール NT スレッドプール プライベートスレッドプール
DirectDraw の Lock API によるプライマリデスクトップビデオバッファーのロック 不可 不可
DirectDraw のクリッピングウィンドウなしでプライマリデスクトップビデオバッファーへのビットブロック転送 不可 不可
GetOverlappedResult API の複数回呼出しでの競合 競合は解決される 競合は解決される 競合は解決されない
ハイ コントラスト モードでの Shell Theme のステータス テーマ設定状況が返される テーマ設定できないことが通知される テーマ設定できないことが通知される
IPersistFile ハンドラー呼出しへの相対パスの使用 呼び出しに失敗する 続行する 続行する
プログラム互換性アシスタント (PCA) PCA による軽減策は適応されない PCA による互換性問題が追跡される PCA による互換性問題が追跡される

モードの確認方法も Windows 7 のときと同じで、リソースモニターを使うことで確認することができます。

リソースモニター

Windows 7 では、Windows Vista モードの実行モジュールが目立ちましたが、
Windows 8 では、多くの実行モジュールが Windows 8 モードや Windows 7 モードになりました。

ちなみに、Windows 8 の内部バージョンは 6.2 になります。

Win8 & 2012: OS のバージョン

Windows 8 & Windows Server 2012 ですが、メジャーバージョン 6 世代の 3 代目 OS になります。
ということは、内部バージョンは…

OS 名称 バージョン値
Windows Vista / Windows Server 2008 6.0
Windows 7 / Windows Server 2008 R2 6.1
Windows 8 / Windows Server 2012 6.2

OS のバージョンチェックですが、Vista 以降では、GetProductInfo() が推奨されていますが、VerifyVersionInfo() を
使っても大丈夫です。

このことからも、Steven Sinofsky から Windows 8 開発者向けのメッセージ

Everything that runs on Windows 7 runs on Windows 8

って納得ですね。

OSバージョン

ワタシは、Enterprise を使っています。

Windows Azure SDK v1.6 で SQLExpress ではなく、SQL Server を使う

Windows Azure SDK で SQLExpress ではなく、SQL Server を使う」 の更新です。
最新の Azure SDK は、v1.6 です。

v1.6 では、DSInit の場所が変更されています。
どこにあるかというと

C:\Program Files\Windows Azure Emulator\emulator\devstore

にあります。
なお、コマンド自体は同じです。

SQL Server のデフォルトインスタンス名で作成する場合は、次のコマンドになります。

DSInit /sqlInstance:. /forceCreate

AzureTools_Cmdv1.6

AzureTools_DSInitv1.6

作成されるデータベース名も変更されていて、DevelopmentStorageDb20110816 になります。

環境変数あれこれ

Windows の環境変数についてです。環境変数には、システム環境変数ユーザー環境変数の 2 種類があります。
これらは、レジストリの以下の場所に格納されています。

  • システム環境変数

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

  • ユーザー環境変数

HKCU\Environment

もちろん、画面でも表示できます。

システムのプロパティ 環境変数

レジストリに書きだしているわけですから、永続化された情報になります。

コマンドプロンプトを開き、set と入力しても環境変数を表示することができます。

コマンドプロンプト_setコマンド

ユーザーが Windows にログオンすると、シェルが起動され、環境変数を読み込みます。
その際、読み込む初期値が、このレジストリにエントリーされている値というわけです。

この投稿の続きを読む

WTL 8.1 11324 リリース

正式にパッケージングされた WTL Version 8.1 build 11324 が 2011/11/20 付けで公開されました。

前回の正式ビルドが、9127 だったので、結構、間が開きました。
一番のエンハンスは、正式ビルドで Ribbon サポートとなったことです。
以前、記事で 「WTL の最新版で Ribbon」 をアップした際、9127_rev448 というビルドを紹介しましたが
正式版がリリースされましたので、ビルド 11324 の方をお使いください。
(rev448 のダウンロードは停止しました)

見たところ、Ribbon ヘッダーである atlribbon.h は、rev448 と変更はありませんでしたが、
早速、11324 を組み込み、WTL ウィザードのままで、ビルドしてみました。

WTL11324_app

きちんと、Ribbon になっていますね。
オリジナルは、英語リソースですが、早速、リソースを日本語化してみました。

Administrator 権限を持っているか確認したい(その2)

たまたま見つけてしまいました。

以前、「Administrator 権限を持っているか確認したい」という記事を書いたのですが、自分でコーディングしなくても
そのものずばりの API がありました…。

Windows 2000 から使えた API のようで、内部で同じことをやっていると思います。
あわわわ。。。