Windows上のBashシェル入門【Windows 10 Anniversary Update記念】
Bash on Ubuntu on Windowsとは？ そのインストールと使い方
Windows 10上で動作するBashシェルの基礎を理解・マスターすることをゴールとして、Bash on Windowsの概要から、インストール、開発での活用方法までを解説。また、よくある疑問をQ＆A形式で短くまとめる。
「次回アップデートで、WindowsにBashシェルが入る！」と、新機能の発表時から大きな話題となり、注目を集めてきた“Bash on Ubuntu on Windows”（以下、BoW）。このBoWが利用可能になるWindows 10 Anniversary Updateが、2016年8月2日（日本時間では3日）に公開された。図1はそのBoWの実行例だ。
今回のBashシェル搭載は、特にWeb開発者やPython／Rubyなどの開発者らにとって大歓迎されているのではないだろうか。最近では、ノウハウや情報が豊富なBashシェルで作業するケースが多くなってきている。そんなBash環境利用のために、本当は使い慣れたWindowsを使いたくても、仕方なくMacやLinuxを使っていたという人も少なくないだろう。そういう人にとっては、今回のBoWがWindows回帰に役立つ可能性がある。
では、BoWでどんなことができるのだろうか？ 本稿ではまず、「BoWがWindowsにおいてどんな位置づけのものなのか」といった特徴や背景、内部構成の概要、BoWが動作する仕組みを紹介し、次に、一般的によくあるBoWに関する疑問をQ＆A形式で簡潔にまとめる。さらに本稿後半では、BoWのインストールから、開発での活用方法までを一通り説明する。本稿を読めば、BoWの基礎から実践までが最短・最速で学べるようになっている。
Windowsの新しい開発ツールセット「Bash on Ubuntu on Windows」
今までのWindowsの*nix環境
WindowsでLinuxのツールを使う方法は、Anniversary Updateがリリースされるまでにもいくつか用意されていた。
- Hyper-V／VMware／VirtualBoxといった仮想化環境を使ってLinuxを実行する
- Git for Windows
- Cygwin
- MinGW
- MSYS2
このうち仮想化環境では、マシンリソースの消費やホストOSとのファイルのやりとりをシームレスに行えないという問題があった。
また、Cygwinをはじめとするエミュレーション環境では、シームレスなやりとりはできるものの、Windowsとツール類を共存させた場合に、同名のコマンドが意図せず呼び出されてしまう、という問題があった。例えば、findというコマンドはLinuxにもWindowsにも用意されている。しかし、両者の引数および、コマンドの仕様は異なっており、同じように呼び出すことはできない。例えば環境変数PATHに対して（Windowsのパスよりも）先にCygwinのパスが定義されていた場合、Windowsのfindコマンドを呼び出そうとしてもCygwin側のコマンドが呼び出されてしまい、意図どおりの正確なコマンド実行ができないといった問題が発生する。
かつてのWindowsには、POSIXやOS/2といったサブシステムが提供されており、それぞれのサブシステムに準拠したアプリケーションを実行することができた(POSIXは再コンパイルが必要、OS/2は16bit版のコマンドラインアプリケーションがそのまま実行できた)。しかし、これらのサブシステムは様々な理由からWindows XPで廃止された(POSIX and OS/2 are not supported in Windows XP or in Windows Server 2003)。UNIX環境との相互運用を目的としてServices for UNIX、Subsystem for UNIX-based Applicationsといったサブシステムが用意され、その上で動作するアプリーション（＝UNIXで提供されているツールを、POSIXサブシステムを使って移植したもの）が提供されていた。しかし、提供当時のニーズやマイクロソフトにおける製品戦略などが徐々に変化してきたためと思われるが、だんだんと収束し、現在では提供されていない。
これら従来のUNIX／Linuxツール使用環境に対し、最新Windows 10のBoWは、Linuxのツール（＝厳密にはLinuxディストリビューションの一つであるUbuntu上で動作可能なツール）をWindows上でそのまま使えるようにするために、仮想マシンでもコンテナーでもない、新しいサブシステムとして導入されたのだ。実利用において厳密なBoWの内部仕様を理解する必要はあまりないと思われるが、参考知識として、新サブシステムの内容と、Bashシェルが動作する仕組みを簡単に示しておこう。
BoWを支える新サブシステム「WSL」
現在のWindowsはもともと、マイクロカーネルに、複数のサブシステムが共存できるアーキテクチャだ。WindowsのGUIはWindowsサブシステムというサブシステムで動いているし、前述のとおり、かつてはPOSIXやOS/2といったサブシステムが提供されていた。
今回、BoWのために新しく作られたサブシステムは、Windows Subsystem for Linux（以下、WSL）と呼ばれている。WSLはPOSIXやOS/2サブシステムとは異なり、Linux互換環境を提供するlxss.sysとlxcore.sysという2つのカーネルドライバーで実装されている（※ちなみに「LX」は「Linux」を意味する省略語）。WSLでは、これら2つを合わせてPicoプロバイダードライバーと呼んでいる。
WSLの仕組みについて本格的に説明すると文章がかなり長くなってしまうので、以下ではWSLの大まかな概要のみを簡単に示す。ちなみに英語になるが、開発チームがWSLについて紹介しているビデオが公開されているので、詳細を知りたい場合は「Learn more about Bash on Ubuntu on Windows and the Windows Subsystem for Linux」に掲載されている各ビデオを参照してほしい。
WSLは、図2に示すような複数のコンポーネント群で構成されている。前述のlxss.sysとlxcore.sysは、この図ではLXSSとLXCoreというコンポーネントとして表現されている。この図の内容・意味については次節で説明する。
「Windows Subsystem for Linux Overview – Windows Subsystem for Linux」から「Figure 1: WSL Components」の図を引用（※画像は独自に拡張して再作成）。
Bashシェルが動作する仕組み
WSLによりBoW（＝Windows上で動くUbuntuのBashシェル）が実現するわけだが、その仕組みや処理の流れは前掲の図2で示されているので、ここではその図の内容を一通り説明しよう。
図2を見ると、ユーザーモード（＝通常のアプリケーションとして動作するもの）内に「bash」と書かれたコンポーネントが2つあるのに気付くだろう。左上にあるBash.exeは「Microsoft Bashランチャー」というアプリケーション名のコンソールウィンドウ（＝ターミナル）で、Windows上でユーザーが入力したコマンドを受け付けてBashシェルに渡し、またBashシェルの出力をユーザーに表示する。当然ながらBashシェルの本体は、Linuxインスタンス（Ubuntu）上にある/bin/bashの方である。
BoWインストール時には、Bash.exeにより処理が実行開始されると、黒色の矢印で示されている COM の流れでWin32プロセスであるLXセッション・マネージャー・サービス（LX Session manager service）が仲介して、緑色矢印の ioctl の流れでカーネルモード（＝Windowsカーネル側）で動作するPicoプロバイダードライバーがその処理を実現する形となっている。また、紫色矢印の Bus の流れで、Windows上で動くLinuxインスタンス（Ubuntu）が生成（init）・管理され、さらに青色矢印の fork の流れで、Linuxインスタンス（Ubuntu）上の/bin/bashがPicoプロセス（＝LinuxプログラムをWindows OS上でそのまま実行できるプロセス）として生成（fork）される。
また、BoW利用時に/bin/bash上で処理が実行されると、赤色矢印の syscall の流れで、Linuxのシステムコール（＝WindowsでいうAPIのようなもの）が発行され、それをPicoプロバイダードライバーが処理する。Picoプロバイダードライバー内部では、システムコールをフックして、Windowsに相当するAPIがある場合はWindows APIで処理を行い、Windows APIに存在しないシステムコールはLinuxカーネルが（つまりWSL内部だけで）処理する形になる。
なぜBoWが必要だったのか
ところで、なぜBoWが提供されるようになったのだろうか？ あくまでも筆者の想像だが、「オープンソース化の推進」と「クロスプラットフォームの推進」が大きな要因だったのではないかと考えている。
以前から多くのプロダクトがオープンソースで提供されていたが、ここ数年、特に企業が開発ツールやライブラリをオープンソースとして提供する例がさらに多くなってきた。そしてそれらはLinuxやMacを前提としているものが多く、Windowsは対応されたとしても後から、という状況もしばしば見られた。
前述のように、UNIX互換環境や仮想化環境で使うという方法もあるが、再コンパイルや、システムリソースの問題、前述したようなWindowsとの共存の問題も発生するため、「WindowsにLinux互換のサブシステムを作って動かせばいいのではないか」という発想になったのではないかと考えている。
2011年にMS Researchが『DrawBridge』という論文で「Windows以外のシステムを実行する軽量なサブシステム」を実現する仕組みを発表している。このDrawBridgeがBoWの原型になったと考えられる。
以上、BoWの特徴や仕組み、登場の背景を説明した。とはいっても、「WindowsでBashが動く」ということについて、依然としてさまざまな疑問が残っているのではないだろうか。インストールや使用方法の説明に入る前に、前提知識として、特によくある疑問をQ＆A形式で簡単にまとめておこう。
BoWに関するQ＆A
Q： PowerShellはどうなるの？ Windowsの管理もBash？
A： BoWはあくまでも開発ツールセットの一つとして提供されている。現時点において、Windowsの管理はあくまでもPowerShellやコマンドプロンプトで行う。
ちなみに先日（2016年8月19日）、PowerShellが.NET Coreを使用したオープンソースとして公開されることが発表された（参考：「PowerShell on Linux and Open Source!（英語）」。恐らく、マイクロソフトが提供するクロスプラットフォーム向けのツールでは、そのオープンソース版のPowerShellが活用されていくことになるだろう。
Q： 運用サーバーとして使える？
A： ライセンスとサポートの問題から使用できない。BoWではnginxやMySQLといった、サーバー機能のアプリケーションを実行することはできるが、あくまでも「クライアントOSにおける、開発ツールセットの一つ」という位置づけとなっている。
以下の公式ブログでも「サーバープラットフォームではない」と明言されている。
This is not a server platform upon which you will host websites, run server infrastructure, etc.
Q： Windows Server 2016にもリリースされるの？
A： 現時点において、クライアントOSであるWindows 10 64bit版にのみリリースされている。
以下のMSDNページでも「WSLはサーバー製品では利用できない」と言及されている。
Windows Subsystem for Linux will be available in desktop versions of Windows.
WSL is NOT a server technology and so will not be available on Server SKU's.
Q： 動かないものがあった場合はどうすればいいの？
A： 機能上のバグに関してはGitHubのissue、アイデアに関してはUserVoiceに、いずれも英語で書いてほしい。UserVoiceに投票する前に、既存のアイデアがないか、まずキーワードで検索して、似たアイデアがあった場合、そのアイデアに［Vote］ボタンを押して投票しよう。Voteの数が投票数となっており、Vote数が多いアイデアに関しては、開発チームにおいて優先的に実装する目安となっている。
投票数には上限が設定されているが、開発チームが開発終了などの理由でクローズしたアイデアに関してはVoteした数がユーザーに戻され、別のアイデアに投票できる。Voteおよびアイデアを投稿する際にはGoogleアカウントかFacebookアカウントが必要になる。
Q： Ubuntuで動いているパッケージを使いたいけど、再コンパイルが必要？
A： UbuntuのELF64バイナリがそのままWindows上で実行されるため、再コンパイルは不要だ。UbuntuのパッケージもCanonicalのサーバーからUbuntuの64bit版パッケージを取得しているし、非公式なリポジトリ（PPA：Personal Package Archive）を指定しても問題ない。もちろん、非公式リポジトリを使用する場合、提供元ベンダーおよび、サーバーが信頼できるかどうかの判断は使用者に委ねられる。
Q：どんなLinuxソフトでも動くの？
A： Ubuntuで提供されている全てのパッケージが動作するわけではない。WSLに実装されているシステムコールの範囲で動作するため、実際にパッケージをインストールしないと、動くかどうかは分からない。例えば執筆時点において、標準パッケージに含まれるコマンドでもshutdownのように実行できないコマンドがある。
（繰り返しになるが）BoWは開発ツールセットの一つとして開発されているため、開発ツールセットおよび、サービスに必要なシステムコールの実装が優先されているようだ。
Q： Windowsのログオンユーザーが使えるの？
A： WindowsのログオンユーザーとBoWのユーザーは無関係に管理される。BoWインストール時にBoW用のユーザーを作成する。
Q： 日本語ファイル名が使えるの？
A： 使用可能だが、現時点ではコンソールで文字化けするので、あまりお勧めはできない。BoWで提供されているコマンドが日本語ファイル名を扱えるかどうかは、Ubuntuで提供されているパッケージで日本語ファイル名が扱えるかどうか、という点に依存する。
Q： 空白を含むファイル名は使えるの？
A： こちらも日本語ファイル名と同様、BoWで使用するコマンドに依存する。しかし、LinuxをはじめとするUNIX系ではあまり空白をファイル名として使用しないため、Windowsで作られた空白を含むファイル名をBoWに渡さない方がよい。
Q： Windowsってパス名260文字までだから、長いファイル名が使えないのでは？
A： もともとWindowsが標準で使用しているNTFSというファイルシステムでは、最大64KBytes（UTF-16で3万2767文字）までのパス名をサポートしており、Win32のUnicodeアプリケーションであれば長いパス名を使用できた（※本稿でいう「パス名」とは、ドライブ名やフォルダー名、ファイル名を\で連結して並べたもののこと）。しかし、Windows 95系列との互換性のため、ほとんどのアプリケーションが260文字を上限にしている。.NET Frameworkでも、バージョン4.6.1までは、もしくはAnniversary UpdateをインストールしていないWindows 10では、260文字が上限となる。
WSLではNTFSの上限までの長さのパス名が使用できる。
Q： どこにインストールされているの？
A： 隠しフォルダー%LocalAppData%\LxSSにインストールされている（※Windowsエクスプローラーの［フォルダー オプション］ダイアログで［保護されたオペレーティング システム ファイルを表示しない (推奨)］のチェックを外さないと表示されない）。このフォルダーはWindowsのログオンユーザーごとに生成されているため、複数のユーザーでBoWを使用する場合、ユーザーごとにBoWやUbuntuパッケージのインストールが必要になる。
標準では%LocalAppData%はC:ドライブにあるので、C:ドライブの容量不足には注意が必要だ。
Q： セキュリティ
A： 不正な通信を遮断するためにはWindowsの「セキュリティが強化されたファイアウォール」で行う。ファイアウォールはWindowsと共有するため、BoW側でiptablesなどを設定する必要はない。BoW側で使用しているポートにアクセスできないといった場合は、まずはWindowsのファイアウォール設定を見直してほしい。
BoW固有の注意点として、SSH（Secure Shell）サービスがWindowsで実行されており、既定では全てのネットワークで外部からの通信を受け入れる設定になっている。BoWにSSHでログインする必要がなければ「セキュリティが強化されたファイアウォール」でSSH Server Proxy Serviceを無効にした後、「コンピュータの管理」でSSH Server BrokerとSSH Server Proxyを停止する。コマンドで行う場合、「管理者として実行」したPowerShellから以下のコマンドレットを実行して、ファイアウォールルールの無効化および、サービスを停止すればよい。
Disable-NetFirewallRule -Name "SshProxy-Service"
Stop-Service -name SshProxy
Disable-NetFirewallRule -Name "SshProxy-Service"
BoWの導入
さて、BoWに関する必要十分な基礎知識が備わったところで、ここからは実践編としてBoWのインストールや使用方法の説明に入ろう。
BoWを使用するには、事前に64bit版のWindows 10 Anniversary Updateをインストールしている必要がある（つまりWindows 10を最新版にアップデートすればよい）。Anniversary Updateをインストールしていれば、BoWは64bit版のWindows 10のHome／Professional／Enterpriseの全エディションで使用できる。
［準備］開発者モードの有効化
まず、Windowsを開発者モードに変更する。これには、Windowsの［スタート］メニューの［設定］から［更新とセキュリティ］を選び、左側の［開発者向け］タブを選択する（図3）。
次に、図3の［開発者モード］ラジオボタンを選択すると、開発者向け機能を使用するかどうかを確認するメッセージが表示されるので（図4）、［はい］をクリックする。
これで準備は完了だ。
WSLのインストール
次に、管理者モードでPowerShellウィンドウを起動し、以下のコマンドレットを実行する（※コマンド実行中に再起動を要求されるので、Windows 10を再起動する）。
|
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
|
BoWの初期設定
再起動後、［スタート］メニューから［bash］を実行する（図5）。
これにより、bash.exeが実行されてウィンドウが起動する。図6のように「ベータ機能であること」と「ライセンス条件に関する情報」が表示され、続行するためにはyキーを押すことが求められる。ここでyキーを押すと使用許諾条件に同意したことになり、Ubuntuパッケージのダウンロードが開始される。ダウンロード完了後に、Windowsファイルシステム上にBoWが展開される。
展開終了後、図6のように表示されるので、BoW用に独自のユーザー名とパスワードを入力する。なお、Windowsのユーザー名およびパスワードと一致させる必要はない。
パスワードを入力すると準備完了だ。しばらく待つと図7のようにBashシェルが起動した状態になるが、BoWの初期設定が完了した段階で［Bash on Ubuntu on Windows］というショートカットが［スタート］メニューから利用できるので、現在のbash.exeウィンドウは一度、終了する。
ちなみに、図7では/mnt/c/Windows/System32というディレクトリが選択されており、BoW上でWindowsのシステムフォルダーがカレントディレクトリとなっている状態だ。このディレクトリパスから分かるように、BoWからWindowsファイルシステムにアクセスしたい場合には、cd /mntコマンドでLinuxのマウントディレクトリに移動したうえでlsコマンドを実行すればよい。マウントされているWindowsのファイルシステム上のドライブが列挙されるので、そこからたどって目的のディレクトリに移動する。また、BoWユーザーのホームディレクトリに移動したい場合には、単にcdとコマンド入力すればよい。
【ヒント】BoWが正常にインストール完了しない場合／BoWの再構築
BoWのインストールが完了しない場合は、セキュリティソフトが影響している可能性がある（特にカスペルスキーとBoWは相性が悪いようだ）。その場合には、いったんセキュリティソフトを終了してみてほしい。これで解決する場合がある。
また、BoW環境をゼロから再構築したい場合は、PowerShellもしくはコマンドプロンプトで下記のコマンドを順に実行するとよい。このように簡単なコマンド実行だけで、Linux環境を再構築できるのもBoWの魅力である。
- （1）BoWをアンインストール：
lxrun /uninstall /full - （2）BoWを再インストール：
lxrun /install
BoWの起動（次回以降の使い方）
次回以降のBoWの起動では、［スタート］メニューに登録されている［Bash on Ubuntu on Windows］をクリックして実行する（図8）。
Ubuntuパッケージの導入
BoWはUbuntuそのものなので、パッケージのインストール／更新／削除はapt-getコマンドで実行可能だ。apt-getの使い方は、「公式ページ：AptGet/Howto（英語）」を参照してほしい。
ここでは例として、Webサーバー「nginx」のUbuntuパッケージをインストールしてみよう。具体的にはリスト2の手順で、apt-getのパッケージリストを更新してから、nginxパッケージをインストールする。
|
sudo apt-get update
sudo apt-get install nginx
|
これだけでnginxが実行可能になる。より詳しくは下記のリンク先を参考にしてほしい。
英語環境でBoWを使用したい場合
Anniversary Updateで提供されているBoWでは、自動的にWindows 10のロケール設定と同じロケールのUbuntuがインストールされる。現時点のBoWはベータということもあり、日本語ロケールでは表示が欠けるなどの問題がある。この場合、英語ロケールにすることで問題を回避できる。
もちろん、インストール後のUbuntuを手動で英語ロケールに変更することもできるが、最新のInsider Preview（執筆時点ではビルド14905。※一般ユーザーにはまだ提供されていない）では、インストール時にOSのロケールに一致させるかどうかの確認メッセージが表示され、ロケールをそこで指定できるようになっている。具体的には以下の画面でnを入力すれば英語ロケールでBoWがインストールされる。
BoWを使用した開発
最後に、より実践的な内容として、BoWとWindowsでファイルシステムを上手に相互運用するためのヒントとして、Windows側のファイルパス作成時の注意点を紹介する。
また、BoWを活用してクロスプラットフォームな.NET開発を目指したい人に向けて、ASP.NET Coreサイトを動かす方法を説明する。
Windowsとの相互運用
BoWとWindowsではもともとの思想の違いや、互換性の歴史などから異なっている点が多くある。前述のQ＆Aでも取り上げた「パス名の長さ」などはその最たるものの一つだ。
前述のとおり、WindowsカーネルおよびNTFSでは64KBytes（UTF-16で3万2767文字）までは扱えた。しかし、長いファイル名を扱うには、以下のようにいくつかの条件があった。
- Win32のC／C++のUnicodeアプリケーションとして提供する
- 特殊な表記（パス名の先頭に
\\?\を付加する）を内部で行う必要がある - .NET Frameworkではサポートしていない
恐らく、「BoWでは長いファイル名／パス名が多く生成されるようになる」という理由から、Windowsでも長いパス名に対する改良が行われることになったのだろう。ただし、現在流通しているほぼ全てのアプリケーションが上記の長いパス名をサポートしていないため、使用するにはOSとアプリケーションの設定を変更する必要がある。その設定方法について、「Win32アプリケーションの場合」と「.NET Coreおよび.NET Frameworkの場合」に分けて説明しておこう（参考：「公式ブログ：.NET 4.6.2 and long paths on Windows 10（英語）」）。
ASP.NET Coreサイトを動かす
ここからは、LinuxやmacOS（OS X）もサポートしているASP.NET CoreアプリケーションをBoWで実行してみよう。
BoWでUbuntu環境に.NET Coreをインストールする
まずは.NET Coreをインストールする。
インストール方法は「.NET Core公式サイト：Install for Ubuntu 14.04, 16.04 & Linux Mint 17（英語）」でまとめられているので、最新情報はそちらを参照してほしい。執筆時点のBoWはUbuntu 14.04 LTS（Long Term Support）なので、公式サイトの説明でも「Ubuntu 14.04」の方法を使用すればよい。ここからは、公式サイトの「Ubuntu 14.04」の方法と同様の説明を日本語で記載していく。
1まずはリスト3の手順で、.NET Coreパッケージ配布用リポジトリのフィードをapt-getのパッケージリストに追加する。
|
sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list'
sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
sudo apt-get update
|
1行目を実行すると「sudo: unable to resolve host ＜ホスト名＞」というエラーが表示される場合は、sudo sh -c 'echo 127.0.1.1 $(hostname) >> /etc/hosts'というコマンドを実行して、hostsファイルにホスト名を追加してやる必要がある。
追加後、.NET Coreパッケージがapt-getで利用可能になる。あとは、apt-get install ＜パッケージ名＞コマンドでそのパッケージをインストールできる。
2そこで次にリスト4の手順で、.NET Coreパッケージ（＝開発用の.NET Core SDK）をapt-getでインストールする。
|
sudo apt-get install dotnet-dev-1.0.0-preview2-003121
|
リスト7を見ると-preview2-003121というバージョンの.NET Core SDKになっている。.NET CoreランタイムはRTMになったが、開発キット（SDK）はまだプレビューであるためだ。これはLinux版だけではなく、Visual Studioと組み合わせるWindows版も同じく「Preview2」となっている（ちなみに.NET Coreランタイム／SDKの最新バージョンは、「.NET公式サイトのDownloadsページ（英語）」でチェックしたりダウンロードしたりできる）。
Visual Studioの場合、現在、Preview3が公開されている次期Visual Studio “15”の正式版と同時期に、Visual Studio用の.NET Core SDKもRTMになる見込みだ（参考：日本マイクロソフトのエヴァンジェリスト井上章氏のブログ「.NET Core 1.0 リリース！」）。
コンソールアプリケーションを構築する
ここから先はBoWの利用例というよりも、.NET Core SDKの使い方の話になる。BoWで開発してもMacやLinuxと同様の手順が実現できることを示すために、また、ここまで手順どおりに試してきた方が実際にASP.NET Coreアプリケーションが動くところまで無事に進められるように、蛇足ながら、以降の開発手順のポイントを示しておくことにしよう。
Hello Worldアプリケーションを実行するだけなら簡単だ。アプリケーション用のプロジェクトを作成したいフォルダーに移動して、以下のコマンドを実行する。各コマンドの意味については本稿の趣旨から外れるので割愛する。
|
dotnet new
dotnet restore
dotnet run
|
もちろんこのプロジェクトは（BoWだけでなく）Windows上でも実行可能だ（図11）。ちなみに、ソースコードをGitなどのリポジトリから取得した場合は、必ずdotnet restoreを実行しないと、ビルドに必要なファイルを復元できないので、注意してほしい。
ASP.NET Coreアプリケーションを構築する
まず下記のリンク先からダウンロードしたインストーラーを使って、Visual Studio 2015 Update3にVS 2015 Tooling Preview 2をインストールする。
次に、下記のリンク先の手順に従い、より高度なテンプレートを扱えるYeoman環境をインストールしたうえで、Yeomanで使えるASP.NET Coreのジェネレーターもインストールする。もちろん、Visual Studioに付属しているASP.NET Coreテンプレートを使ってプロジェクトを作成しても問題ないが、Bashシェル上でプロジェクトを作成する場合にはYeoman＋ASP.NET Coreジェネレーターを使う必要がある。
残念ながら、作成したASP.NET Core WebアプリケーションはBoWで実行しても動作しない。現状のBoWのバグのようで、下記のリンク先で説明されている。
- dotnet core on Bash on Unbuntu on Windows（英語）
- On local server start error says the port is already in use（英語）
このバグが修正され正常に実行できるようになったら、あらためて解説をここに追記する予定だ。
まとめ
いかがだっただろうか？ BoWを使用できるようになったことで、従来のようにWindows上でLinux仮想化環境を構築したり、別途Linuxマシンを用意したりすることに比べれば、非常に低コストでLinux環境をWindowsだけで完結させられる可能性が見えてきた。
とはいっても、前述のようにまだまだ足りない機能やバグもあるのは事実である。だが現状でも、Linuxでしか動かなかった数多くのツールをWindows上でそのまま動かせるようになっており、例えば「Linux用のバイナリを生成するためのビルドエージェントを実行する」といった用途においては非常に便利に活用できるだろう。