消費者と一緒にNuGetパッケージを開発するためのベストプラクティス？
私は主に、複数のWebアプリケーションで使用されるデータアクセスおよびユーティリティ機能用のNuGetパッケージを作成していますが、NuGetパッケージの開発を推進する1つのメインWebアプリケーションがあります。そのため、同じマシンでNuGetパッケージと一緒にそのWebアプリケーションを開発したいので、必要なパッケージ機能を簡単に追加して、すぐにWebアプリケーションでテストできます。
ただし、NuGetパッケージを公開する必要があり、いくつかの機能を追加してテストしたい場合は常に最新バージョンをプルダウンする必要があるため、これには厄介なオーバーヘッドがあります。それが適切に機能しない場合は、修正してこの手順を再度実行する必要があります。
NuGetパッケージをパッケージのコンシューマーと一緒に簡単に開発できるようにするためのベストプラクティスはありますか？パッケージソリューションでDLLを共通ディレクトリに出力し、コンシューマーでDLLへの直接参照を追加することもできますが、これはチェックインしてはならない一時的な参照であるため、物事を行うには悪い方法のようです。 NuGetパッケージプロジェクトを、このメインのWebアプリケーションと同じソリューションに配置し、それを使用するのが適切ですが、NuGetパッケージ参照ではなくプロジェクト参照を使用しますか？
NuGetには、ファイルシステムの場所を指定する機能があります。このディレクトリをローカルリポジトリとして扱います。開発サイクル中にここに公開します。
MSBuildファイルのパッケージ化プロセスを自動化することもできます。クライアントをテストできるように、ローカルリポジトリを更新するたびにGUIを手動で操作する必要はありません。
「ベストプラクティス」は、nugetパッケージを単独で開発することであり、デバッグせずに使用できることを確認する十分なテストを行うことです。
しかし、私はあなたが何を意味するのか知っています。一般的な回避策は、開発中にプロジェクトを参照し、安定したらパッケージに切り替えることです。
A.b.c.d-prereleaseバージョンを公開および参照できることを忘れないでください。