Windows上のBashシェル入門【Windows 10 Creators Update対応】（2）

Bash on Ubuntu on Windowsを使って「開発」をしてみよう

2017年4月12日

WindowsとBoW（Bash on Windows）の間でファイルシステムを上手に相互運用するためのヒントや、BoWを活用してクロスプラットフォームな開発を行う方法を説明する。

亀川和史

　前回は、Bash on Ubuntu on Windows（以下、BoW）の概要とインストール方法を説明した。今回は、より実践的な内容として、BoWとWindowsでファイルシステムを上手に相互運用するためのヒントとして、Windows側のファイルパス作成時の注意点を紹介する。また、BoWを活用してクロスプラットフォームな.NET開発を目指したい人に向けて、ASP.NET Coreサイトを動かす方法と、WindowsからLinuxネイティブバイナリをデバッグする方法を説明する。

Windowsとの相互運用

　BoWとWindowsではもともとの思想の違いや、互換性の歴史などから異なっている点が多くある。前述のQ＆Aでも取り上げた「パス名の長さ」などはその最たるものの一つだ。

　前回述べたとおり、WindowsカーネルおよびNTFSでは64KB（UTF-16で3万2767文字）までは扱えた。しかし、長いファイル名を扱うには、以下のようにいくつかの条件があった。

Win32のC／C++のUnicodeアプリケーションとして提供する
特殊な表記（パス名の先頭に\\?\を付加する）を内部で行う必要がある
.NET Frameworkではサポートしていない

　恐らく、「BoWでは長いファイル名／パス名が多く生成されるようになる」という理由から、Windowsでも長いパス名に対する改良が行われることになったのだろう。ただし、現在流通しているほぼ全てのアプリケーションが上記の長いパス名をサポートしていないため、使用するにはOSとアプリケーションの設定を変更する必要がある。その設定方法については、英語になるが「公式ブログ：.NET 4.6.2 and long paths on Windows 10」を参照してほしい。

ASP.NET Coreサイトを動かす

　それではここからは、LinuxやmacOSもサポートしているASP.NET CoreアプリケーションをBoWで実行してみよう。

BoWでUbuntu環境に.NET Coreをインストールする

　まずは.NET Coreをインストールする。

　インストール方法は「.NET Core公式サイト：Install for Ubuntu 14.04, 16.04 & Linux Mint 17（英語）」でまとめられているので、最新の手順はそちらを参照してほしい。以下でも執筆時点の手順を参考情報として示しておこう。なお、執筆時点のInsider PreviewでのBoWはUbuntu 16.04 LTS（Long Term Support）なので、公式サイトの説明でも「Ubuntu 16.04」の方法を使用すればよい。なお、本稿ではapt-getコマンドの代わりにaptコマンドを使っているが、使い方はほぼ同じである（※Ubuntu 16.04からはaptコマンドの利用が推奨されている）。

　1まずはリスト1の手順で、.NET Coreパッケージ配布用リポジトリのフィードをaptのパッケージリストに追加する。

Bash

sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 417A0893

sudo apt update

リスト1　.NET Coreパッケージ配布用のaptフィードを追加

1行目を実行すると「sudo: unable to resolve host ＜ホスト名＞」というエラーが表示される場合は、sudo sh -c 'echo 127.0.1.1 $(hostname) >> /etc/hosts'というコマンドを実行して、hostsファイルにホスト名を追加してやる必要がある。

　追加後、.NET Coreパッケージがaptコマンドで利用可能になる。あとは、apt install ＜パッケージ名＞コマンドでそのパッケージをインストールできる。

　2そこで次にリスト2の手順で、.NET Coreパッケージ（＝開発用の.NET Core SDK）をaptでインストールする。

Bash

sudo apt install dotnet-dev-1.0.1

リスト2　.NET Core SDKをインストール

　ちなみに、現在の.NET Coreは「ランタイム」「dotnetコマンド」「開発キット」がそれぞれ別のバージョンのように見え、非常に分かりづらくなっている（※この状況について、日本語では芝村氏が解説している。参考：「しばやん雑記：.NET Core のバージョンが難しい」。マイクロソフトには、この辺がもう少しすっきりと分かるように整理してほしいものだ）。

　ちなみに.NET Coreランタイム／SDKの最新バージョンおよび、過去バージョンは、「GitHubのReleaseページ（英語）」でチェックしたりダウンロードしたりできる）。

【コラム】.NET Coreのサポートライフサイクル

　.NET Coreでは、サポートライフサイクルとして、Long Term Support（LTS）とCurrent Releasesの2種類が提供されている。基本的にLTSは「1.0」「2.0」……というメジャーリリースに適用され、Current Releasesは「1.0.0」「1.1.0」……というマイナーリリースに適用される。

　LTSは、正式リリースから3年間、もしくは次のLTSリリースがあればそのリリース日から1年間サポートされる。例えば.NET Coreランタイムのバージョン1.0.0は、2016年6月27日にリリースされたので2019年6月27日まで（3年間）サポートされるが、もし次のLTSリリースがあればその12カ月後まで（1年間）に短縮される。

