Windows上のBashシェル入門【Windows 10 Fall Creators Update対応】（2） Windows Subsystem for Linuxを使って「開発」をしてみよう WindowsとWSL（Windows Subsystem for Linux）の間でファイルシステムを上手に相互運用するためのヒントや、WSLを活用してクロスプラットフォームな開発を行う方法を説明する。 亀川 和史

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

Windowsとの相互運用

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

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

Win32のC／C++のUnicodeアプリケーションとして提供する

特殊な表記（パス名の先頭に \\?\ を付加する）を内部で行う必要がある

を付加する）を内部で行う必要がある .NET Frameworkではサポートしていない

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

ASP.NET Coreサイトを動かす

それではここからは、LinuxやmacOSもサポートしているASP.NET Coreアプリケーションを、WSLのLinuxインスタンス（今回は「Ubuntu」）で実行してみよう。

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

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

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

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

Bash curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod xenial main" > /etc/apt/sources.list.d/dotnetdev.list' 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-sdk-2.0.0 リスト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.1.4）を、最新版をいち早く使いこなせるならCurrent Releases（執筆時点なら.NET Core 2.0.0）を選択すればよいというわけだ。.NET Coreのサポートライフサイクルの詳細は「.NET Core Support Lifecycle」（英語）で解説されている。

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

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

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

Bash dotnet new console -o buildinsider cd buildinsider dotnet run リスト3 Hello Worldアプリケーションを作成して実行する

▼

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

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

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

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

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

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

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

Bash dotnet new mvc -o buildweb cd buildweb 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のコンパイラーが搭載され、リモートデバッグ環境も用意された。

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

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

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

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サービスの起動

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

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行目に設定

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

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

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

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

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

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

図13 デバッグ中の様子

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

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

まとめ

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

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