問題タブ [nuget-update]

アウト ビルド サーバー (TeamCity) のソリューションに nuget パッケージをインストールして更新するビルド ステップがあります。最近、これにより更新が正しく行われなくなりました。これを調査したところ、ナゲットの更新コマンドがソリューション内のすべてのプロジェクトを更新していないことが問題のようであることがわかりました。これをローカル マシンに複製できます。

このコマンドを実行すると:

更新予定の 10 個のプロジェクトのリストを取得します

ただし、ソリューションには 13 のプロジェクトが含まれており、これらすべてにpackages.configファイルが含まれており、私が知る限り、他のプロジェクトと何ら変わりはありません。プロジェクトは単一のプロジェクトであり、そのサブプロジェクトとプロジェクトのディレクトリ構造はプロジェクト名と一致します (したがって、project1.subproject1 は subproject1 が project1 内のフォルダーにあることを意味します)。問題のあるプロジェクトはすべて、次のような特定の名前を持つプロジェクトにあります。

名前のルーティング部分が問題を引き起こす場合 (Resourcesパッケージ名の末尾に単語を使用する前に問題がありました)

すべて同じビルド構成と手順を使用する 50 以上のソリューションがあり、それらすべてで正常に機能します。このソリューションは、正しく更新されていない唯一のソリューションのようです。

なぜこれが当てはまるのか誰にもわかりますか？または、ソリューション内のパッケージを検索するコードが何をしているかを知っている人はいますか? または、この問題を追跡するのに役立つものはありますか?

ファイルを使用してpackages.configNuGet の依存関係を指定する場合、allowedVersions属性を指定して、更新できるバージョンの範囲を定義するSemVer文字列を指定できます。を使用する[]ことで、現在、パッケージを単一のバージョンに効果的に固定できます。例えば：

.net コア プロジェクトではproject.json、NuGet の依存関係を指定する必要があります (短命かもしれません)。NuGet の依存関係をdotnet restore、アプリケーションを新しいバージョンに更新しないようなバージョンに固定するにはどうすればよいですか?パッケージソース？

このnuget ドキュメントの図 #2 は、これが可能であることを暗示していますが、それを行うための構文は提供していません。

- アップデート -

2 つの .net コア クラス ライブラリとローカル ファイル システムをパッケージ リポジトリとして使用して、これをテストしました。という名前のクラス ライブラリを作成し、UpdateMeDependencyLibv1.0.0 としてパッケージ化して、2 番目のプロジェクトから nuget 経由で使用しました。以下は、2 番目のクラス ライブラリを使用する project.json です。UpdateMeDependencyLib

その後、バージョン 1.1.0 に更新UpdateMeDependencyLibして再パッケージ化したため、ローカル システムには v1.0.0 と v1.1.0 の nuget パッケージが存在します。の v1.1.0 を作成した後UpdateMeDependencyLib、次のエクスペリエンスが得られます

• UpdateMeDependencyLib出力 v1.1.0 をその bin ディレクトリに 消費する Visual Studio でプロジェクトをコンパイルする (コンシューマー project.json を変更しない)
  • コンシューマー ライブラリでパッケージの復元を強制すると、Nuget の警告が表示されるようになりました。

そのため、消費ライブラリで「1.0.0」を使用するだけではピン留めされず、NuGet ソースに新しいバージョンが表示されると自動的に更新されます。

packages.configNuGet 用の .NET の古いシステムでは、Package 要素の属性を使用して、パッケージの更新時に考慮されるパッケージの可能なバージョンを制限できました。allowedVersions

update-package上記を含むプロジェクトの Visual Studio 内で を実行すると、属性を使用して 10.0.3 に固定しているため、更新は行われませんNewtonsoft.Json。allowedVersions

でこれを達成するにはどうすればよいPackageReferenceですか? Version 属性にsemver構文を適用すると、復元されたバージョンにのみ影響します。更新は制限されません。したがって、以下を指定してPackageReference実行するupdate-packageと、たとえば、11.0.1 が NuGet リポジトリにある場合、11.0.1 にアップグレードされます。

バックグラウンド

パッケージの更新にはコマンド ライン ツールを使用しています。これは、高速で移動する内部パッケージ (1 日に複数回更新) と、より安定した移動の少ないパッケージ (例: ASP.NET) の両方があるためです。大規模なコードベースでは、ファイル内の各依存関係を手作業で更新すること.csprojは、単純にスケーラブルではありません (そしてエラーが発生しやすくなります)。その下packages.configで、アップグレードしたくないサードパーティのパッケージを「固定」し、最新の急速に変化する依存関係に更新することもできます。

誰かが次のシナリオについて良い考えを持っているかもしれません:

packagename.1.2.0.1000-dev.nupkg のようなプレリリース開発パッケージと、packagename.1.2.0.1.nupkg のようなリリース パッケージがあります。

私の考えは、開発パッケージのより高い番号範囲から開始すると、開発者がナゲット更新ステップでプレリリースオプションを有効にすると、常に開発パッケージを取得できるようになるというものでした。これはうまくいきます。その後、プロジェクトを最新のリリース バージョンに更新したいと思います。しかし、dev/pre-release パッケージよりもバージョン番号が低い最新のリリース バージョンに更新するオプションはないようです。また、ここでは -Safe オプションが機能しないようです。

これらは異なるビルドであるため、ビルド番号も同期できません。逆に、リリース バージョンのビルド番号が高い場合、プレリリース パッケージを含めても、通常の nuget 更新を行っても、最新の開発パッケージに更新されることはありません...

ここにアイデアはありますか？

どうもありがとう！