　Current Releasesは、親の（＝最も直近の）LTSリリースと同じ3年枠の期間、もしくは次のLTSリリースがあればそのリリース日から1年間、もしくは次のCurrent Releasesのリリースがあればそのリリース日から3カ月間サポートされる。例えば2016年11月16日にCurrent Releasesでリリースされた.NET Coreランタイムのバージョン1.1.0は、親のLTSと同じ2019年6月27日まで（3年間）サポートされる予定だが、もし次のLTSリリースがあればその12カ月後まで（1年間）、もしくは次のCurrent Releasesリリースがあればその3カ月後までに短縮される。

　ユーザーは、LTSとCurrent Releasesのどちらかを選択できる。安定した技術を長く使いたい場合はLTS（執筆時点なら.NET Core 1.0.1）を、最新版をいち早く使いこなせるならCurrent Releases（執筆時点なら.NET Core 1.1.1）を選択すればよいというわけだ。.NET Coreのサポートライフサイクルの詳細は「.NET Core Support Lifecycle」（英語）で解説されている。

コンソールアプリケーションを構築する

　ここから先はBoWの利用例というよりも、.NET Core SDKの使い方の話になる。BoWで開発してもMacやLinuxと同様の手順が実現できることを示すために、また、ここまで手順どおりに試してきた方が実際にASP.NET Coreアプリケーションが動くところまで無事に進められるように、蛇足ながら、以降の開発手順のポイントを示しておくことにしよう。

　Hello Worldアプリケーションを実行するだけなら簡単だ。アプリケーション用のプロジェクトを作成したいフォルダーに移動して、以下のコマンドを実行する。各コマンドの意味については本稿の趣旨から外れるので割愛する。

Bash

dotnet new console -o buildinsider

cd buildinsider

dotnet restore

dotnet run

リスト3　Hello Worldアプリケーションを作成して実行する

▼

図1　BoW上でHello Worldアプリケーションの実行例

　もちろんこのプロジェクトは（BoWだけでなく）Windows上でも実行可能だ（図2）。ちなみに、ソースコードをGitなどのリポジトリから取得した場合は、必ずdotnet restoreを実行しないと、ビルドに必要なファイルを復元できないので、注意してほしい。

図2　BoWで作成したHello WorldアプリケーションをWindows上で実行した例

【コラム】.NET Coreのプロジェクトファイル形式変更について

　.NET Core SDK 1.0 Preview 3（dotnet-dev-1.0.0-preview3-004056）以降、.NET Coreのプロジェクトファイルが、JSON形式のproject.jsonファイルからMSBuild形式の.csprojファイルに変更された。既存のproject.jsonファイルはdotnet migrateコマンドで移行できるが、プロジェクトが参照しているパッケージに関しては移行が行われないため、注意してほしい。

【参考リンク】

ASP.NET Coreアプリケーションを構築する

　.NET Core SDK 1.0.1にはVisual Studioと同じテンプレートが内蔵されており、Visual Studioがなくても、基本的なアプリケーションの作成が可能になっている。内蔵されているテンプレートはdotnet new -lコマンドで表示される（図3）。

図3　dotnetコマンドで作成できるアプリケーションの一覧

　以下に示すように、コンソールアプリケーションと同じ手順でWebアプリケーションの作成が可能だ。

Bash

dotnet new mvc -o buildweb

cd buildweb

dotnet restore

dotnet run

リスト4　ASP.NET MVCアプリケーションを作成して実行する

▼

　ターミナルに“Application started”という表示が出るまで待ってから、Webブラウザーでhttp://localhost:5000/にアクセスすると、シンプルなASP.NET MVCのWebアプリケーションが実行されていることが分かる（図4）。実行中のASP.NET Core WebアプリケーションはターミナルでCtrl＋Cキーを押下することで終了できる。

図4　dotnetコマンドで生成したWebアプリケーション実行例

WindowsでLinuxアプリケーションの開発

　今までもWindowsでLinuxの実行ファイルを生成するクロスコンパイラーが提供されている開発環境はあったが、Visual Studio 2017より正式にLinuxのコンパイラーが搭載され、リモートデバッグ環境も用意された。

　BoWと併用することにより、限定的ではあるが、Linux仮想環境を用意することなくビルドやデバッグも可能になる。

BoWのリモートデバッグ設定

　まず、BoWにリモートデバッグ環境を用意する。既にインストールしたパッケージの依存関係によってはインストールされているパッケージもある。

Bash

sudo apt install -y build-essential

sudo apt install -y gdbserver

sudo apt install -y openssh-server

リスト5　コンパイラ、リモートデバッガ、sshサーバーのインストール

　sshdをインストールしたら、/etc/ssh/sshd_configファイルを編集して、パスワード認証を有効にする。具体的には図5のように、選択反転している“PasswordAuthentication”のところを“yes”に変更する。図5ではエディターとしてGNU nanoを使用しているが（リスト6）、vimなどの任意のもので構わない。

