We Keep Coding

Add reference to local folder

I'm adding my dll file to my reference and set Copy local to true
Everything is OK and after I build application, my dll added to output folder
Now my question is how do Ι change the local path?
For example:
my application path is C:\myproject, I want to put dll into C:\myproject\libs
How can I set dll path to {applicatonpath}\libs NOT {applicationpath} ?

When you compile you project, visual studio will put everything that has been compiled and set to copy locally to the "output folder", which depends on your current compile configuration. If you are compiling in Debug mode then this folder will be:
c:\your_solution_path\your_project_path\bin\Debug
If you use Release mode, it will be:
c:\your_solution_path\your_project_path\bin\Release
However, sometimes we reference a lot of assemblies (DLLs if you will) and those assemblies have dependencies of their own. In order to make everything "point and click" for our convenience, we must tell visual studio how we would like it to act for a particular project build.
So, as TotPeRo said, you should go do project properties and use the functionality of Pre-build and Post-build events. As the name suggests, Pre-Build happens before the actual build, while Post-Build takes place immediately after it. Please refer these links for further information: link1 and link2.
Lets assume the following scenario:
You have one solution.
that solution holds 2 projects (let's call them Project A and Project B). Project A is the actual GUI. Project B is just a helper project, that compiles into a DLL.
Let's say, that project B is doing some heavy matrix calculations, so you also have to include some MatLab libraries. NOTE: only Project B uses these libraries.
Project A references project B so that you can use the calculated information from B and show it in gui in A.
In order to compile this, the compiler is smart enough to determine, that Project B should be compiled first. If everything checks, the project is compiled into ProjectB.dll. Then, the compiler proceeds to compile Project A. It check all the dependencies and finds out, that you have already compiled Project B (which is a dependency for Project A) and that it can continue. Everything is then copied to the output folder (bin/Debug or bin/release) and should be in working order.
However, during runtime, something goes wrong and the application crashes. You find out, that Project B does not have the appropriate library to work with (namely MatLab libraries). And then you conclude, that MatLab should be included in the bin/debug (or bin/release) folder at compile-time. Since the MatLab library is a dependency library for Project B but not for Project A, it does not get copied and hence the exception. You can mitigate this behavior with the aforementioned Pre and Post-Build events. You can tell the Visual Studio that you want it to manually copy MatLab.dll to the output folder when it is doing a compile. This comes super handy when you come into situations like these. Build events can also trigger a lot of other things so be sure to check it out. I'm using this a lot and it's a time saver at least.

in the Visual Studio you can go Project > [project name] Properties > Reference Path
change the path/create folder or else you want
First make folder lib new project source code then use relative address

in post-build event on visual studio go to properties in your project and add this:
copy "c:\pathtolibrary\bin\debug\namelibrary.dll" "$(SolutionDir)\bin\Debug\libs"

How to build a visual studio 2010 solution into a standalone dll?

I have a visual studio 2010 project, uses static and dynamic libs (.lib and .dll), the project is compiled and built successfully as .exe both in release and debug modes, the code is c and c++.
What is the right way to compile and wrapping all the solution to one standalone .dll file.
I want to have one dll file, I'll be able to load it in other c, c++, c# project safely.
in my case I want to load it in teraterm and in other simple self developed c# application.

Visual Studio has a C++ linker option called "Link Library Dependencies": http://msdn.microsoft.com/en-us/library/024awkd1(v=vs.90).aspx
This would link the object files from all projects in the solution directly into the project output (via dependency tracking). Be careful when you use this though, if you use this in an EXE and the DLLs you're linking export symbols your EXE will also export them.
Update:
Here's more detail: What happens is that instead of linking the DLLs (this assumes you have the DLLs you'd like to link set as dependencies of your project in the solution) to produce separate binaries, the linker takes the outputs from each individual project dependency and links them into the final executable/DLL directly, thus creating a monolithic DLL.
A side effect is that (depending on the code) the overall size of the output is reduced a little, the monolithic DLL (or EXE) might be large in general, but smaller in size than the individual output files combined due to link-time optimisations. Any symbols exported by the objects linked will be exported by the final DLL, since they are marked as such in the compilation step.

There's may be a catch, but being in VS2010, you should just click on the startup project, select 'properties' ->
'configuration properties' -> 'general' -> 'configuration type' -> set it to 'dynamic library (dll)'

Copy C++ library to a C# project automatically on build? (Visual Studio 2010)

