종속 DLL이 Visual Studio의 빌드 출력 폴더로 복사되지 않습니다

종속 DLL이 Visual Studio의 빌드 출력 폴더로 복사되지 않습니다

---

비주얼 스튜디오 솔루션이 있습니다. 솔루션에 많은 프로젝트가 있습니다. 시작 역할을하고 다른 프로젝트를 사용하는 하나의 주요 프로젝트가 있습니다. "ProjectX"라는 프로젝트가 있습니다. 참조는 기본 프로젝트에 추가됩니다. ProjectX는 솔루션의 일부가 아닌 다른 .NET dll (예 : abc.dll)을 참조합니다.

이제이 abc.dll은 기본 프로젝트의 bin / debug 폴더에 복사해야하지만 복사되지는 않습니다. 알려진 이유가 무엇입니까?

---

ProjectX가 abc.dll을 참조했지만 abc.dll에서 DEFINED 유형을 직접 사용하지 않으면 abc.dll이 기본 출력 폴더로 복사되지 않습니다. (이는 혼동을 피하기 위해 ProjectX 출력 폴더로 복사됩니다.)

따라서 ProjectX의 어느 곳에서나 abc.dll의 형식을 명시 적으로 사용하지 않으면 ProjectX의 파일 중 하나에 더미 선언을 넣으십시오.

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

모든 클래스에 대해이 작업을 수행 할 필요는 없습니다. 한 번만 있으면 DLL 복사본을 만들 수 있고 모든 것이 예상대로 작동합니다.

부록 : 디버그 모드에서는 작동하지만 릴리스에서는 작동하지 않습니다. 자세한 내용은 @nvirth의 답변을 참조하십시오.

---

오버로드 주르그의 답변에 대한 주석.

이 방법으로 더미 참조를 추가했으며 디버그 모드에서 작동했습니다.

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);
    }
}

이 정보는 실제로 알아내는 데 몇 시간이 걸렸으므로 공유하기로 생각했습니다.

---

예,로 설정 Copy Local해야 true합니다. 그러나 나는 확신 당신은 또한 조립 주요 프로젝트와 세트에서 참조해야합니다 Copy Local에 true그것은 단지 종속 어셈블리에서 복사되지 않습니다 -뿐만 아니라.

Copy Local아래의 어셈블리를 클릭 References하고 F4를 눌러 속성으로 이동할 수 있습니다 .

---

어셈블리 속성으로 만들 때 매끄럽게 보입니다.

[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))]

---

이 같은 문제에 부딪쳤다. 배경 정보 : 구축하기 전에 솔루션에 새로운 Project X를 추가했습니다. 프로젝트 Y는 프로젝트 X에 의존하고 프로젝트 A, B, C는 프로젝트 Y에 의존했습니다.

빌드 오류는 프로젝트 A, B, C, Y 및 X dll을 찾을 수 없다는 것입니다.

Root cause was that newly created Project X targeted .NET 4.5 while the rest of the solution projects targeted .NET 4.5.1. Project X didn't build causing the rest of the Projects to not build either.

Make sure any newly added Projects target the same .NET version as the rest of the solution.

---

Not sure if this helps but for me, many times I reference a DLL (which automatically adds it to the bin folder of course). However that DLL might need additional DLLs (depending on what functions I'm using). I do NOT want to reference those in my Project because they just simply need to end up in the same folder as the DLL I am actually using.

I accomplish this in Visual Studio by "Adding an existing file". You should be able to add it anywhere except the Add_data folder. personally I just add it to the root.

Then change the properties of that file to ...

Build Action = None (having this set to something like Content actually copies the "root" version to the root, plus a copy in the Bin).

Copy to output folder = Copy if Newer (Basically puts it in the BIN folder only if it is missing, but doesn't do it after that)

When I publish.. my added DLL's only exists in the BIN folder and nowhere else in the Publish location (which is what I want).

---

You could also check to make sure the DLLs you're looking for aren't included in the GAC. I believe Visual Studio is being smart about not copying those files if it already exists in the GAC on the build machine.

I recently ran in this situation where I'd been testing an SSIS package that needed assemblies to exist in the GAC. I'd since forgotten that and was wondering why those DLLs weren't coming out during a build.

To check what's in the GAC (from a Visual Studio Developer Command Prompt):

gacutil -l

Or output to a file to make it easier to read:

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

To remove an assembly:

gacutil -u MyProjectAssemblyName

I should also note, that once I removed the files from the GAC they were correctly output in the \bin directory after a build (Even for assemblies that were not directly referenced in the root project). This was on Visual Studio 2013 Update 5.

---

This is a slight tweak on nvirth's example

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

---

In my case, it was the stupidest thing, caused by a default behavior of TFS/VS that I disagree with.

Since adding the dll as a reference to the main project did not work, I decided to add it as an "Existing Item", with Copy Local = Always. Even then the file was not there.

Turns out that, even though the file is present on the VS Solution and everything compiled both locally and on the server, VS/TFS did not add actually add the file to source control. It was not included on the "Pending Changes" at all. I had to manually go to the Source Control Explorer and explicitly click on the "Add items to folder" icon.

Stupid because I've been developing for 15 years in VS. I've run into this before, I just did not remember and somehow I missed it because everything still compiled because of the file being a regular reference, but the file that was added as Existing Item was not being copied because it did not exist on the source control server.

I hope this saves someone some time, since I lost 2 days of my life to this.

---

I would do add it to Postbuild events to copy necessary libraries to the output directories. Something like XCopy pathtolibraries targetdirectory

You can find them on project properties -> Build Events.

---

If you right Click the referenced assembly, you will see a property called Copy Local. If Copy Local is set to true, then the assembly should be included in the bin. However, there seams to be a problem with Visual studio, that sometimes it does not include the referenced dll in the bin folder... this is the workaround that worked for me:

---

You may set both the main project and ProjectX's build output path to the same folder, then you can get all the dlls you need in that folder.

---

Make sure that the dependent dll used by you does not have target .net framework higher than the target .net framework of your project's Application.

You can check this by selecting your project, then press ALT+ENTER, then select Application from left side and then select Target Framework of your project.

Suppose, dependent dll Target Framework = 4.0 and Application dll Target Framework = 3.5 then change this to 4.0

Thank you!

---

Other than the common ones above, I had a multi-project solution to publish. Apparently some files target different frameworks.

So my solution: Properties > Specific Version (False)

---

NO NEED FOR DUMMY IN CODE
Just :

add a Reference to the Executeable Project

or/and ensure that the reference in the executeable project has "Copy Local" set to TRUE (which was my "fault") is seems that this "overwrote" the setting in the base referenced library-project...

---

Add the DLL as an existing item to one of the projects and it should be sorted

---

Issue:

Encountered with a similar issue for a NuGet package DLL (Newtonsoft.json.dll) where the build output doesn't include the referenced DLL. But the compilation goes thru fine.

Fix:

Go through your projects in a text editor and look for references with tags in them. Like True or False. “Private” is a synonym for “Copy Local.” Somewhere in the actions, MSBuild is taking to locate dependencies, it’s finding your dependency somewhere else and deciding not to copy it.

So, go through each .csproj/.vbproj file and remove the tags manually. Rebuild, and everything works in both Visual Studio and MSBuild. Once you’ve got that working, you can go back in and update the to where you think they need to be.

Reference:

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

참고URL : https://stackoverflow.com/questions/15816769/dependent-dll-is-not-getting-copied-to-the-build-output-folder-in-visual-studio