一部のクラスで、 System.Net.WebSockets 名前空間は、Windows 7、Windows Vista SP2、および Windows Server 2008 でサポートされます。ただし、クライアントとサーバー Websocket の唯一のパブリックの実装では、Windows 8 および Windows Server 2012となります。

-------引用終了

と注意書きがあるように、定義はあるけれどWindows 8以降じゃないと実装が伴っていないところがあるからです。

なぜ、こんなことがあるかといえば、Windowsのカーネルモードドライバであるhttp.sysを直接利用することでHTTP周りのオーバーヘッドを少なくしているのですが、Windows 7のhttp.sysがWebSocketに対応していないからです。

Windwos 7のメインストリームサポートは終了しています

https://www.microsoft.com/ja-jp/atlife/article/windows10-portal/eos.aspx

みんな大好きWindows 7は2009年10月22日にライフサイクルがスタートして2015年1月13日にメインストリームサポートが終了しています。延長サポートの終了こそ2020年1月14日ということでまだ先ですが、延長サポート期間である現在はセキュリティ更新はおこなわれますが、仕様変更や新機能のリクエストはサポート対象外となり、これからWindows 7のHTTP.sysにWebSocket実装が追加されることはほぼないと考えてよいでしょう。

ではどうすればいいのか

一つの解決策としては、HTTP.sysを使わないWebSocket実装のコードを書く、もしくは、HTTP.sysを使っていないライブラリをNuGetで探してくるというものがあります。

https://github.com/kerryjiang/WebSocket4Net

https://github.com/sta/websocket-sharp

NuGetでライブラリを探すときは、企業ユースを考えるならばSystem.Net.WebSocketsならば対応している認証PROXYがサポートされているかなどのチェックを十分に行う必要があるでしょう。なお、残念ながら上記２つについてもまだきっちり調べ終わっていません。

しかし、System.Net.WebSocketsであればHTTP.sysを使って「オーバーヘッドが少ない」＝「性能がよいことが期待される」なのにWindwos 7をサポートすることでその利点を得られないという問題が生じてしまいます。

対象となる機能がWindows 7でも使えないといけないのか、もしくは、対象となる利用者がWindows 7をどれくらい使っているのかを見極めて判断するといいでしょう。

企業でもWindows 7からWindows 8.1やWindows 10への置き換え（少なくとも新規導入は8.1か10がデフォルト）が始まっている時期なので悩ましいところですね。

Windows 8以降かどうかをチェックする

Windows 7のときにはWebSocketを使った機能をdisableしたいときなどは、OSのバージョンチェックが必要になってきます。

対象はWPFとかWindowsフォームのときで、UWPやXamarin.Android、Xamarin.iOSのときは対象環境で動かないということはないのでチェックは不要です。

ですので実装時は

#if WPF

#endif

のようにifディレクティブを定義してその中でOSバージョンのメジャーバージョンとマイナーバージョンを取得してチェックします。

var searcher = new System.Management.ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem");
var os = searcher.Get().Cast().FirstOrDefault();
var major = 6;
var minor = 1;
if ((os != null) && (os["OsType"] != null) && (os["Version"] != null))
{
    if (os["OsType"].ToString() == "18")
    {
        major = new System.Version(os["Version"].ToString()).Major;
        minor = new System.Version(os["Version"].ToString()).Minor;
    }
}

Windows 10以上はmajor >= 10でよいのですが、Windows 8.xは、major == 6 && minor >= 2で判断しますので、その点だけ注意しましょう。

2017-09-26

2017年10月の登壇予定

NUI Windows10 Unity UWP 勉強会 HoloLens

2017/10/21(土)

fukuten.connpass.com

ASP.NET系ばかりなので、.NETのクライアント側ネタで乗り込みます！って通常枠は埋まっているのでLTで！

2017/10/29(日)

2017.sendaiitfes.org

2日間イベントの２日目に登壇します。MRアプリ開発の入門をわかりすく解説します。

2017/10/11(水)

metadata-jp.org

開催案内はまだですが、「今まで待っていたものに名前がついた。それはMixed Realityだよとあなたは言った。」というタイトルでWinMRの世界観を30分でお伝えいたします。

2017-09-24

Windows 10 Insider Preview Build 16294

Windows10

一般の方にはもしかしたらなじみがなく、また、仕事道具を動かすプラットフォームとしてWindowsを使っている人にも縁がないものに、Insider Previewがあります。

あくまでも「いまつくっている最中のバージョンを様々な環境でまずはつかってもらおう」というものです。

一般公開前ですから品質的に問題があったり致命的なバグがあったりも覚悟しつつ、アプリ開発していたり、OSそのものの新しい機能をいち早くためしたいという人がちょっとだけ未来に一般公開されるバージョンを試せるものということです。

Insider Previewのリリース間隔がみじかくなってくると、秋に公開されるというFall Creators updateもそろそろなの？みたいな感覚が味わえるのもいい点ですね。

