Dependencies that are never merged

SmartAssembly will never merge or embed the following types of dependency:

• Dependencies containing mixed managed/unmanaged code
• Primary Interop Assemblies
• Dependencies signed using Microsoft's strong-naming key (PublicKeyToken 31bf3856ad364e35)

If the Microsoft assembly mentioned in the last item is not a Framework Class Library, a potential workaround is to use ildasm.exe to dump the IL to a folder and reassemble it using ilasm.exe, signing it with your own strong-naming key.

Merging WPF dependencies

Your program might not work if you merge a dependency containing WPF, and name mangling is enabled for the dependency. In this case, do not apply name mangling to the dependency.

Third-party DLLs

You may not be able to merge a third-party DLL. In some cases, the DLL has integrity protection and will fail to load if the code is changed, which happens when the dependency is merged with the main EXE. If this happens, embed the dependency instead of merging it (see Embedding dependencies).

Complex merging

Merging may fail if your application has a complex architecture and you have not merged all dependencies together. A typical example of when merging may cause your application to fail is when you are using a plug-in, as in the case below:

Assume that both MainExe.exe and plugin.dll reference shared.dll, and also that MainExe.exe loads plugin.dll.

If you merge shared.dll into MainExe.exe, MainExe.exe and plugin.dll will not be able to communicate using types from shared.dll. This is because the fully-qualified names of those types will have changed from "shared, MyNamespace.MyType" to "MainExe, MyNamespace.MyType".

The solution is to embed shared.dll instead of merging it (see Embedding dependencies).

For projects where dependency embedding is not supported (XNA), you must keep the dependency separate and distribute the DLL with your application.

For more information about this issue, see The assembly [assembly] is being merged, but the dependent assembly [assembly] isn't. Either merge both assemblies, or neither.

The wrong version of the dependency is merged

For more information, see How SmartAssembly searches for dependencies.