Nugetでインストールしたパッケージは各ソリューションで共有するのはまずいですか？

Question

初期のままですとソリューションの中にパッケージフォルダが作成されライブラリがインストールされると思います。
この場合ソリューションを作成するごとに同じパッケージがインストールされるので、いくつも同じライブラリが存在することになりなんだか微妙だと思うのです。
そこでこれらのライブラリを共有したいと思っていますが皆さんどうされているんでしょう？

大昔VS6.0を使っていた時は、ライブラリをどこかのフォルダに置いておいて参照していましたがVS2017に変わってちょっと戸惑ってます・・・。

#解決法(09.16)
サイトを参照しVS2017の設定でPackageReferenceに変更。
一度プロジェクト内で使用していたパッケージをアンインストール。
再度インストールするとデフォルトのCドライブからの参照になるようです。
プロジェクト＞参照のアイコンも変わってます。
ソリューション内のpackageはアンインストールしたことでなくなりました。
すっきり！

Answer 1

この場合ソリューションを作成するごとに同じパッケージがインストールされるので、いくつも同じライブラリが存在することになりなんだか微妙だと思うのです。

実はもう解決されていて、VS2017 から PackageReference という新しい方式が使えます。
この方式だと今まで各々の
$(solutiondir)/packages に散らばっていたライブラリが
c:/users/**/.nuget/packages/ に集約されます。
他にもいろいろ使い勝手がいいのでそちらに切り替えるのをおすすめします。

ただし、新方式はサポートしてないというライブラリもありましたので注意してください。（使えなくはなかったですが。）

プロジェクト ファイルのパッケージ参照 (PackageReference)

Visual Studio 2017 での NuGet アップデートが良い感じだった

Comments

[nekome4]

ご回答ありがとうございます。

新しくなった機能の詳細を教えていただきありがとうございました。
こちらのリンクをよく読んで利用を検討してみようと思います。

Answer 2

こんにちは。

まずいかまずくないかと聞かれたら、「好きにすればいい」としか答えられないですが、仮にそういう運用をする場合、Nugetがどういう仕組みで動いていて、どのようなことをやっているのかを深く理解した上で、それでも標準から外れた運用をすることにメリットを見いだしてからやるべきです。
今のNugetは大分こなれてきて、バージョンの管理はもちろん、依存関係の自動解決や自動的な不足パッケージのインストール等、現代的なパッケージマネージャとしての機能を備えていますが、それらを全て自力で解決するということをする明確な意志と決断があればよいです。
その場合、当然ながら一般的なサポートは受けられず、例えばここ(Teratail)みたいな質問回答サイトでも助力を受けることは難しくなります。

個人的な意見ですが、開発環境がWANから断絶しているなど物理的に利用が不可能な場合でなければ、Nugetの管理システムの利用を断念するほどのメリットは全く思いつきません。
さらに言えば、.NETの場合、ビルド時に依存ライブラリはまるっとoutputにコピーされるので、そもそもライブラリのコピーを避けることにつながっていません。
また、VS2017以降では、Nugetのパッケージの内容は共有キャッシュ内に展開されるようになったので、そもそも共有ライブラリとほぼ同等の取り扱いとなります。

もし、今の時代に追いつく意志があるなら、むしろ逆に、「自前のライブラリ群も全てNugetパッケージ化してしまい、ローカル環境に小規模リポジトリを用意し、Nugetのパッケージ管理システムを介してライブラリを利用する」という形態を取ってしまう方法があります(私はそうしています)。
.NETに限らず、ITの世界は文化自体が日々新しくなっており、過去の常識や運用ノウハウは大体通用しないと思っておいた方が良いです。それでも過去にしがみつくのであれば、それこそ好きにすればいいです。

Comments

[nekome4]

詳しく書いていただきありがとうございます。

少し説明不足でした。ライブラリ自体はNugetで管理していくつもりです。そのうえでパッケージのインストール場所(packageフォルダ)をソリューション内ではなく別のドライブやフォルダに変更する(nuget.configファイルでの設定)のはどうなのか(不都合なことなどないか？)ということになります。

何故そうしたいのかという事は他のサイトでも書かれていたので引用します。

＃引用
”同じライブラリーを使うソリューションが複数あった場合には、毎回インストールする必要があります。 同じ dll を何個もシステム上に持つことにもなります。”

同一ソリューション内でいくつもプロジェクトを使えば全く気にならないのですが、ソリューションを複数使うとどうしてもライブラリがいくつも分散してしまいますよね(現状としてはちょっと気になるな～？という程度なんですが）。

なんとなくtamotoさんのおっしゃる通り好きにしたらよいということはよくわかります＾＾；

[tamoto]

すみません、ソリューション内にパッケージを展開する古いNugetの設定や運用にはあまり詳しくなく(覚えておらず)、適切な助言ができていないかもしれません。
しかし、そのような設定をするとなると、標準から異なる運用をする時点で自己責任となり、本来起きえない障害や不具合に悩まされる可能性が高くなるため、個人的にはかなりオススメしませんね。

回答でも書いていますが、2017年以降のNugetシステムでは、まさに質問者さんが考えているとおり、1カ所のグローバルなキャッシュにパッケージを展開しておき、パッケージを指定した際に特定バージョンのdllをリンクするという仕組みに標準でなっているため、こちらを利用できるようにすることを検討した方が良いかもしれません。

もし可能であれば、(旧式のNugetシステムにおいて)nuget.configの設定によって質問者さんの目的を実現できる設定について書かれたドキュメント等へのリンクを頂けないでしょうか。

[nekome4]

ご返信ありがとうございます。

>しかし、そのような設定をするとなると、標準から異なる運用をする時点で自己責任となり、本来起きえない障害や不具合に悩まされる可能性が高くなるため、個人的にはかなりオススメしませんね。

なんでもそうですがやはりおかしなことはやらないほうがいいかもしれませんね。

>2017年以降のNugetシステムでは...
VS2017以降にそれを実現する機能があるとは知りませんでした。
こちらの利用を検討してみようと思います。

>...リンクを頂けないでしょうか。

以下に記載されておりました。
http://bit.ly/2pgCnGJ

[tamoto]

リンク先確認しました。本当に内部設定で展開先を変えるだけのようですね。やはりこれだとNugetのサポートを受けられなくなるので後々困ったことになりそうです。