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)'

VS2010 generates different assembly each time compiling the project

I have some c# projects. I added post build event to those projects that copy the resulted assembly (dll) from the bin into common folder.
It appears that each compile generates assembly which is binary different from the previous even when I don't modify the project files.
It is quite a problem for me since I'm using Kiln that monitor those file and think they were modified.
I read somewhere that the dll stores time stamp of compilation which if true then I cannot fix this. If so how do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?
Thanks,
Eran.

To address the specific question of "How do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?", I have a very simple answer: ignore.
We exclude /bin and /obj from the directories which our source control will even attempt to commit. This does mean that you will need to recompile the code on each machine after each change, but Visual Studio would do that anyway for any project where the code has changed.

Don't commit the output folders of your projects.
If you want to have a Setup folder or something similar that always contains the latest versions of the assemblies created by your projects, the solution is to make sure that your post-build event is configured to run only when the build updates the project output. There is an option that is named like this:

How do you manage generated code in Visual Studio - in particular, creating DLLs from .idls

I'm trying to add a generated COM interop assembly project to my solution, and the only solution I could come up with feels really nasty.
I created a .net dll project, removed all .cs files from it and then created the following post-build event:
call "$(DevEnvDir)..\tools\vsvars32.bat"
midl.exe $(ProjectDir)relative-path-to-my-idl\MyComName.idl /tlb MyComName.tlb
tlbimp.exe /keyfile:path-to-my-key\k.snk MyComName.tlb
Essentially, I first create an empty DLL, then overwrite it with a real interop DLL. And there's no dependency management here - it's created every time.
Is there a better way to do this?

The MIDL compilation can be handled by making the COM interop project a managed C++ project (instead of a C# project) then adding the idl and h to the project as regular source files.

You can overcome the dependency problem by using MSBuild tasks directly instead of a PostBuild batch file, which line up nicely with the MSBuild dependency system.
However, why are you generating the file manually from an idl? When I need COM interop, I just import it and put the generated assembly (*.Interop.dll) into version control. This way, you always have the version you need and it's already ready to use, and Visual Studio can find the interop DLL before the first build, i.e. Intellisense is there right from the beginning.
Now some people won't like to check in a binary file, which I typically agree with, but well, if it works... :)
Of course, my method won't work if building the COM server is part of building the solution. In this case, just try to put the generation into the MSBuild script to get rid of the dependency thing, unless Visual Studio accepts a reference to a solution-internal non-.NET-COM project.

ILMerge Best Practices

Do you use ILMerge? Do you use ILMerge to merge multiple assemblies to ease deployment of dll's? Have you found problems with deployment/versioning in production after ILMerging assemblies together?
I'm looking for some advice in regards to using ILMerge to reduce deployment friction, if that is even possible.

I use ILMerge for almost all of my different applications. I have it integrated right into the release build process so what I end up with is one exe per application with no extra dll's.
You can't ILMerge any C++ assemblies that have native code.
You also can't ILMerge any assemblies that contain XAML for WPF (at least I haven't had any success with that). It complains at runtime that the resources cannot be located.
I did write a wrapper executable for ILMerge where I pass in the startup exe name for the project I want to merge, and an output exe name, and then it reflects the dependent assemblies and calls ILMerge with the appropriate command line parameters. It is much easier now when I add new assemblies to the project, I don't have to remember to update the build script.

Introduction
This post shows how to replace all .exe + .dll files with a single combined .exe. It also keeps the debugging .pdb file intact.
For Console Apps
Here is the basic Post Build String for Visual Studio 2010 SP1, using .NET 4.0. I am building a console .exe with all of the sub-.dll files included in it.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
Basic hints
The output is a file "AssemblyName.all.exe" which combines all sub-dlls into one .exe.
Notice the ILMerge\ directory. You need to either copy the ILMerge utility into your solution directory (so you can distribute the source without having to worry about documenting the install of ILMerge), or change the this path to point to where ILMerge.exe resides.
Advanced hints
If you have problems with it not working, turn on Output, and select Show output from: Build. Check the exact command that Visual Studio actually generated, and check for errors.
Sample Build Script
This script replaces all .exe + .dll files with a single combined .exe. It also keeps the debugging .pdb file intact.
To use, paste this into your Post Build step, under the Build Events tab in a C# project, and make sure you adjust the path in the first line to point to ILMerge.exe:
rem Create a single .exe that combines the root .exe and all subassemblies.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
rem Remove all subassemblies.
del *.dll
rem Remove all .pdb files (except the new, combined pdb we just created).
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).all.pdb.temp"
del *.pdb
ren "$(TargetDir)$(TargetName).all.pdb.temp" "$(TargetName).all.pdb"
rem Delete the original, non-combined .exe.
del "$(TargetDir)$(TargetName).exe"
rem Rename the combined .exe and .pdb to the original project name we started with.
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).pdb"
ren "$(TargetDir)$(TargetName).all.exe" "$(TargetName).exe"
exit 0

