Visual Studio 2017 MSDN 版でオフライン用インストールファイルを作る

MSDN サブスクライバーダウンロードで Visual Studio 2017 をダウンロードすると、Web インストーラーがダウンロードされてきます。Visual Studio 2017 からは ISO イメージの提供はありませんので、ネットワーク環境でのインストールが前提になります。ただ、当然のことですが、オフライン環境でもインストールできないと困るわけで…。
MSDN で提供される Visual Studio 2017 Enterprise 版は

mu_visual_studio_enterprise_2017_x86_x64_10049783.exe

がインストーラーです。(これがダウンロードされる)
これを使って、オフラインインストール用のキャッシュを作成することができます。
コマンドプロンプトを開いて

mu_visual_studio_enterprise_2017_x86_x64_10049783.exe --layout "G:\VS2017\Disk" --lang ja-JP

と実行すると、G:\VS2017\Disk にVisual Studio 2017 Enterprise の日本語インストール用のファイルをすべてダウンロードしてくれます。 ちなみに上記のダウンロードで70分くらいかかり、フォルダーサイズは約 20.7GB になりました。
コマンド打ったら、放置しておくのがよさそうです。待つのは辛いです。
このフォルダーごとインストール環境にもっていって、Disk 直下にある

mu_visual_studio_enterprise_2017_x86_x64_10049783.exe

を実行することで、オフライン環境でインストールすることができます。

参考情報

Bootable USB メディアを作ろう

Windows 10 Anivasary Update 1607 が公開されました。
ワタシの環境は、Windows 10 Enterprise なので、Windows 10 更新アシスタントからの更新や
メディア作成ツールが使えません…。悲しい。

そうなると、自前で Bootable USB を作ることになるわけ(わざわざ、DVD に焼くのが勿体無い)で
忘れないように残しておきます。やることは 3 つのステップです。

  1. USB メディアのフォーマットとアクティブ化
  2. インストールメディアファイルの全コピー
  3. ブートセクタの書き込み

まずは、「USB メディアのフォーマットとアクティブ化」を Diskpart コマンドを使ってやります。

管理者権限でコマンドプロンプトを開く
Diskpart コマンド実行
DISKPART> list disk
DISKPART> select disk X (USB メディアのディスク番号)
DISKPART> clean
DISKPART> create partition primary
DISKPART> select partition 1
DISKPART> active
DISKPART> format fs=fat32
DISKPART> assign
DISKPART> exit

続いて、持っている ISO イメージをマウントして、「インストールメディアファイルの全コピー」を xcopy で
全てコピーします。

マウントした ISO ドライブを S: ドライブ、USB メモリを U: ドライブとする
XCOPY S:\*.* /S /E /F U:\

最後に「ブートセクタの書き込み」です。これはインストールメディアにある bootsect コマンドを使います。

マウントした ISO ドライブを S: ドライブ、USB メモリを U: ドライブとする
管理者権限でコマンドプロンプトを開く
S:\boot> bootsect /nt60 U:\

これでおしまい。

SQL Server 2016 のオフラインインストールについて

SQL Server 2016 が GA となって一か月経過し、ポツポツ情報が出始めているこの頃です。
インストーラー(setup.exe)を起動してみると…

SQL2016インストーラートップ

なんか、過去バージョンと微妙に違っています。

SQL2014インストーラートップ

インストール対象環境がインターネット接続できる場合には何も問題ないですが、オフラインインストール時に
問題なくインストールできるのかは気になります。で、実際にやってみると、↓ で止まると思います。

SQL2016-R2

ウィザードに表示されている URL からダウンロードすればいいのですね。
では、アクセスしてみます。(ウィザードがテキスト表示だけでリンクになっていないのが残念)

https://go.microsoft.com/fwlink/?LinkId=761266&lcid=1041
https://go.microsoft.com/fwlink/?LinkId=735051&lcid=1041

すると、2016/07/01 現在だと

SRO_3.2.2.803_1033.cab
SRS_8.0.3.0_1033.cab

のファイルがダウンロードできます。このファイルを適当なフォルダーにコピーして選択してみると…

SQL2016-R3

「次へ」ボタンが非活性のままで、先に進まねえっすよ。
どうなってんだ、これ。

解決方法ですが、先ほどダウンロードしたファイルの名前を変更してから、再度、フォルダーを指定します。

  • SRO_3.2.2.803_1033.cab  SRO_3.2.2.803_1041.cab に変更する
  • SRS_8.0.3.0_1033.cab SRS_8.0.3.0_1041.cab に変更する

なんだかねぇ。
Microsoft のサイトを探しまくったら、米国サイトに情報がありました。

URL 文字列に 1041 を足しているんだから、こういうのは直してほしいもんです。

de:code 2016 二日目

de:code 二日目でした。

  • ARC-009    RDB技術者のためのNoSQLガイド
  • DEV-009    ここまでできる!Visual Studio 2015 ~強化されたC/C++ クロスプラットフォーム開発解説~
  • ARC-001    Updated: 5年後のアプリケーションアーキテクチャを考える
  • DBP-003    SQL Server 2016 Analysis Servicesのアーキテクチャとその活用方法
  • DEV-003    新しく生まれ変わったデータアクセステクノロジ ~Entity Framework Core 1.0の全貌~
  • PRD-005    Skype Developer Platformによるアプリケーション開発の最新情報

