5

私たちは、内部で構築されたパッケージとサードパーティのパッケージの両方で、NuGet の熱心なユーザーです。

最近、一部のビルド プロジェクトで NuGet パッケージの復元オプションを有効にして、ソース管理にコミットするバイナリ ファイルの量を減らし始めましたが、問題に直面しています。

Visual Studio の起動に非常に長い時間がかかり、一度起動すると (30 分以上かかる場合があります)、その後のビルドにも同様に時間がかかります。これが発生している間、プロセス エクスプローラーで多くの子 NuGet プロセスが表示されたり停止したりするのを確認できます。

packages.config ファイルで参照されているパッケージのバージョンが、構成されたパッケージ ソースのいずれからも利用できない場合 (おそらく、内部パッケージの古いバージョンであり、誰かがローカル リポジトリをクリーンアップしてくれている可能性があります) を発見しました。 、NuGet と Visual Studio がある種の無限 (または少なくとも実行時間の長い) 再試行ループに入るように見えます。

コマンド ラインから NuGet インストール コマンドを実行すると、エラーが返されます。

>.nuget\NuGet.exe install project\packages.config -o packages
Unable to find version '1.0.0.1' of package 'my.internal.package'.

しかし、これは Visual Studio/NuGet によって正しく消費されていないようです。

  • NuGet はそのアクションをどこかに記録しますか?
  • NuGet の復元の再試行またはタイムアウトを制限できますか (おそらくnuget.targetsファイルで?)
  • NuGet のセマンティック バージョニングが使用されていないように見えます。上記のシナリオでは 1.0.0.2 がレポから入手できるため、これを有効にできますか?
4

2 に答える 2

2

これはこの問題に似ているようですhttp://nuget.codeplex.com/workitem/2970 一時的な回避策は、nuget.targets を開いて
<!-- アセンブリ解決前にパッケージが復元されていることを確認する必要があります -- >
<ResolveReferencesDependsOn Condition="$(RestorePackages) == 'true'">
RestorePackages;
$(ResolveReferencesDependsOn);
</ResolveReferencesDependsOn>
で

<BuildDependsOn Condition="$( RestorePackages) == 'true'">
RestorePackages;
$(BuildDependsOn);
</BuildDependsOn>

VS でソリューションを閉じてリロードします。これにより、ビルドがアセンブリ解決ではなく復元パッケージに依存するようになり、問題が解決したようです。

お役に立てれば。

于 2013-01-29T07:17:35.063 に答える
0

まず、バージョン管理がnugetの推奨事項（1.2.3）に準拠していません。したがって、バージョンを1.0.1に上げて、問題が解決するかどうかを確認する必要があります。

  • NuGetはそのアクションをどこかに記録しますか？

コマンドライン「nugetinstall」で-verbosityフラグを使用して、追加情報を取得できます。詳細は出力ウィンドウでも確認できます。ドロップダウンから「パッケージマネージャー」を選択します。詳細については、devenv/logを使用してください

  • NuGetの復元の再試行またはタイムアウトを制限できますか（おそらくnuget.targetsファイルにありますか？）

ここではどうしようもない。

  • 上記のシナリオでは1.0.0.2がリポジトリから利用できるため、NuGetのセマンティックバージョニングが使用されていないように見えますが、これを有効にできますか？

これは、ツール->オプション->パッケージマネージャーで「アップグレードを自動的にチェックする」をチェックすることで達成できますか？packages.configがバージョンを1.0.0.1に制限しているかどうかを確認します

于 2013-02-04T11:13:43.700 に答える