ILMerge | ILMerge is a static linker for .NET Assemblies | Code Editor library

Context: I'm writing a CRM Plugin, trying to use a recent version of RestSharp. I'm trying to use ILMerge to merge in RestSharp (and its dependencies such as the listed error) into the Plugin DLL.

Merged assemblies: ... source\repos\MyCRMVSSolution\packages\System.Runtime.CompilerServices.Unsafe.5.0.0\lib\net45\System.Runtime.CompilerServices.Unsafe.dll; ...

error : Unresolved assembly reference not allowed: System.Runtime.CompilerServices.Unsafe.

See above, the "merged assemblies" command shows that it knows where the file is under /packages/, and it knows to try to Merge it. Yet it says it's an unresolved reference.

Why could it come back saying "Unresolved" for it? Not sure what to even review or debug. It's apparently reading it right where I want it to, under packages. But somehow not.

Using the Nuget package MSBuild.ILMerge.Task, with default/OOTB configuration.

I have a SQL Sever database project in my solution and several dependencies projects.

When I compiling (in VS) this database project I've get a SQL script and a .dacpac file as result.

But also I want to aggregate all my dependencies projects in one dll and make SQL script/.dacpac file only for this result dll.

I'm using ILMerge.MSBuild.Tasks.ILMerge to aggregate all dll on AfterBuild event in sqlproj. But this aggregation happens after generating SQL script.

How can I enforce SQL script generation in the end?

Build log:

What I am doing (partly for fun and learning, partly hopefully as a serious virtualization effort someday) is merging my VM dll with a target assembly via ILMerge.

Only afterwards I modify the newly created file with dnlib to replace the method bodies of selected methods with a call to my VM function. I pass the required metadata that is now absent in the method itself via a base64 encoded binary string and obviously the arguments and the old method body too (in the future I want to implement my own bytecode instruction set for that, but so far its just the original code base64-encoded).

Since .initlocals is from my experience always set in a .NET method, what I want to do is save the type of every local as data in such a way that I can initialize my local array in the Virtualizer runtime with it.

My current approach is just to save the MDToken writer.Write(local.Type.ToTypeDefOrRef().GetNonNestedTypeRefScope().MDToken.ToInt32());

I write my changes to the assembly with the PreserveAll flag opts.MetadataOptions.Flags = dnlib.DotNet.Writer.MetadataFlags.PreserveAll;

and in the runtime resolve the MDToken via

I have two assemblies:

1. Main plugin assembly - Plugin used for my project
2. Framework assembly - I want to merge this assembly with the main plugin so I can reuse some common methods used a lot in different projects.

I installed ILMerge on the main plugin assembly and referenced the built out framework dlls while simultaneously setting project build order on the solution.

Now, this looks okay before I deploy. The main problem comes when I try to debug using my unit tests project.

In my unit tests project, I have a reference to the main plugin assembly which allows me to use fakexrmeasy to run my unit tests. However, now that the assemblies have been merged I expect that I should be able to use the framework methods within my unit tests project. I cant seem to access those methods when referencing the main plugin assemblies in the test classes.

All of the projects mentioned above exist within the same solution.

Im fairly new to ILMerge so might be doing something wrong thats glaringly obvious. I just compile using the built in visual studio compiler.

Can anyone suggest what could be going wrong?

I have main assembly MyAssembly.dll and a lot of libraries which I want to merge into main assembly. Because there are lots of them, I wanted to include them all using wildcard, something like this:

ILMerge.exe /wildcard /allowDup /out:MyAssembly.Merged.dll MyAssembly.dll *.dll

The problem with this approach is that it merges MyAssembly.dll twice, resulting in duplicated type names, so need to use /allowDup option. But this option renames duplicated types, and I don't want that (my DLL is a plugin for other application and all types must have original names). I could omit MyAssembly.dll in command line, but because ILMerge merges assemblies alphabetically, it treats the first one as a main assembly (for example Autofac.dll) which results in final assembly having wrong metadata (version etc.). Is it possible to exclude certain assembly name with wildcard option?

As the title says, I want to consume all of PDFSharp's source code into my own project. But let me explain why I came to this scenario, so if there is something else I can do, maybe there are other options.

Goal: Compile my project into a single .exe file to use. No installers. Problem: It uses PDFSharp.dll which is causing me issues.

What I am trying to do, is use ILMerge to create the .exe. I've used this successfully in the past for other projects.

The issue I think is that ILMerge is requiring references to other assemblies that PDFSharp uses. The first being Microsoft.ApplicationInsights. So to by-pass this, I installed Microsoft.ApplicationInsights into my project via Nuget. Then removed the actual reference from the project, but referenced the library in my ILMerge command as below:

Problem: I embedded a DLL into the exe through ILMerge, but this dll has no dependency relationship with the exe. Now I want to find the dll in the exe, what do I need to do？
Details:
I embedded all resources into the DLL, all logic code is EXE. I don't want to compile exe again, only modify the resource dll to change the exe's skin.
Then , I meet the problem.

I am working on a simple WPF app which makes use of two external DLLs, Nancy.dll and Nancy.Hosting.Self.dll to send some data over http. I'd like to keep the .exe file standalone so I'm trying to merge the two .dll files into the application. I tried multiple post-build merging methods such as NetZ and ILMerge, but both seem to have problems with wpf applications and didn't output a working executable.

There is this post which has multiple suggestions for going about this problem, although they all boil down to the same two things:

1. Use a post-build merger. This doesn't work well in my case.
2. Put the DLL into the application as an embedded resource, and make use of the AppDomain.CurrentDomain.AssemblyResolve event to load it when necessary.

The second option seemed promising: the event gets triggered, it finds the embedded resource, makes a datastream out of it and loads it as an assembly. I can verify the assembly is loaded in multiple ways:
Visual Studio's Debug -> Windows -> Modules shows the loaded assembly, and
AppDomain.CurrentDomain.GetAssemblies() also shows the assembly being loaded.

However, when it comes to using the assemblies (in this case calling Nancy.Hosting.Self.NancyHost host = new NancyHost();) I still get the following error:

I writing and open-source winforms app, and my program depends on another open-source project called ObjectListView.

ObjectListView is its own project in my solution and referenced as such, but its output is set as a .DLL.. It's just an enhanced ListView control. Is there any way that the project ObjectListView can be embedded in my own assembly without having to ILMerge or use some form of packer? (Defeating the purpose of an open-source project)

My initial thought was just to manually drop all the source files and whatnot into my own project, but that seems rather clunky and far from an idea solution.

PS; I did try searching for this but I didn't come across much that wasn't related to embedding DLLs into an output assembly.. Not merging projects like this. I apologize in advance if this question has been answered before.