お品書き

• .NET Core におけるローカルでのパッケージの使い方。
• コマンドのちょっとした説明。
• 本題(参照とかがどうなってるのか)。

.NET Core におけるローカルでのnugetパッケージの使い方。

パッケージ、作っておくと何かと楽ですよね。dllの直接参照なんて嫌です。
nuget.orgにアップロードしておくとなんも考えないでいいのですが、まぁpublicな場所にupできない場合って結構あると思います。
じゃぁローカルのパッケージに作ったパッケージどうやって使うのというとそれはstack overflow
に書いてあるとおり、

の一連のコマンドを実行すればとりあえずパケージを参照することはできるようになります。

上のコマンド何やってるか一応。

コマンドが何をやっているか、雑に書いておきます。
まずはじめにclasslibなどの.csprojなどがあるところで

とかでpackします。すると

/bin以下に.nugetファイルが出来上がります。(こいつは実際のところただのzipで、unzipするとdllとか必要な情報が入ったものが出てきます。)
でこいつを直接dotnet add packageとかで参照しようとしてもそれはできません。ここらへんはパッケージをよしなに参照してもらうために

などとして、packagesディレクトリ内に参照する際のディレクトリ形式を整備してもらったり、必要なファイルを生成してもらったりします。
このディレクトリを参照するべく、参照したい側のプロジェクトで

とするとめでたくパッケージが使えるようになるわけです。

本題

ようやく本題です。

というコマンドを売ったときどういうふうに参照されるようになっているのかが気になるポイントです(私は気になった).
このコマンドを叩くと、csprojには以下のようにPackageReferenceが追加されます。

このPackageReference、別に先程addしたパッケージの直接の参照を持っていなさそうです。直接参照しているなら、なんらかの形でパッケージのパスを書き込まれていそうなものです。が、実際に書き込まれたのは名前とバージョン情報だけです。
試しに、雑に先程packしたプロジェクトに関数を追加し、もう一度pack,nuget addしてみて、dotnet add packageした側のプロジェクトでclasslib側に追加した関数を呼んでみると、そんな関数ないぞ！とコンパイラさんに怒られます。
やはり直接参照はしていなさそうです。
コンソールアプリだと、.csprojとMainのあるProgram.csしかありませんし、そこに対した情報がないことはわかったので、そこでちゃんとdotnet add packageがちゃんとできて、ビルドが通った場合のbin以下を覗いてみます。()

するとPackTest.runtimeconfig.dev.jsonに

とか書いてるものがあります(環境はMac,nenoは私のユーザ名)。"additionalProbingPaths"。
完全に名前がそれっぽいですね。
参照先はここっぽい。"/Users/neno/.nuget/packages"を覗いてみると、先程packしたMyPackage.nugetが存在することがなんと確認できます。パッケージを追加したとき、どうやらここを参照していそうです。
しかし、いつの間に.nuget/以下に配置されたのでしょうか。。。
それは

でパッケージを追加したタイミングで、.nuget/以下に配置され、そこから参照するようになるようです。

まとめ

すると、しれっと.nuget/配下にパッケージが配置されて、そこから参照されるようになるらしい。決してプロジェクトがあるディレクトリにコピーとかされたりしないし、パスで直接パッケージの参照を持ったりしない。