web-dev-qa-db-ja.com

参照DLLファイルが展開プロジェクトのビンにコピーされず、エラーが発生する

Webアプリケーションプロジェクトで参照されているいくつかの外部DLLファイルがあります。ホスティングサーバーにインストールするための展開プロジェクトがあります。NET3.5およびVisual Studio 2008を使用していた場合、DLLファイルはbinフォルダーにコピーされていました。NET4およびVisual Studio 2010にアップグレードしたため、これは発生しなくなり、参照が見つからないためサーバーエラーが発生します。

CopyLocalがtrueに設定されており、web.config内で他の場所に設定されていることを示唆するものを見つけることができません。

visual-studio-2010web-deployment-project
59
g.foley

Visual Studio 2010にはバグがあります。デフォルトでは、ソリューションファイルのXMLは次のようになります。

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>

MSBuildはこれを以下に期待しているので、DLLファイルは展開に含まれます：

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>

トリックは、Copy LocalをFalseに設定し、プロジェクトを保存してから、True-再度保存にリセットすることです。これには、MSBuildが尊重するプライベートノードが正しく含まれます。

Visual Studio 2010に含まれるプライベートノード（Copy Local）のデフォルトはTrueであるように見えますが、MSBuildはその欠落ノードをFalseとして読み取ります。

102
Rebecca

私は同じ問題を抱えていたので、「BeforeBuild」ステップを追加するのではなく、単にこれを行うテストを作成しました

    [TestMethod]
    public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
    {
        Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
    }

そして、それはエラーを修正しました「Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler ...」タイプは解決できません

3
stevie_c

私の展開プロジェクトに奇妙なことが起こりました。依存関係が検出されていないことがわかったとき、プライマリ出力を削除して再追加しました。

これで、依存関係が表示され、インストール時にbinフォルダーに配置されます。

2
g.foley

私はまったく同じ問題を抱えていました。 EnterpriseLibraryを参照するVisual Studio 2008プロジェクトがあります。 TFSとWeb展開プロジェクトを使用して統合ビルドを実行すると、すべてのDLLファイルがコピーされます。 Visual Studio 2010、TFS 2010、およびWDP 2010にアップグレードしたとき、いくつかのDLLファイルが見つかりませんでした。奇妙なことに、これは一部のDLLファイルでのみ発生し、他のファイルでは発生しません。

たとえば、Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dllは両方のケースでコピーされますが、Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dllはコピーされません。

回避策として、「BeforeBuild」ステップを使用してファイルをコピーしました。

今では正常にビルドされているようです。

1
Patrick Magee

私はちょうど同じ問題を抱えていて、誰かを助けるかもしれないので見つけたものを共有したかった：

私の場合の理由は、サードパーティアプリケーションのインストール中にアセンブリがGACにインストールされたためです。

DLLファイルがGACにある場合、コンパイラは、[プライベート]ノードを使用して[ローカルにコピー]を指定しない限り、目的のフォルダーにコピーすることはありません。 Juntoが言及したプロジェクトファイル。

問題は、そのノードを追加せずに、あるマシンで開発して別のマシンでビルドし、DLLファイルがビルドマシンのGACのみにある場合、プライベートノードを使用しないデフォルトの動作により、ファイルは開発マシンに正しくコピーされますが、ビルドマシンにはコピーされません。

より大きな問題は、DLLファイルが直接参照されていないが、プロジェクトがDLLファイルを参照する2番目のプロジェクトを参照している場合です。その場合、 DLLファイルはプロジェクトによって「ローカルにコピー」されるようにマークすることはできません。これは参照されないためです。したがって、DLLファイルがGAC-出力フォルダーにコピーされません。

この場合に考えられる解決策は次のとおりです。

  • GACからDLLファイルをアンインストールします
  • 最終プロジェクトのDLLファイルへの直接参照を追加します。
  • 新しい厳密な名前でDLLファイルに再署名します。これにより、GACのDLLファイルと区別されます。