しかし、現地に行くまでの朝ラッシュがきつい。
都内に通勤する人ってすごい体力の持ち主よ。自分には無理だな。

DSC_0019DSC_0030

二日目はデータベーステクノロジーを中心に参加セッションをチョイス。

DSC_0029DSC_0033DSC_0034

今年一番感じたのは、ここ最近低迷が感じられた Microsoft テクノロジーが盛り返したなってことかな。
サポートエンジニア的な意見だけど、Windows に bash 入れるのはやめてほしいわ。
トラブルの元にしかならん。
せっかく、SUA(Subsystem for Unix Application) の呪縛から解放されたのに…。

de:code 2016 一日目

今年も de:code に行くことができました。

DSC_0002DSC_0004

開催場所は例年通りの ザ・プリンスパークタワー東京 です。
現場に 9:20 くらいに着いたのですが、何と、基調講演会場に入れず、隣のサテライトルームを案内された。
Nadella CEO の基調講演で人が増えたということか。
ただ、ここまで来てサテライト会場で聴講するというのであれば、どこかでライブストリーミングを見るのと変わりないわけで。
結局、基調講演会場の一番後ろで立ち見してました。参ったよ、本当に。

  • 基調講演
  • DEV-013    まだまだ進化が止まらない!開発者のためのMicrosoft Azure最新機能
  • DEV-002    .NET言語(C#)と.NETコンパイラプラットフォーム(Roslyn)最新情報
  • DEV-020    Bot Framework & Cognitive Services ~自動応答ソリューション開発に挑戦~
  • SPL-001    マイクロソフト最新テクノロジーと魅力ある未来像

基調講演は、build 2016 とほぼ同じ内容だったな。
デモは MS KK のエバンジェリストが担当していたので一部日本向けのものがあった。

キーワードは、Conversation as a Platform です。

今年の de:code はテクノロジーいっぱいで楽しくなりそうな予感がした。

参加者パーティにも参加したが、人が多すぎだよ…。
身動き取れなかった。

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 ですが、方法は同じです。

LDR と GDR

よく聞かれるので、まとめておこうと思う。

Microsoft は製品に何らかの不具合が見つかった場合に修正プログラムを提供しているのですが、この修正プログラムには

  • LDR : Limited Distribution Release
  • GDR : General Distribution Release

の二種類が存在します。
LDR も GDR も特定の問題に対する修正を行ったモジュールなのですが、LDR は局所的にテストを行ったもので、GDR は広範囲にテストを行ったものと認識してください。そのため、提供方法も若干異なります。
LDR はサポート技術情報(KB)からの個別ダウンロード & インストールとなるのですが、
GDR は、それに加えて、「重要な更新プログラム」という位置づけになると Microsoft Update でダウンロードされインストール
されることもあります。

  • 重要な更新プログラム
  • 更新プログラム
  • 更新プログラムのロールアップ
  • セキュリティ更新プログラム

よく、QFE という言葉を耳にしますが、本来、QFE(Quick Fix Engineering)は LDR のこと指しています。
なお、完全に特定環境における個別問題に対する修正モジュールを Hotfix と呼んでいます。

LDR に関しては一つ注意しておかなければならないことがあります。
一度でも LDR でモジュール適応した後、何かのタイミングで、そのモジュールがさらに更新されたとしても
LDR モジュールが適応され続けます。
更新されたモジュールに新しい LDR があれば、その新しい LDR が適応されることになります。
つまり、GDR が適応されることはなく、GDR を適応させたいという場合には、LDR をアンインストールした後に
GDR を適応する必要があります。

こんな事情があるので、Windows Vista 以降の GDR には、LDR が含まれています。
GDR は大体、拡張子 .msu (MIcrosoft Update Standalone Package)で提供されているのですが、
実は、このファイル展開することができます!

では、GDR の中にある LDR のインストール方法を紹介します。

  1. msu ファイルを個別に KB サイトからダウンロードする
  2. 適当なワークフォルダーを作成する
  3. コマンドプロンプトを開く(管理者用コマンドプロンプトである必要はない)
  4. コマンドプロンプトで
    expand -F:* <msuファイル名> <作成したワークフォルダー>
    を実行すると、ワークフォルダーにファイルが展開されます。
  5. ワークフォルダーに展開されたファイルの中に キャビネットファイル(.cab)がありますので、それを展開します。
    コマンドプロンプトで
    expand -F:* <cabファイル名> <作成したワークフォルダー>
    を実行すると、ワークフォルダーにファイルが展開されます。
  6. cab ファイルを展開したワークフォルダーに update-bf.mum というファイルがあることを確認します。
    これをパッケージマネージャーを使ってインストールします。
    pkgmgr /ip /m:<your dir>update-bf.mum

なお、ファイルのバージョン情報を見ると、LDR と GDR の区別ができます。

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 で内部バージョンが一気に上がりましたねぇ。

名前募集!?

マイクロソフトが窓辺家に、1名キャラを加えるそうだ。
DSP 版の情報サイト「Windows Navi+」で応援キャラクターを公開しとる。

    01

なんともすごい設定だわ。
100 年後の未来の窓辺家からやってきたとか…
Windows 10 だから、テンコ はダメだよね。