I have a library written in C++, and a wrapper for this library written in C#.
Both projects are under development, and the way it is now I have to manually copy the .dll from the C++ project to the C# project after each build.
So I was wondering if there was any way to make Visual Studio copy the .dll from the C++ project automatically when re-building?

You can use Build events in visual studio and place a dos command to copy the dll to the current project
Right click on the project in Solution explorer in Visual studio, select properties. There in Build events you can type:
copy c:\Cplusproject\yourproject.dll $(TargetDir)
You can use Post Build or Pre Build events based on your requirements
See this article: http://geekswithblogs.net/dchestnutt/archive/2006/05/30/80113.aspx

Use post build event for that. Just something like xcopy <yourDllFilePath> <destinationPath> and it will copy your dll file to wherever your want

if yr using that c++ dll as reference, then u might be able to add the c++ project as a project reference, and everything will be copied automaticly, and it also helps while debugging.
Click on references in yr c# project, then a dialog window opens and choose Projects and select yr c++ project

There are several approach to achieve what you request.
Here I suppose you are using Microsoft Visual C++, but on other platforms there will be analogous functionalities.
Right click on the icon representing the vc++ project on the Solution explorer
Click Properties
Select the Configuration Properties/Build Events/Post Build Event node
Write the Command Line required to copy the dll around
Remember you must do it for every Configuration and for every Platform supported from your project.
Alternatively you may ask the Linker to output directly on the location referenced by your C# project:
Right click on the icon representing the vc++ project on the Solution explorer
Click Properties
Select the Configuration Properties/Linker/General Event node
Set the Output File property to the location referenced by your C# project
That said, you may also get the dll from the c# project.

C# / C++ in same solution - DllImport not finding DLL

I have a solution with a C++ dll project and a C# project that uses it. The problem is that the build path of the c++ project is in the solution folder and the c# is in the project's bin folder (each nested with debug/release), so the DllImport doesn't find them.
Is there a standard way to fix this?

The way you are supposed to do this is to set the build path for both projects to the same 'bin' directory... preferrably one for the solution, not a project. Then just make all projects build to that one folder. You can change that from the Project settings.
Another technique is to use a post-build step for the C++ app that copies the DLL to the C# project's folder. That way you don't actually change any paths. You just copy over a DLL. Be careful here though because when you clean the C++ file's project, you may actually still have the copy in the C# projec'ts bin directory leaving you scratching your head as to why things aren't happening as expected.
Alternately, you can deploy the C++ DLL to a system path (also as part of a post-build step) but you'll have the same issues as stated above.
For debugging, I'd recommend these in the order presented.

Cleanest Method for copying Native DLLs in a .NET Project

I have a C# GUI application that references a Managed C++ project, which requires 7 native C++ DLLs. I'm looking for the cleanest method for copying these 7 DLLs to the final project output.
What works
Add all DLLs to the C# applications, specifying:
Build Action == "Content"
Copy To Output Directory == Copy Always"
This will make the base folder of the project a mess of DLLs in some cases, all of which are requirements of referenced projects, and not that project itself.
What does not work
Adding these DLLs to a folder named "Required DLLs" with the above settings. It copies it to a folder with the same name in the output, causing them to be in an incorrect location. I can't see a way to specify the output directory.
Embedded Resources: In C# P/Invoke, you can add DLLs you're referencing as embedded resources, and the DLLs are embedded inside your final library. I don't see this possibility in Managed C++, and I'm not even sure if it works with reference chains.
Adding the DLLs as content within the Managed C++ project. The files do not get copied to the output directory.
What is the best solution in this case? I'd prefer the Managed C++ project to be able to handle it's own DLL requirements if possible, and preferably in a way that won't prevent the project from being used across multiple applications.
As far as having a clean project goes, is it better to insert all my code files within subfolders in the project, and have the DLLs at the root to make the first solution work?
Solution:
Using the post-build suggestion from Joseph, the following command does the trick to use a "Required DLLs" folder.
xcopy "$(ProjectDir)Required DLLs*.*" "$(TargetDir)" /Q /Y
/Q hides the individual files from the output, and /Y suppresses overwrite prompts.

You can use a post-build event to copy the contents of a directory (e.g., your "Required DLLs" directory) into the project's output directory.

You can work with static libs instead of dynamic, it will make your dlls bigger but single dll instead of multiple is just time saver and not only in your aspect.
Route all the projects in the solution to a single directory (managed and unmanaged).