I have a solution with multiple MVC and libraries projects and the build of this solution is very slow.
To improve the build performance, I changed all projects to output in the same folder and changed all project references to copy local = false, this improved the build performance almost in 90%, from 10m to 1m30s.
However, this generated an issue, in run mode my application show errors because have no references assemblies in the output folder.
I'd like to know if exists a way, to make solution copy the references only one time to my output folder.
I tried somethings, like a target to copy the dlls from packages folder to the output folder, but this not work correctly, because in a packages folder can exists dlls from many framework versions.
Any ideia to solve this issue?
One common solution is to have all projects output to the same directory, and have all references set to CopyLocal=False, and then have one extra project (or an existing one, like the main application) targetting the same output directory and which contains all references and has CopyLocal=True. Then that one project effectively takes care of getting all your references where you want them. To get all projects use the same output directory I'd suggest to modify the .csproj files to all import the same file which sets the OutputPath property instead of manually changing it in each project.
Alternatively, since you mention the main problem with a single output directory and CopyLocal set to True is that some files get copied multiple times, you could modify how the copying occurs. Normally, by default, the Copy tasks used will skip files with matching timestamps. This is controlled by the SkipCopyUnchangedFiles flag so you could force it to true and see if that changes anything:
msbuild my.sln /p:SkipCopyUnchangedFiles=True
Or you could even ask it to use hardlinks instead of copying, this should effectively mean no copies are made at all:
msbuild my.sln /p:CreateHardLinksForCopyLocalIfPossible=True
or symbolic links:
msbuild my.sln /p:CreateSymbolicLinksForCopyLocalIfPossible=True
If all else fails and files are still copied more than once it could mean e.g. that one project references A.dll and another one also references A.dll but from a different directory or a different version etc, so it will get copied twice no matter what unless you fix that.
I have included some native DLLs that my project depends on into the project and set in their properties Build Action to content and Copy to Directory to Copy if newer.
I am now having the annoying behavior that the DLLs are sometimes not being copied to the output directory, when I build a project. The behavior appears to be, that when I select Build they are not being copied, but they are being copied when I select Rebuild. To make matters worse they are sometimes removed and I am not sure when (I believe before performing a normal Build).
So my question is: What am I doing wrong? I have also found people using the Post-Build event to copy the DLLs, so is my way not the correct way to do it?
Edit:
I forgot to mention that I have two projects (on which the project that I am building depends) with the same Dlls included, since they both depend on EmguCV, which uses the native OpenCV Dlls, which are the ones causing the trouble.
during development of our application we use a branching structure and while we are developing another team is using earlier builds of our software to create content with it.
To facilitate easy swapping between builds and teams I was hoping to use empty Hintpaths in the content projects' csproj files so that they can use our GAC installed assemblies to build against and in the meantime add a reference path to the projects for our use during development and test cycles where we don't want any assemblies installed in the GAC.
However, it seems reference paths are not stored in the csproj file and thus don't get sourcecontrolled. Since there will be extensive branching it would be less than ideal to have to set all reference paths again when a developer pulls another branch from sourcecontrol.
I've been searching for a bit now and can't seem to find ways to do this. Anybody know of a way to force the reference path in and out of sourcecontrol?
We're talking Visual Studio 2008 and TFS 2008 here.
Cheers,
Anton.
Ok, I seem to be a little clearer in the head after a good night's sleep, took the logical step, namely investigate where exactly the information was stored and how. It turned out the information was stored in the .user file for the project in the project's folder and as it turens out this file contains mbsuild xml.
I then did what I wanted as follows:
Create the Reference path as I required it to facilitate both scenarios without any work.
Browse to the Project's .user file
Copy the PropertyGroup containing the ReferencePath
Paste the PropertyGroup in all the necessary Projects' .csproj xml.
Reload and build.
Done.
The references are stored in the *.csproj file. The nodes are ItemGroup/Reference...
Thomas
This is pretty simple--we do this in our shop.
First, in the Workspace (using Windows Explorer, browse to the Solution folder), create a folder. We name it "Referenced Assemblies". In here, drop all your DLLs.
Now, in the Solution, add a new folder to match the one created in Windows Explorer. Into that folder, add all the DLLs you just dropped in.
Finally, in each project, set up your references to use the DLLs that were added to the solution.
Now your project references DLLs that are part of the solution, so that when the build runs, it will grab the DLL from Source Control to generate the build.
Also, I'd recommend not using the GAC at all if you can avoid it. In my experience, reference behavior is strange. It seems references go first to the GAC, then to the DLL in the local folder, meaning that if the DLL is updated, the one in the GAC is used instead of the DLL in the local folder (which is likely the updated one).
Our solution has several (10+) C# projects. Each has a reference to the CAB extension library, with the reference pointing to the DLLs in the library's release folders. Each project has between four and seven such references.
We'd like to make some changes to the library; but to debug the changes, we'll need to build a debug version of the library and refer to that. I'd like to add the library's projects to our solution and change each of the DLL references to a project reference.
Is it possible to perform a 'find and replace' on the existing references, or will I have to do it by hand?
There isn't such a feature in the VS IDE.
However, as a .csproj file is just an XML document it is possible to do such a global search and replace in a scripted fashion e.g. by changing one file to observe the before and after states then running sed over the remainder.
For a one-off, going to the extent of writing a script to load the XML and making the substitutions by DOM manipulation is probably overkill.
Take a look at Jared's answer to this SO thread. That approach will likely work for you.
If you download CI Factory, it just so happens that there is a nant function in there called FixUpThirdPartyRefs which you could use or tweak to help you do this. So you could just setup nant and use that function.
It is part of the power tools with CI Factory: http://www.cifactory.org/joomla/index.php?option=com_content&task=view&id=29&Itemid=41
Why don't you just replace DLLs in library's release folder with debug version temporary ? I assume that you have local development environment.
EDIT:
You could:
1. develop all time with debug version of library
2. make updating references in *.csproj more flexible
3. make file system location of library files more flexible
On point 3: If the path to your library dlls contains "release" and if debug and release library folder structure is the same than change from release could be made by just renaming folder "release" to "release.original" and "debug" to "release".
I would probably choose option 1 and all time develop with debug assemblies. Release build would use just for final testing and deploy to customer. Debug and release dlls are not that different.
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