10

ソリューション ファイルに 20 個のプロジェクトがあります。プロジェクトの 1 つは、すべてのプロジェクトが参照する標準ライブラリ プロジェクトです。

約 1 年前、新しい nuget パッケージを追加しました。これをPackage Aバージョン 5.0.0.0 と呼びます。コンパイル時に転送されるファイルがたくさんありましたが、最終的には対処しました。パッケージを標準ライブラリ プロジェクト (他の 19 が参照するプロジェクト) に追加しました。

私はNugetを初めて使用するので（おそらく何か間違ったことをしたのかもしれません）、のヘルパーとして機能する新しいパッケージを作成しましたPackage A。ヘルパーがバージョン 3.0.0.0 から 5.0.0.0 に依存するようにすべてを設定しましたPackage A(したがって、私たちよりも低いバージョンの他のユーザーでも機能します)。この新しいパッケージを呼び出しましょうPackage A helper

インストールするPackage A helperと、すべてが正常に機能しています。プル リクエストを実行すると、ソリューション内のすべての app.config が

<runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <dependentAssembly>
                      <assemblyIdentity name="Package.A" publicKeyToken="8FC3CCAD86" culture="neutral"/>
                      <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0"/>
              </dependentAssembly>
      </assemblyBinding>
</runtime>

それがなくても問題なくコンパイルされますが、ビジュアルスタジオは不平を言って警告を出します。何を与える？私のマネージャーは、app.config にあまりにも多くのノイズを追加し、パッケージ A に依存しすぎているため、コードをマージすることを許可しません。

インストールする前に主な依存関係が既に満たされているのに、依存する nuget パッケージを追加すると、Package Aこの新しい bindingRedirect が必要になるのはPackage A Helperなぜですか?

そして、ナゲットパッケージとpackage.configで3.0.0.0-5.0.0.0を指定したときに、なぜ0.0.0.0-5.0.0.0と言うのですか

アップデート：

Package A helperバージョン 5.0.0.0 への参照を使用してビルドするとPackage A、すべての bindingRedirects がすべての app.config で自動入力されず、代わりに警告が生成されます。最小の依存関係でビルドするのが最善だと考えたので、最初は 3.0.0.0 でビルドしました。Visual Studio は依然として警告を発し、bindingRedirects が作成されることを示唆しているため、問題は依然として存在します。

No way to resolve conflict between "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" and "Package A, Version=3.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33". Choosing "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" arbitrarily.
Consider app.config remapping of assembly "Package A, Culture=neutral, PublicKeyToken=83hfhsd33" from Version "3.0.0.0" [] to Version "5.0.0.0" [path to Package A dll] to solve conflict and get rid of warning.

私のnugetパッケージの依存関係を3.0.0.0から5.0.0.0に変更し、5.0.0.0を許可して私のpackages.configを取り除くだけの解決策allowedVersions="[3,6)"ですか? nuget パッケージの有用性と下位互換性を低下させたくありませんが、同時に、メイン ソリューションに必要な警告や bindingRedirects を必要としません。

更新 2:Copy Local参照プロパティを設定してFalse実際に問題を解決しましたが、その理由がわかりません。

4

1 に答える 1

7

私は最初に3.0.0.0でそれを構築しました.それが最善だと思ったからです...

そこから問題が始まりました。あなたのソリューションは現在、A.dll の2 つの異なるバージョンに依存しており、一方が他方を上書きします。最終的に bin\Debug にコピーされる A.dll のバージョンはランダムです。最後にビルドされたプロジェクト。

これは良い結末になることはできません。解決策は実行に失敗する運命にあります。どちらかが A-helper.dll のコードである場合、バージョン 5.0.0.0 がコピーされると失敗します。または、A.dll を使用する他のプロジェクトのコードであり、バージョン 3.0.0.0 がコピーされると失敗します。最終結果は、ソリューションが常に失敗するということです。

つまり、ビルドシステムがそれについて何かをしているのを見ています。不一致に気付き、勝つバージョンの 1 つを選択します。5.0.0.0 が選択されましたが、これは正しい選択でした。また、app.configを変更し、bindingRedirect を追加して、3.0.0.0 バージョンのロードを要求するコードが実際に 5.0.0.0 を取得するようにします。バージョン 5 をバージョン 3 と十分に互換性があるようにすれば、これは機能する可能性があります。そうでない場合でも、通常、メジャー バージョン番号が 2 つ増えると問題が発生します。検査したらわかります。

したがって、参照プロパティの Copy Local を False に設定すると、実際に問題が解決しました

それは問題を解決しませんでした。ビルドシステムがこの問題を解決する必要があると想定するのを妨げただけです。DLL をコピーする必要がなくなったため、両方のバージョンが共存できるようにアセンブリを GAC にインストールすると推測されます。開発マシンでそうするのは一般的ではなく、一般的に非常に賢明ではありません。追加のインストール手順を考えると、上司や​​チーム メンバーがこのソリューションを気に入る可能性はほとんどありません。

したがって、次の 2 つの基本的なことができます。

  • ビルドシステムにこれを整理させてください。そのように、問題は正しく解決され、ソリューションは機能します。バージョン 5 がバージョン 3 と十分に互換性がある場合、A-helper.dll のコードは正しく実行されます。上司がそれを気に入らない場合は、もちろんこれをスクラッチして実行する必要があります。

  • A-helper プロジェクトの参照を A バージョン 5.0.0.0 に変更します。現在、非互換性はなくなり、唯一無二の A.dll がすべてのコードに適しています。あなたの要件を考えると、これが上司が好む唯一の解決策です。

于 2016-04-03T11:02:22.040 に答える