1

I've got a .net windows service application that calls out to a bunch of other dlls of our own creation. However, all of these dlls were created for x86, and we've since moved on to Any CPU (on x64 environments). Sadly, thanks to .NET's delayed loading functionality, many of these dlls are not loaded unless we exercise some rare and somewhat complicated code paths. The net result? We get incorrect format exceptions days or weeks after deploying code.

I want to know if there's a way to force .NET to fully load all assemblies that it directly references so that I can see such incompatibilities without manually poring through the dozens of projects from which these dependent dlls were created, or worse, doing full regression tests to force all of the assemblies to be loaded.

Addendum: Even if there's an easier way to resolve my specific x86-dlls-in-a-x64-environment issue, I'm still interested in seeing if there's a way to force the environment to load all of its dependencies. You never know when it'll come in handy! :)

EDIT: These are all managed DLLS, and I actually have used reflection to triage the issue in production. However, in a development environment, it suffers from the same problem the other options have: manually traversing all of the DLLs in one way or another.

bvoyelr
  • 920
  • 8
  • 11
  • I'd cheat and use reflection - iterate through each referenced assembly that isn't from MS, find a class inside that assembly and instantiate it. It's not elegant but it would force all the assemblies to load immediately. That said, I do think you're approaching this whole problem from the wrong direction. – Basic Oct 19 '12 at 14:15
  • Do you mean managed or unmanaged DLL? – Alvin Wong Oct 19 '12 at 14:17

1 Answers1

0

One way is to statically link the libraries using ILMerge to merge them into the executable itself. otherwise the whole point of DLLs is that they are not evaluated until they are used in code. see The .NET equivalent of static libraries?

of course you could just run a diagnostic sequence on app load that touches some aspect of all your dlls, so at least you know on load what is there and what won't work.

Community
  • 1
  • 1
Frank Thomas
  • 2,434
  • 1
  • 17
  • 28
  • Finally got around to playing with IL Merge, and it seems to be doing exactly what I don't want it to do: passively detect that one of the assemblies is x86 and make the resulting output assembly x86. – bvoyelr Oct 29 '12 at 19:34