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

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アプリケーションはターミナルでCtrlCキーを押下することで終了できる。

図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 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形式で短くまとめる。

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

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

3. Bash on Ubuntu on Windowsの、Creators Updateでの強化点&新機能

正式リリースされたWindows 10 Creators Updateで、Bash on Windowsはどう進化するのか? その強化点と新機能を紹介する。

サイトからのお知らせ

Twitterでつぶやこう!


Build Insider賛同企業・団体

Build Insiderは、以下の企業・団体の支援を受けて活動しています(募集概要)。

ゴールドレベル

  • グレープシティ株式会社
  • 日本マイクロソフト株式会社