web-dev-qa-db-ja.com

依存DLLがVisual Studioのビルド出力フォルダーにコピーされません

私はビジュアルスタジオソリューションを持っています。私はそのソリューションにたくさんのプロジェクトがあります。スタートアップとして機能し、他のプロジェクトを使用するメインプロジェクトが1つあります。 "ProjectX"というプロジェクトが1つあります。その参照はメインプロジェクトに追加されます。 ProjectXはソリューションの一部ではない別の.NET DLL（例えばabc.dll）を参照します。

今、このabc.dllはメインプロジェクトのbin/debugフォルダにコピーされるべきですが、そこにはコピーされていません。コピーされないのはなぜですか、既知の理由は何ですか？

c#.netvisual-studio-2010dllreference
160
Brij

ProjectXがabc.dllを参照しているのにabc.dllで定義されている型を直接使用していない場合、abc.dllはメイン出力フォルダにコピーされないことがわかりました。 （混乱を招くため、ProjectXの出力フォルダにコピーしてください。）

したがって、ProjectXのどこかでabc.dllの型を明示的に使用していない場合は、ProjectXのいずれかのファイルのどこかにダミーの宣言を配置します。

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

すべてのクラスに対してこれを行う必要はありません - DLLコピーを作成するのに一度だけで十分であり、すべてが期待通りに動作します。

補遺：これはデバッグモードでは動作するかもしれませんが、リリースでは動作しません。詳細は@ nvirthの回答を見てください。

98
Overlord Zurg

Overlord Zurgの答えに対する単なる補足です。

私はこのようにダミー参照を追加しました、そしてそれはデバッグモードで働きました：

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

しかし、リリースモードでは、依存DLLはまだコピーされませんでした。
これはうまくいきました：

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

この情報は実際に私が理解するのに何時間も費やしたので、私はそれを共有すると思いました。

53
nvirth

はい、Copy Localをtrueに設定する必要があります。しかし、私はかなり確信していますメインのプロジェクトからそのアセンブリを参照し、Copy Localをtrueに設定する必要があります。依存アセンブリからコピーされるだけではありません。

Referencesの下のアセンブリをクリックしてF4を押すと、Copy Localプロパティに移動できます。

48
Mike Perrenoud

アセンブリ属性にすると滑らかに見えます。

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

使い方は次のようになります。

[Assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]
27
Arie R

これと同じ問題に遭遇した。背景情報：構築する前に、新しいProject Xをソリューションに追加しました。プロジェクトYはプロジェクトXに依存し、プロジェクトA、B、CはプロジェクトYに依存しました。

ビルドエラーは、プロジェクトA、B、C、Y、およびX DLLが見つからなかったことでした。

根本的な原因は、新しく作成されたProject Xが.NET 4.5をターゲットにし、残りのソリューションプロジェクトが.NET 4.5.1をターゲットにしたことです。 Project Xがビルドされず、残りのプロジェクトもビルドされない。

新しく追加されたプロジェクトが、他のソリューションと同じ.NETバージョンをターゲットにしていることを確認してください。

21
Darren Alfonso

これで効果があるかどうかはわかりませんが、私にとってはDLLを参照することがよくあります（もちろん自動的にbinフォルダに追加されます）。ただし、DLLには追加のDLLが必要になる場合があります（使用している機能によって異なります）。それらは単に私が実際に使用しているDLLと同じフォルダーに入るだけでよいので、私は私のプロジェクトでそれらを参照したくはありません。

これはVisual Studioで「既存のファイルを追加する」ことによって実現します。 Add_dataフォルダ以外の場所に追加できるはずです。個人的にはルートに追加するだけです。

それからそのファイルのプロパティを...に変更します。

Build Action = None（これをContentのようなものに設定すると、実際には "root"バージョンがrootにコピーされ、さらにBinにコピーされます）。

出力フォルダにコピー=新しい場合はコピー（基本的には、見つからない場合にのみBINフォルダに入れますが、それ以降は行いません）

私が公開すると..追加されたDLLはBINフォルダにしか存在せず、他の場所には発行場所には存在しません（これが私の望むものです）。

16
da_jokker

探しているDLLがGACに含まれていないことを確認することもできます。ビルドマシンのGACにファイルが既に存在する場合、Visual Studioはそれらのファイルをコピーしないことを賢明に考えています。

私は最近GACにアセンブリが存在する必要があるSSISパッケージをテストしていたこの状況で走りました。私はそれ以来忘れていたし、なぜこれらのDLLがビルド中に出てこなかったのか疑問に思いました。