図5　ssdh_condigファイルを編集

Bash

sudo nano /etc/ssh/sshd_config

リスト6　sshd_configファイルをGNU nanoエディターで編集するためのコマンド

　次に、SSHの鍵を作成する（リスト6）。

Bash

sudo ssh-keygen -A

リスト7　sshの鍵を作成する

　最後に、sshサーバーを起動しておく（リスト8、図6）。

Bash

sudo service ssh start

リスト8　sshサーバーを起動する

図6　sshサービスの起動

　これでBoW側の設定は完了だ。

Visual Studioの設定

　前述したように、Visual Studio 2017からLinux開発環境が標準サポートされた。Visual Studio 2017のインストーラーで［C++ による Linux 開発］コンポーネントにチェックするとインストールされる。なお、コンパイラーが入っているわけではなく、プロジェクトテンプレートがインストールされるだけで、接続するLinuxにインストールされているコンパイラーを使うようだ。

図7　Visual StudioインストーラーでC++によるLinux開発を追加

ビルドおよびデバッグ

　実際にC++によるLinux開発を行うには、Visual Studioからプロジェクトの新規作成を行うときに、左側のツリーにある［Visual C++］－［クロスプラットフォーム］の中に［Linux］というカテゴリがあるのでこれを選択して、中央のテンプレート一覧から「コンソールアプリケーション (Linux)」を選択する（図8）。

図8　Visual StudioでLinuxのコンソールプロジェクトを作成する

　ここではビルドとデバッグを試すために、加算するだけのプログラムを用意して、ブレイクポイントを設定してから実行してみよう（図9）。

図9　Visual StudioでLinuxのコンソールプロジェクトを作成して、ブレイクポイントを10行目に設定

　この状態でコンパイルを実行すると、BoWへの接続ダイアログが表示される（図10）。ホスト名は自ホストなので［Host name:］欄には「localhost」を、［User name:］欄と［Password］欄にはBoWのユーザーとパスワードを指定する。他の入力欄はデフォルト値のまま、［Connect］ボタンをクリックしてBoWに接続する。

図10　BoWへの接続ダイアログ

　図10の接続ダイアログの情報は、一度指定するとVisual Studio内に保存される。設定を変更したい場合は、［オプション］ダイアログの［Cross Platform］から変更可能だ（図11）。また、「どのLinuxマシンに接続するか」といったリモート接続情報は、プロジェクトごとに指定できる（図12）。

図11　接続情報の管理（［オプション］ダイアログ）

図12　リモート接続情報はプロジェクトごとに設定可能（プロジェクトプロパティのダイアログ）

　最後に、Visual StudioでF5キーを押せば、デバッグが開始される。もちろん、Visual Studio内で開発しているときと同様に、ローカル変数や呼び出し履歴の参照も可能だ（図13）。

図13　デバッグ中の様子

　注意してほしいのは、Visual Studioでコンパイルを行っているのではなく、リモートのLinux（今回はBoW）に接続してソースコードをsshでコピーしたうえでビルドしているという点だ。ソース管理は必然的にWindows側で行うことになる。

　そのため、継続的インテグレーションでビルドする場合に、BoWを使おうとするとBoWが常時起動している必要があり、あまり好ましい使い方ではない。よってBoWではなく、ビルド用のLinuxマシンを用意して、そこでビルドを行うように接続設定を行ってほしい。BoWでのビルドはあくまでも補助的に使用してほしい。

まとめ

　今回はBoWを活用してクロスプラットフォームなASP.NET Coreおよび、Visual StudioでLinuxネイティブアプリケーションのビルドおよびデバッグを行う方法を説明した。

　BoWではまだLinuxのソフトウェアが100％動くわけではない（恐らくマイクロソフト自身もそこまでは目指していないだろう）。そうはいっても、マイクロソフトのクロスプラットフォーム戦略によりBoWが登場し、開発者向けのツールセットとして急速に進化し、便利になっていると感じているので、ぜひ日常の開発用途で使用してほしい。

1. Bash on Ubuntu on Windowsとは？そのインストールと使い方

Windows 10上で動作するBashシェルの基礎を理解・マスターすることをゴールとして、Bash on Windowsの概要から、インストール方法までを解説。また、よくある疑問をQ＆A形式で短くまとめる。

2017年4月6日(木曜日)

2. 【現在、表示中】≫ Bash on Ubuntu on Windowsを使って「開発」をしてみよう

2017年4月12日(水曜日)

3. Bash on Ubuntu on Windowsの、Creators Updateでの強化点＆新機能【Insiders Preview版】

あと1～2カ月でリリースされると見られるWindows 10 Creators Updateで、Bash on Windowsはどう進化するのか？最新Insider Previewの内容で強化点と新機能をいち早く知っておこう。

2017年3月7日(火曜日)

Windows上のBashシェル入門【Windows 10 Creators Update対応】（2）