本サイトからスピンオフした姉妹サイトです。Coreの基礎から開発実践までが学べる入門連載。Standardなクラスライブラリなプロジェクトを作成し、別のコンソールプロジェクトから参照する方法を説明する。今回はクラスライブラリプロジェクトを作成し、そのプロジェクトを参照するコンソールプロジェクトを作成する。2つのプロジェクトをまとめるソリューションも作成する。リスト1の一連のコマンドを実行し、ソリューションの作成、プロジェクトの作成、プロジェクトのソリューションへの追加を行ってほしい。ソリューションとクラスライブラリとコンソールプロジェクトを作成し、プロジェクトをソリューションに追加するコマンドなお、これ以降のシェル上でのコマンド実行は、リスト1実行後のカレントディレクトリである、ソリューションファイルが配置されているディレクトリを基準に全て実行してある。カレントディレクトリの移動が必要な場合は、最初にcdコマンドで移動している。classlibで指定しているclasslibというのがデフォルトで用意されているクラスライブラリプロジェクトのテンプレートだ。作られたクラスライブラリプロジェクトにはClass1.csと<プロジェクト名>.csprojの2つのファイルが存在しているはずである。Class1.csは適宜リネームや削除して必要なクラスファイルを追加すればよいが、まず<プロジェクト名>.csprojファイルの中身を見てみよう。デフォルトのテンプレートで生成されたクラスライブラリプロジェクトの.csprojファイルXMLの<Project>要素は、前回説明したコンソールプロジェクトと同じである。前回のリスト2と見比べると、<PropertyGroup>の子要素の<OutputType>要素がなくなり、<TargetFramework>要素がnetstandard2.0となっているところが違う要素である。2.0以降のみから参照できるライブラリとして開発するのであれば、この<TargetFramework>要素をnetcoreapp2.0に変更することもできる。Frameworkをはじめ、Xamarinの各プラットフォームやUWPといったプロジェクトからも参照できるクラスライブラリになり汎用性が増す。2.0向けのライブラリとしてまず開発する場合、ほとんどのケースでnetstandard2.0として問題がないため、クラスライブラリプロジェクトの<TargetFramework>はnetstandard2.0を指定して開発を進めていくことを強くお勧めする。Standardのバージョンを指定することをお勧めする。2.0とは」の項で説明する。Frameworkという単一実装のみで動いていた。Frameworkの実装で動くことが確実だった。Phoneなのか)によってサポートするAPIに違いが生じてきた。確かに違いはあるものの、共通部分も多くあるため、「プラットフォームの差異による影響を受けない特殊なクラスライブラリを利用することで、共通部分は同じソースコードで動かしたい」という要望から、プロファイルベースのポータブル・クラス・ライブリ(PCL)という仕組みが生まれた。PCLにも課題が生じてきている。具体的には、PCLはお互いのプラットフォームがサポートするAPIの共通部分という形を採っていたため、組み合わせが増えるとより複雑なサポートAPIの管理が必要になってきたのだ。(iOS/macOS/Android)UWPなど広範囲に及ぶようになった。Standardという仕組みを新たに導入するに至った。Standardは、「それぞれの.NET実装が実装すべきAPI群をあらかじめ決めておき、各プラットフォームでの動作をサポートする.NET実装が実際にそのAPIを実装してサポートする」という仕組みになっている。Standardのバージョンを決めておくことで、クラスライブラリを開発するときは、サポートされるAPIのみを参照して開発できる。Standardに対応している全ての.NET実装で参照できる。Standardのバージョンごとにサポートする.NET実装は、公式ドキュメントの表を参照してほしい(参考:表1に執筆時点のものを引用転載している)。Standardのバージョンを確認してみよう。2.0に関して、表1の黄色の背景色で示した部分を見てほしい。2.0(netstandard2.0)をターゲットとするクラスライブラリを参照できることが分かる。1.0に関して、黄色の背景色の左側にある列を見ほしい。1.6およびそれより小さいバージョン(1.5/1.4/1.3/1.2/1.1/1)をターゲットとするクラスライブラリを参照できることが分かる。Standardのバージョンから、それを実装している各.NET実装のバージョンを確認してみよう(先ほどとは逆の視点になる)。表1の緑色の背景色で示した部分を見てほしい。Frameworkだと4.6.1と比較的新しいバージョンにしないといけない。他の.NET実装も同様に最新バージョンが必要になる。2.0と指定するしかないだろう。Standardで開発可能な場合は、小さいバージョンを指定しておいた方が、そのクラスライブラリを利用できるプラットフォームが多くなるわけである。2.0を指定するよりも幅広いバージョンとプラットフォームで利用できるようになる。Standardのバージョンを指定することをお勧めする」理由だ。Standardのバージョンをターゲットとすることもできる。Standard向けのバイナリを出力できる。この方法については最後の方の節で紹介する。クラスライブラリプロジェクトの作成それでは実際にクラスライブラリプロジェクトを作成してみよう。クラスライブラリプロジェクトは、コンソールプロジェクトと違い、エントリポイントとなるMainメソッドを持たない。他のプロジェクトがクラスライブラリを参照して、そのライブラリ内のクラスを利用できるようにするために、publicなクラスとメソッドを定義する。今回は、Class1.csファイルをいったん削除し、MyStringLib.csというファイルを作成し、リスト3のようにコードを定義する。編集後、リスト4の1つ目のdotnetコマンドでクラスライブラリプロジェクトをビルドすると、bin/Debug/netcoreapp2.0フォルダーにExample4.ConsoleApp.dllというバイナリファイルが生成される。配置用に発行したい場合は、2つ目のdotnetコマンドを実行するとbin/Debug/netcoreapp2.0/publishフォルダー以下に生成されることが確認できる。次に、このクラスライブラリプロジェクトをコンソールプロジェクトから参照してみよう。リスト5のコマンドを実行すると、コンソールプロジェクトからクラスライブラリプロジェクトへの参照が追加される。プロジェクト参照を追加するコマンドこのコマンドは、リスト6のような<ItemGroup>要素を、.csprojファイルに追加している。実際にリスト5のコマンドを実行した後に.csprojファイルを見ると確認できる。.csprojファイルを直接編集してこの要素を追加することでも、参照を追加できる。コンソールプロジェクト側のソースコードからクラスライブラリ側のメソッドを呼び出すコードを、リスト7のように追加した。コンソール側からクラスライブラリ側のメソッドを呼び出すリスト8のようにコマンドを実行すると、コンソールプロジェクトを実行できる。コマンド出力を見ると分かるように、クラスライブラリプロジェクトをビルドした後、コンソールプロジェクトをビルドしている。あるプロジェクトをビルドするためには、プロジェクト参照している全てのプロジェクトを先にビルドしないといけないため、プロジェクトを相互参照することはできない。コンソールプロジェクトのビルドまたリスト9のようにコンソールプロジェクトを発行すると、参照しているクラスライブラリプロジェクトの.dllバイナリファイルがbin/Debug/netcoreapp2.0/publishフォルダーの下に一緒に生成されていることも分かる。これは参照しているライブラリを全て一緒の場所に配置するためである。1.0~1.6の間のいずれかを単一のターゲットとするクラスライブラリを作成すればよい。Standardもターゲットとして追加したい」というケースもあるだろう。本章では、その実現方法を解説する。1.0のコンソールプロジェクトから参照しようとするところから始めてみよう(※前述したバージョンの組み合わせを考えると、これは当然エラーになるが、実際にエラーになる点を確認してみる)。1.0のコンソールプロジェクトを作成する。1.0が必要なので、実際に実行したい場合は連載第1回の記事などを参考にインストールしてほしい。1.0と2.0(および1.1や今後リリースが予定されるそれ以外のバージョンも含む)はインストール先のパスを変えておけば共存が可能である。1.0の実行コマンドである。リスト10のコマンドでコンソールプロジェクトを作成した後、Example4.ConsoleApp.NetCoreApp10/Example4.ConsoleApp.NetCoreApp10.csprojファイルを直接編集して<TargetFramework>要素をnetcoreapp1.0に変更してほしい。2.0のときと同様にリスト11のコマンドでクラスライブラリをプロジェクト参照として追加してみると、エラーが発生した。dotnetコマンドによるプロジェクト参照の追加は、ターゲットフレームワークに互換性がない場合、エラーが出て追加できないようになっている。.csprojファイルを直接編集して追加した場合は、ビルド時にエラーが発生する。1.0をクラスライブラリプロジェクトのターゲットに追加してみよう。1.0で実行できるコードに切り替えるためである。ターゲットを複数指定する方法は連載第2回でやったように.csprojファイルをリスト12のように編集して、<TargetFramework>要素から<TargetFrameworks>要素に変更すればよい。2.0のdotnetコマンドを使って、このコードをビルドしてみよう。リスト13のようにエラーが発生するはずだ。2.0向けのビルドは成功している。2.0で追加されたAPIであるからだ。2.0以外をターゲットフレームワークとしてビルドしたときは)同等の処理を行う別のコードに切り替えるようにしてみよう(リスト14)。Coreのドキュメントに記載がある。ifディレクティブによる、ターゲットフレームワークごとの処理の切り替え(抜粋)再度ビルドすると、今度は両方のターゲットフレームワークでビルドが成功するはずだ。1.0のコンソールプロジェクトにこのクラスライブラリをプロジェクト参照として追加できるはずだ。1.0のコンソールプロジェクトにクラスライブラリのメソッドを呼び出す処理を追加できるようになる。2.0をターゲットとして作成し、プロジェクト参照としてコンソールプロジェクトに追加する方法を説明した。複数ターゲットをクラスライブラリに指定する方法を紹介した。プロジェクト参照は参照される側のソースコードが必要であり、全てをビルドし直さないといけないなど制約も多い。そこで次回は、今回作成したクラスライブラリプロジェクトをパッケージングし、nuget.orgにアップロードし、コンソールプロジェクトの参照をNuGet経由に変更してみる予定である。※以下では、本稿の前後を合わせて5回分(第3回~第7回)のみ表示しています。INDEX]を参照してください。Coreの基礎から開発実践までが学べる入門連載。Codeを使って開発するフローを説明する。Coreの基礎から開発実践までが学べる入門連載。4回目は作成したコンソールアプリのプロジェクトをビルドして配置する手順を説明する。Coreの基礎から開発実践までが学べる入門連載。Standardなクラスライブラリなプロジェクトを作成し、別のコンソールプロジェクトから参照する方法を説明する。Coreの基礎から開発実践までが学べる入門連載。6回目はクラスライブラリプロジェクトをNuGetパッケージとして参照できるように、作成と発行を行う。Coreの基礎から開発実践までが学べる入門連載。最終回は単体テスト用のプロジェクトを作成して、テストを行う方法を説明する。機械学習エンジニアを目指す人~初中級者のための技術情報サイトです。「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。開発者のためのSlackチーム、作りました:「機械学習&AI」「クラウド&ビッグデータ」「IoTデバイス」のネット記事情報を共有中。2020最適なビューへの切り替えを推奨します:スマートフォン用表示に。