3

I have not had any luck merging wpf assemblies using ILMerge.

Justin
  • 2,399
  • 4
  • 31
  • 50
  • Possible duplicate of [Merging dlls into a single .exe with wpf](https://stackoverflow.com/questions/1025843/merging-dlls-into-a-single-exe-with-wpf) – StayOnTarget Jul 05 '18 at 11:27

3 Answers3

3

I would imagine that the main issue you are having when merging WPF assemblies is that the PackURIs for resources are not being changed.

If you are able to refactor your resources to a single assembly that is not merged or otherwise fix up the PackURI's in your assemblies then your merged assemblies should work.

Joe Kuemerle
  • 6,338
  • 1
  • 23
  • 18
3

Mike Barnett's ILMerge page at http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx refers to this note from Jeffrey Richter:

http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx

This section discusses how to embed your application’s dependent DLLs inside your EXE file, simplifying deployment by allowing you to distribute just one physical file.

In essence you bundle your dependent DLLs as resources into your EXE and load on demand by hooking your AppDomain’s ResolveAssembly event.

Jeremy McGee
  • 24,842
  • 10
  • 63
  • 95
2

I don´t know why ILMerge has a problem with WPF Assemblies, but there is another tool to pack and merge assemblies. Take a look at .NETZ.

Jehof
  • 34,674
  • 10
  • 123
  • 155
  • I tried out .NETZ but unfortunately it doesn't seem to work with my .NET 4 WPF app. I'm using it just to merge assemblies (not compress them) but the built app just throws an exception when run. – devios1 Aug 02 '10 at 11:51
  • Just a heads up to anyone out there thinking they should try it with 3.5 WPF.. I tried .NETZ on a 3.5 WPF app and it reports it "Cannot determine EXE's subsystem (default is GUI windows EXE) The packed application will fail!". – Adam Caviness May 29 '12 at 19:10