もちろん、品質や日本語訳の変な点をどんどんフィードバックするのもInsider Preview参加者の役目の１つだったりします。

16294でなにがかわったかといえば以下のような点。変わったというよりもほぼバグフィックス。

Surface Pro 3でOSが起動できないバグの修正
オランダ版であったOneDriveからのダウンロード通知でクラッシュループが発生する問題の修正
expand.exeがファイル名に日本語が含まれているときに展開できない問題の修正
0x800B010Cが発生する問題の修正
insider build 16291をインストールしようとすると0ｘ80070057か0x8007071が発生する問題の解決

これをみて思うのは新機能の追加というよりも特定条件下で発生する問題の解決が多く、チューニングと汎用化の最終的な匙加減にはいてきたのかなって点。

よく「これくらいのバグをみつけられずにだしてくるのか？」なんて感想がブログで見受けられるけど、これ、なかなか面倒ですよね。対象ハードを絞れるといいだろうけれど。

あと、どうしてInsider Previewなのに「マイクロソフトも」みたいな感じで人格攻撃しちゃう人がいるのかはいつも不思議だったりします。問題点をかばう必要はないけど。きっと身近な人が失敗すると「だからお前はダメなんだ！」みたいな怒り方をしてそうですよね。

2017-09-07

HoloLensアプリのサンプルプロジェクトをgithubで公開する

HoloLens

ソースコードを公開せずに多人数でHoloLensアプリを作るときは、「Visual Studio Team Services」などで非公開でやっていくとよいと感じです。

ちょっとしたサンプルコードならば、gistなどもいいでしょう。

サンプルプロジェクトを公開するならgithubがやっぱり一番よさそうです。

HoloLensアプリを公開するときはUnityプロジェクトとUWPプロジェクトでそれぞれ別の.gitignoreファイルを置けると便利です。

そこで次のようなフォルダ構造を作成し、UnityプロジェクトフォルダとVisualStudioソリューションフォルダにそれぞれに適した.gitignoreファイルを置きましょう。

[アプリ名フォルダ]

+[Unityプロジェクトフォルダ]

+assets

|unityファイル

+UWP

|VisualStudioソリューションファイル

+[プロジェクトフォルダ]

このフォルダの作り方やその他の詳細はHoloLensアプリ作成時の共通作業（2017年9月編）を参照してください。

github上にサンプルプロジェクトのリポジトリを作成

新規にリポジトリを作るときに下の方に[.gitignore]ドロップダウンリストがあるので、そこで「Unity」を選択して「アプリ名フォルダ」と同じ名前でリポジトリを作成します。

Unityを指定したときの.gitignoreファイルの内容は次のようになります。

/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/Assets/AssetStoreTools*

# Visual Studio 2015 cache directory
/.vs/

# Autogenerated VS/MD/Consulo solution and project files
ExportedObj/
.consulo/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb

# Unity3D generated meta files
*.pidb.meta

# Unity3D Generated File On Crash Reports
sysinfo.txt

# Builds
*.apk
*.unitypackage

リポジトリをローカルにクローンする

リポジトリができたならば、ローカル（自分のPC）にリポジトリをクローンします。

このとき、すでにサンプルプロジェクトを作ってしまっていたならば、作成済のサンプルプロジェクトのアプリ名フォルダをリネームしておきます。そして、その場所を指定してクローンします。

ローカルドライブにフォルダが作成できならば、このフォルダを「アプリ名フォルダ」としてHoloLensアプリのプロジェクトを作成します。

あらかじめ作成してありリネームしてあるならば、そのフォルダの中身を移動してきます。

クローン下フォルダに移動するだけでローカル側の変更として検知されます。ここで、.gitignoreファイルをUnityプロジェクトフォルダに移動します。

今回はUWP側はUnityから自動生成すればいいのでUWPフォルダを丸ごと削除します。

UWP側でも独自のコードを書いているのであれば、UWPファイルだには次のような.gitigoneファイルを配置します。

#ignore thumbnails created by windows
Thumbs.db
#Ignore files build by Visual Studio
*.obj
*.exe
*.pdb
*.user
*.aps
*.pch
*.vspscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
*.dll
*.lib
*.sbr
*.msi
*.appx
obj/
bin/
TestResults/
AppPackages/
BundleArtifacts/
packages/
UpgradeLog*.*

コミットしてプッシュする

公開するコードがすべて格納出来たら、コミットを行い、プッシュします。

github上のUnityプロジェクトフォルダを見てみる次のようになります。

これでコードを公開できました。

github.com

はつねの日記

Kinect, Windows 10 UWP, Windows Azure, IoT, 電子工作

音声認識の仕組みやこれから進んでほしい未来についてお話します。

Visual Studio + Unity + MixedRealityToolkit 2017年10月15日現在のベストマッチ

HoloLensとPCのWindows 10のバージョン