We use ILMerge on the Microsoft application blocks - instead of 12 seperate DLL files, we have a single file that we can upload to our client areas, plus the file system structure is alot neater.
After merging the files, I had to edit the visual studio project list, remove the 12 seperate assmeblies and add the single file as a reference, otherwise it would complain that it couldnt find the specific assembly. Im not too sure how this would work on post deployment though, could be worth giving it a try.

I know this is an old question, but we not only use ILMerge to reduce the number of dependencies but also to internalise the "internal" dependencies (eg automapper, restsharp, etc) that are used by the utility. This means they are completely abstracted away, and the project using the merged utility doesn't need to know about them. This again reduces the required references in the project, and allows it to use / update its own version of the same external library if required.

We use ILMerge on quite a few projects. The Web Service Software Factory, for example produces something like 8 assemblies as its output. We merge all of those DLLs into a single DLL so that the service host will only have to reference one DLL.
It makes life somewhat easier, but it's not a big deal either.

We had the same problem with combining WPF dependencies .... ILMerge doesn't appear to deal with these. Costura.Fody worked perfectly for us however and took about 5 minutes to get going... a very good experience.
Just install with Nuget (selecting the correct default project in the Package Manager Console). It introduces itself into the target project and the default settings worked immediately for us.
It merges the all DLLs marked "Copy Local" = true and produces a merged .EXE (alongside the standard output), which is nicely compressed in size (much less than the total output size).
The license is MIT as so you can modify/distribute as required.
https://github.com/Fody/Costura/

Note that for windows GUI programs (eg WinForms) you'll want to use the /target:winexe switch. The /target:exe switch creates a merged console application.

I'm just starting out using ILMerge as part of my CI build to combine a lot of finely grained WCF contracts into a single library. It works very well, however the new merged lib can't easily co-exist with its component libraries, or other libs that depend on those component libraries.
If, in a new project, you reference both your ILMerged lib and also a legacy library that depends on one of the inputs you gave to ILMerge, you'll find that you can't pass any type from the ILMerged lib to any method in the legacy library without doing some sort of type mapping (e.g. automapper or manual mapping). This is because once everything's compiled, the types are effectively qualified with an assembly name.
The names will also collide but you can fix that using extern alias.
My advice would be to avoid including in your merged assembly any publicly available lib that your merged assembly exposes (e.g. via a return type, method/constructor parameter, field, property, generic...) unless you know for sure that the user of your merged assembly does not and will never depend on the free-standing version of the same library.

We ran into problems when merging DLLs that have resources in the same namespace. In the merging process one of the resource namespaces was renamed and thus the resources couldn't be located. Maybe we're just doing something wrong there, still investigating the issue.

We just started using ILMerge in our solutions that are redistributed and used in our other projects and so far so good. Everything seems to work okay. We even obfuscated the packaged assembly directly.
We are considering doing the same with the MS Enterprise Library assemblies.
The only real issue I see with it is versioning of individual assemblies from the package.

I recently had issue where I had ilmerged assembly in the assembly i had some classes these were being called via reflection in Umbraco opensource CMS.
The information to make the call via reflection was taken from db table that had assembly name and namespace of class that implemented and interface. The issue was that the reflection call would fail when dll was il merged however if dll was separate it all worked fine. I think issue may be similar to the one longeasy is having?

It seems to me like the #1 ILMerge Best Practice is Don't Use ILMerge. Instead, use SmartAssembly. One reason for this is that the #2 ILMerge Best Practice is to always run PEVerify after you do an ILMerge, because ILMerge does not guarantee it will correctly merge assemblies into a valid executable.
Other ILMerge disadvantages:
when merging, it strips XML Comments (if I cared about this, I would use an obfuscation tool)
it doesn't correctly handle creating a corresponding .pdb file
Another tool worth paying attention to is Mono.Cecil and the Mono.Linker [2] tool.
[2]: http:// www.mono-project.com/Linker