3

I got the following error when executing an unmanaged assembly:

Could not load file or assembly 'file:///C:\Program Files\Maxima-5.21.1\lib\maxima\5.21.1\binary-gcl\maxima.exe' or one of its dependencies. The module was expected to contain an assembly manifest.

What should I do? Is it impossible to execute an unmanaged assembly using AppDomain?

Rob
  • 45,296
  • 24
  • 122
  • 150
Second Person Shooter
  • 14,188
  • 21
  • 90
  • 165

3 Answers3

6

  1. AppDomains are pure managed construct. Any unmanaged code running in the process is unaffected by the AppDomain boundaries and has full access to all process memory, data and code.

  2. Unmanaged assemblies are not executed the same way managed assemblies are. The process of loading the assembly, and finding and executing the entry point for the unmanaged assembly is different than the one for managed assemblies. Hence the particular failure you get.

  3. If you want to execute functions exported by an unmanaged dll, you should use P/Invoke, which will ensure that the assembly is loaded using the right mechanism and the proper entry point is invoked.

  4. You can't run code from an executable in the same process, as in your scenario above; you can only start a new process.

Franci Penov
  • 74,861
  • 18
  • 132
  • 169
2

You're correct, an un-managed DLL cannot be loaded into an AppDomain. You need to use P/Invoke to call methods in the DLL.

Rob
  • 45,296
  • 24
  • 122
  • 150
  • My assembly is executable. I can execute it using Process class. However, using Process will limit the scalability that I want to avoid. – Second Person Shooter Jul 30 '10 at 06:09
  • @Xport, there have been other questions on here recently asking somehting very similar. Unofortunately there is *no* way to load another executable into an AppDomain and run it, particularly if it's not a .net executable. – Rob Jul 30 '10 at 06:12
  • Injecting code in the same process in a new appdomain instead of starting a new process is less scalable. Your code will be more resource constrained; it'll be less reliable, as any crash in one appdomain can bring the whole process down; and the OS scheduler rules for scheduling threads are different than for scheduling processes. – Franci Penov Jul 30 '10 at 06:13
  • @Rob - technically, it is possible, but requires very explicit knowledge of the OS process load and start up procedure in order to duplicate it in-process. – Franci Penov Jul 30 '10 at 06:17
  • Franci Penov's statement: "Injecting code in the same process in a new appdomain instead of starting a new process is less scalable." <=== it seems contrary to what I read saying that AppDomain is usefull to expand scalability whenever you want to instantiate many executable assemblies. – Second Person Shooter Jul 30 '10 at 06:27
  • @Franci - and thus I assume making it OS/Service Pack/Hotfix dependent? – Rob Jul 30 '10 at 06:27
  • @xport - Yes, AppDomains do have their advantages, when it comes to speed of starting a new instance, IPC communications and couple others. However, there's cost as well - constrained in the memory address space of one process (~3GB on 32-bit OS), can't load-balance on multiple machines, no unmanaged code isolation, can't use standard OS activation on demand mechanisms, and so on. Hence, how scalable using AppDomains vs. processes is depends really on the particular scenario. – Franci Penov Jul 30 '10 at 07:46
2

executing an unmanaged assembly:

First - this does not exist. An "Assembly" (which has the physical form aof a .DLL file) is ALWAYS managed. An unmanaged DLL is simply not an assembly PER DEFINITION. DLL's were around WAY before .NET and the term Assembly is SPECIFIC for a managed .NET DLL in this context.

Is it impossible to execute an unmanaged assembly using AppDomain?

Exactly. Which part of the vast documentation indicated otherwise?

You can use:

  • P/Invoke to make calls out into a DLL. This sometimes is REALLY hard as the .NET managed API is not so elegant for certain unmanaged structure constructs.
  • Use C++/CLI to create an assembly that references the DLL. Managed C++ is great for bridging the gap.
Jack Ukleja
  • 13,061
  • 11
  • 72
  • 113
TomTom
  • 61,059
  • 10
  • 88
  • 148
  • 1
    umh, that's slightly incorrect. Windows side-by-side engine (Fusion) works with unmanaged code as well, and they are still called assemblies. Assembly is essentially a set of one or more binaries that represent a code unit with single identity. Whether these are managed or not is irrelevant. – Franci Penov Jul 30 '10 at 06:24