1

I have a WPF application that uses a third-party library to perform a specific task; this library, in one of its methods, executes the statement Assembly.GetEntryAssembly().

If I run the WPF application on debug (by running a .Net exe for testing) the library works properly and Assembly.GetEntryAssembly() returns a reference to the assembly of the executable, but in production I have a different situation that causes me some problems.

In production, the WPF application is integrated with a VB6 application and programs are launched from a VB6 menu using the InteropFormLibrary; in this situation the library raise an exception because Assembly.GetEntryAssembly() returns null (it can't find the executable associated with the assembly).

My problem is that I can't change the code of the library because I don't have the sources available and I found the statement that throws the exception by dll decompiler and analyzing the method that was in the exception.

Now my question is: Is there any way to make sure that the method GetEntryAssembly doesn't return null? Can I assign or "circumvent" in some way?

Jens Björnhager
  • 5,632
  • 3
  • 27
  • 47
Luca Petrini
  • 1,695
  • 2
  • 28
  • 53
  • 1
    Is it possible to execute the WPF application within a new AppDomain? – Matten Apr 13 '12 at 09:05
  • I'm trying but there are some problems with the interop – Luca Petrini Apr 13 '12 at 09:41
  • The cleanest way is to contact the library developer as the MSDN states the fact that `GetEntryAssembly` returns `null` if called from unmanaged code. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly%28v=vs.100%29.aspx – Matten Apr 13 '12 at 09:46
  • Possible duplicate of [I need an alternative to \`Assembly.GetEntryAssembly()\` that never returns null](http://stackoverflow.com/questions/14165785/i-need-an-alternative-to-assembly-getentryassembly-that-never-returns-null) – Michael Freidgeim Apr 13 '17 at 08:29

1 Answers1

1

The easiest way would be getting the developer of the dll to fix his code to support being hosted in a native (like VB6 or C/C++) process.

That said, if its not possible, you can try to host your .NET side in a separate process, being based on a .NET exe. Since you are doing VB6 interop you'll probably already be using COM interop, so you could just switch to the out-of-process COM model. This way your .NET components can run inside a .NET exe and have an entry point assembly. I've already done that for similar reasons and it worked fine for me.

Zarat
  • 2,584
  • 22
  • 40
  • Yes...it seems the only solution, now I'm trying to contact the library developers to fix the issue – Luca Petrini Apr 13 '12 at 09:31
  • Another "temporary" and "dangerous" solution that I found is use MSIL disassembler (from prompt using ildasm command) to modify statement and then recompile dll (using ilasm command). It works, but it isn't the best choice. – Luca Petrini Apr 17 '12 at 12:39
  • 1
    In general it doesn't work that easily because you lose the strong name of the assembly, causing you to recompile anyone who references that assembly, possibly causing a huge chain reaction. – Zarat Apr 17 '12 at 14:07
  • Right...in fact I had to use "Strong Name Tool" to disable validation for dll (sn.exe -Vr) and this is not very safe. – Luca Petrini Apr 17 '12 at 14:47