1
rzen

VS 2012 Expressでも同様の問題がありました。プロジェクトでTesseractライブラリを使用しました。複数のプロジェクトがあるソリューションでこのプロジェクトを使用するまで、すべてがうまく機能しました。問題は、通常bin/debug/x86またはbin/debug/x64フォルダーに置かれている一部のDLL（liblept168.dll、libtesseract302.dll）が、ソリューション全体を再構築したときにのみコピーされることでした。 1行を変更して再度ビルドすると、DLLが削除され、コピーされません。

不足しているDLLを作成するプロジェクトの参照をスタートアッププロジェクトに追加することで、この問題を解決しました。

0
chviLadislav

プロジェクトがライブラリを直接ロードしない場合、明示的に参照されていても、常にデプロイされるとは限りません！ローカルのBinディレクトリで見ることができたが、デプロイされたときではなかったため、混乱しました。 Binディレクトリ内のdllは、Clean中に削除されなかった古いファイルであったため、混乱しました。

完全にクリーンアップして再構築しましたが、ローカルのBinフォルダーにも問題はありませんでした（web.configでのみ使用しています）。次に、プロジェクトでdllファイル自体を参照し、出力にコピーするように設定して、展開されるようにしました。

0
Lukos

rzenと他の人、ありがとう-あなたのコメントは私たちのための解決策につながりました。

Microsoft.ReportViewer.Common.dllおよびMicrosoft.ReportViewer.WebForms.dllアセンブリのバージョン10をターゲットとするプロジェクトがあります（「src」レベルで作成した個別の「libs」フォルダー）。しかし、ビルドを行ったときの出力には、ビルドサーバーに最近インストールされたバージョン12が含まれていました。

ここでコメントを使用して、 'Copy Local'がTrueに設定され、フラグがプロジェクトファイルで設定されていることを確認しました。ただし、まだバージョン12を展開していました。そのため、このトリックの目的は、「特定のバージョン」プロパティが2つの参照にも設定されていることを確認することでした。これで、各ファイルのバージョン10がデプロイされました！

多くの喜びがありました。

JH

0
John H

参照されるDLL=ファイルをbinディレクトリにコピーしないように<Private>False</Private>を使用できます。これは、別のTFSビルドサーバーでアプリケーションをビルドするときに便利です。 DLLファイルをbinディレクトリにコピーしないで、アプリケーションをビルドする必要があります。

0
jrapolu

Visual Studio 2008でどのようにセットアップされたかはわかりませんが、Post-Buildイベントコマンドラインを使用している可能性があることはほぼ間違いありません。そこに、デプロイメントに必要なDLLファイルをコピーするように指示できます。以下に例を示します。

mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll" 
$(SolutionDir)\Deployment\
0
VoodooChild

私も、参照されたdllが公開フォルダーのビンにコピーされないという同様の問題に遭遇しました。アプリケーションにbinフォルダーを含まないTFSチェックアウトコピーを使用していました。 -> binフォルダを含めました。 ->参照アプリケーションの構築-> Webサイトプロジェクトの公開これで、公開フォルダー内のすべての参照dllがbinに表示されます

0
user4869201

同じ問題に出会うことはできませんでしたが、似ています。参照がコピーされないWPFメインプロジェクトと参照プロジェクトがありました。私の場合、メインプロジェクトはNET 4.0クライアントプロファイル用に設定され、NET 3.5用に参照されていることがわかりました。メインプロジェクトを3.5に設定すると、参照プロジェクトのコンパイル済みDLLがコピーを開始しました。 （練習で解決したので、理由はわかりません）

0
Bronek

DLLファイルが参照されているプロジェクトのフレームワークを確認してください。フレームワークは.NET 4.0である必要があります。フレームワークがクラ​​イアントプロファイルの場合は修正してください。

0
Siddharth Sharma