We Keep Coding

How to merge a subset of linked dll files with one exe file (C#, WinForms)?

I have a solution with two C# projects: One WinForms application (exe) and one library (dll). Multiple external dll files are referenced. I would like to merge the output of my projects into one exe file, while keeping the other dll files separately, i.e. instead of
myApp.exe
myLib.dll
externalLib1.dll
externalLib2.dll
...
I would like to have
myMergedAppAndLib.exe
externalLib1.dll
externalLib2.dll
...
Is this actually possible?
I am aware of the ILMerge tool, but it seems to be deprecated and I don't know whether it is ok not to include all referenced dll files.
I am also aware of the publishing option in Visual Studio Produce single file, but to my understanding this will also merge the external dll files, right?
I cannot merge the two projects, because the library project is also used for a third project (another WinForms exe).
Related SO question: merge-dll-into-exe

Which files do I need to distribute from a C# build?

When I build a C# application project named MyApplication with .NET 6.0 on Windows, I get the following files:
MyApplication.dll
MyApplication.exe
MyApplication.deps.json
MyApplication.dll.config
MyApplication.pdb
MyApplication.runtimeconfig.json
MyApplication.xml
Which of these files do I need to distribute?
MyApplication.dll contains the IL code of the application. I certainly need this one.
MyApplication.exe is the stub loader that starts the application. I do need this.
MyApplication.pdb contains the debug info. I don't need to distribute this.
But what about the others? They seem to contain some dependency information. But is that only required for the compiler, or is it required later at runtime? (My application consists of dozens of dll's).

From the spec of runtime configuration files
MyApp.dll - The managed assembly for MyApp, including an ECMA-compliant entry point token.
MyApp.exe - A copy of the corehost.exe executable.
MyApp.runtimeconfig.json - An optional configuration file containing runtime configuration settings.
MyApp.deps.json - A list of dependencies, as well as compilation context data and compilation dependencies. Not technically required, but required to use the servicing or package cache/shared package install features.
So while the json files are not strictly required, I would probably recommend including them.
The MyApplication.xml is an optional documentation file that contains comments for your dll. This is probably not needed if you are distributing an application and not a library, and there should be an option to turn of the generation of this file in your project properties.
You should also check the documentation for Deploying your application. I would especially consider the parts about self contained and single file publishing.

Is assembly in C# similar to the translation unit in C++? [duplicate]

Could you please explain what is an Assembly in C# or .NET?
Where does it begin and where does it end?
What important information should I know about Assemblies?

An assembly is the compiled output of your code, typically a DLL, but your EXE is also an assembly. It's the smallest unit of deployment for any .NET project.
The assembly typically contains .NET code in MSIL (Microsoft Intermediate language) that will be compiled to native code ("JITted" - compiled by the Just-In-Time compiler) the first time it is executed on a given machine. That compiled code will also be stored in the assembly and reused on subsequent calls.
The assembly can also contain resources like icons, bitmaps, string tables and so on. Furthermore, the assembly also contains metadata in the assembly manifest - information like version number, strong name, culture, referenced assemblies and so forth.
In 99% of your cases, one assembly equals a physical file on disk - the case of a multi-file assembly (one assembly, distributed across more than a single file) appears to be a rather odd-ball edge case which I've never encountered so far in my 5+ years of .NET development.
In a multifile assembly there would still be only one assembly manifest in a DLL or EXE and the MSIL code in multiple netmodule files.

The answer is in order for immediate-grasping.
Put simply, it is the compiled project involving your classes and additional files, if there are. That is, each project in a
solution is assembly.
Or more techinally,
An assembly is where a type is stored in the flesystem. Assemblies are
a mechanism for deploying code. For example, the System.Data.dll
assembly contains types for managing data. To use types in other
assemblies, they must be referenced. - Source
How do we know it? If you glance at properties of a project under the solution you can see the following images.
When you compile the project, it turns out to DLL or EXE.

.NET assembly
In the Microsoft .NET framework, an
assembly is a partially compiled code
library for use in deployment,
versioning and security.

http://www.codeguru.com/columns/csharp_learning/article.php/c5845
An assembly is a file that is automatically generated by the compiler upon successful compilation of every .NET application. It can be either a Dynamic Link Library or an executable file. It is generated only once for an application and upon each subsequent compilation the assembly gets updated.

Here's another explanation of the make up of .NET Assemblies, a mini-quote:
The .NET framework consists of the
concepts of modules, assemblies, which
both store metadata and manifest
information. An assembly can contain
multiple modules. Visual C# only ever
creates one module which is turned
into an assembly by the C# compiler
(csc.exe), but an assembly can link
many .NET modules together via the
assembly linker (al.exe) command-line
tool. For example each of your source
code .cs files could be compiled into
a module and linked together to form
an assembly - an assembly is just a
collection of modules and resources.
One of these modules, however; must
contain manifest metadata (see below)
information for the assembly to be
understood by the CLR.
....
Having created a new .exe or .dll
inside VS.NET you see your file appear
inside your bin folder. Opening it in
notepad will give out gibberish, or
even inside a hexadecimal editor
without knowing the structure of the
file, you need a tool like ildasm.exe
or CFF explorer to make meaning from
it. The structure of the assembly is
as follows:
PE header
CLR header
CLR metadata
CLR
IL code
Native data

When a source code is compiled by the language compiler it Generate a Managed Assembly and MSIL(MisroSoft Intermediate Language). That Assembly contains .dll or .exe file. An Assebmly can be of two types Private Assembly and Shared Assembly, shared Assembly is stored in GAC(Global Assembly Cache) so that any application can refer to it while private assembly is stored in application folder which can be used by only one Application.

An assembly is a DLL or an EXE which will be created when you publish it or compile your application.

After writing source code of your program(project) then a file is created which may be DLL or EXE depends on your project. It makes only once for a single project. It has two types
1:- single
2:- shared or multiprogram
single assembly used only in a single program while shared can be used for multiprogram

An Assembly is a collection of logical units. Logical units refer to the types and resources which are required to build an application and deploy them using the .Net framework. Basically, Assembly is a collection of Exe and DLLs. It is portable and executable.

Visual Studio 2010 EXE Packaging [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Embedding DLLs in a compiled executable
I have a c# winforms application along with a few depending .dlls and a dependant external .exe.
Is it possible to somehow complile all of them into one executable (not installer) just stand alone executable?
From VS 2010 Ultimate if possible?

In short: the only way that may work is to add all external files as an embedded resource and use ILMerge.
Option #1: the following steps show how to embed a resource file Inside Visual Studio :
Go to Solution Explorer,
Right click the resource file,
GO to Build Actions: Select Embedded Resource.
You will have that file reference inside the exe. Later you can use Reflection and get the resource when you run your application. Borrowed Source Code from here:
Option #2 with managed dll's:
For the managed DLLs you have a couple of options:
Use ILMerge. ILMerge has a nice GUI interface that can be found [here]7]
Embebed them as a resource, see this article for details.
Check out the following CodeProject article that explains this .
ILMerge is a utility that can be used to merge multiple .NET assemblies into a single assembly. ILMerge takes a set of input assemblies and merges them into one target assembly. The first assembly in the list of input assemblies is the primary assembly. When the primary assembly is an executable, then the target assembly is created as an executable with the same entry point as the primary assembly. Also, if the primary assembly has a strong name, and a .snk file is provided, then the target assembly is re-signed with the specified key so that it also has a strong name.

ILMerge is a utility that can be used to merge multiple .NET assemblies into a single assembly.

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