GACの内容を確認するには（Visual Studio開発者コマンドプロンプトから）：

gacutil -l

読みやすくするためにファイルに出力します。

gacutil -l > output.txt
notepad.exe output.txt

アセンブリを削除するには

gacutil -u MyProjectAssemblyName

GACからファイルを削除すると、ビルド後に\ binディレクトリに正しく出力されたことにも注意してください（ルートプロジェクトで直接参照されていないアセンブリでも））これはVisual Studio上にあります。 2013年アップデート5

10
Brett

これはnvirthの例を少し微調整したものです

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}
2
maca134

私の場合は、私が賛成できないTFS/VSのデフォルトの振る舞いが原因で、これは最も愚かなことでした。

メインプロジェクトへの参照としてdllを追加することはうまくいきませんでしたので、私はCopy Local = Alwaysを使用して "Existing Item"として追加することにしました。それでもそのファイルはありませんでした。

ファイルがVSソリューションに存在し、ローカルとサーバーの両方でコンパイルされたすべてのものが存在していても、VS/TFSは実際にはファイルをソース管理に追加しませんでした。 「保留中の変更」にはまったく含まれていませんでした。私は手動でソース管理エクスプローラに行き、明示的に「フォルダに項目を追加する」アイコンをクリックしなければなりませんでした。

私はVSで15年間開発してきたので愚かです。私は以前にこれに遭遇しました、私はただ覚えていなかったし、どういうわけか私はファイルが通常の参照であるためにすべてがまだコンパイルされたのでそれを見逃しました。ソース管理サーバー.

私はこれが私の人生の2日間を失ったので、これが誰かが時間を節約することを願っています。

1
GR7

参照アセンブリを右クリックすると、Copy Localというプロパティが表示されます。 Copy Localがtrueに設定されている場合、アセンブリはビンに含まれるはずです。 ただし、、Visual Studioに問題があることがあるため、binフォルダに参照DLLが含まれないことがあります。これが回避策です。それは私のために働いた：

enter image description here

1
Hooman Bahreini

必要なライブラリを出力ディレクトリにコピーするためにPostbuildイベントに追加します。 XCopyパスライブラリtargetdirectoryのようなもの

あなたはそれらをプロジェクトのプロパティ - >ビルドイベントに見つけることができます。

1
chethan jain

メインプロジェクトとProjectXのビルド出力パスの両方を同じフォルダに設定すると、そのフォルダに必要なすべてのDLLを取得できます。

0
YantingChen

問題：

ビルド出力に参照DLLが含まれていないNuGetパッケージDLL（Newtonsoft.json.dll）で同様の問題が発生しました。しかし、コンパイルはうまくいきます。

修正：

テキストエディターでプロジェクトを調べて、タグが含まれる参照を探します。真か偽か。 「プライベート」は「ローカルコピー」の同義語です。アクションのどこかで、MSBuildは依存関係を見つけ、他の場所で依存関係を見つけて、コピーしないことを決定します。

したがって、各.csproj/.vbprojファイルを調べて、タグを手動で削除してください。再構築すると、すべてがVisual StudioとMSBuildの両方で機能します。動作するようになったら、戻って必要な場所に更新できます。

参照：

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/

0
Nkl Kumar

あなたが使用する依存DLLがあなたのプロジェクトのアプリケーションのターゲット.NETフレームワークより高いターゲット.NETフレームワークを持っていないことを確認してください。

これを確認するには、プロジェクトを選択してからAlt + Enterキーを押し、次に左側から[アプリケーション]を選択してから、[プロジェクトのターゲットフレームワーク]を選択します。

従属dllターゲットフレームワーク= 4.0およびアプリケーションdllターゲットフレームワーク= 3.5で、これを4.0に変更したとします。

ありがとうございました！

0
Manish Jain

上記の一般的なもの以外に、私は公開するマルチプロジェクトソリューションを持っていました。どうやらいくつかのファイルは異なるフレームワークをターゲットにしています。

だから私の解決策：プロパティ>特定のバージョン（False）

0
RicL

DLLを既存の項目としてプロジェクトの1つに追加すると、ソートする必要があります。

0
abhijithkarkal

コード内のダミーには必要ありません
ただ：

実行可能プロジェクトへの参照を追加します。

または実行可能プロジェクトの参照で"Copy Local"がTRUEに設定されていることを確認します（これは私の "障害"でした）。これは "上書き"base-reference library-projectの設定...

0
Cadburry