Dave Donaldson

I'm posting this to save someone else an hour or two worth of work. Awhile back I was working on a problem where I needed to dynamically create new AppDomains in a given client application, where in each new AppDomain I needed to load an assembly. There are a few different ways to accomplish this task, and one of the ways I investigated was using ExecuteAssembly.

To call ExecuteAssembly, you first need to get a reference to an AppDomain object, by either getting the current AppDomain (AppDomain.CurrentDomain) or by creating a new AppDomain (AppDomain.CreateDomain). Once you have that, you simply invoke the ExecuteAssembly method on the AppDomain object, as such:

AppDomain newDomain = AppDomain.CreateDomain(“NewDomain“);
newDomain.ExecuteAssembly(“SomeAssembly.exe“);

Notice the extension of the assembly that is passed to the ExecuteAssembly method: it's an EXE, not a DLL. I kept running into problems because I wanted to dynamically load DLL assemblies and execute the stuff inside them. For those unaware, there is one primary difference between an EXE and a DLL: EXEs have entry points, DLLs do not (more on that later). Once I remembered that little fact, I realized ExecuteAssembly would not work in my situation.

My issue here is I feel the name of the ExecuteAssembly method is a little misleading. Afterall, an EXE written in .NET and a DLL written in .NET are both assemblies. So it's easy to see how the name ExecuteAssembly could be mistaken as something that can execute *any* .NET assembly type. And the exception that gets raised is a COMException, which is also a bit misleading. Why doesn't ExecuteAssembly throw an InvalidAssemblyTypeException or something like that? That makes more sense to me.

I also went back through some of the MSDN documentation and although it does say “... assembly begins executing at the entry point specified ...“, it does not explicitly state that ExecuteAssembly will not work with DLLs. I know it seems very much like a minor detail, but I think having that in the documentation would help clear up the confusion of the method name itself. Or it could be that I simply forgot about entry points for an hour or so and decided to blog about it.

As for entry points, how would a developer know that DLLs do *not* have entry points (yes, there are plenty of devs unaware of entry points)? Where would they find that information? I mean, it's not really documented or explicitly stated anywhere, at least no place that I can remember at this moment (if there is, please comment so I can refer people to it). The answer is in the IL.

To see this, create a new Windows application project in VS.NET, compile it, then open up the assembly with ILDASM. Navigate to the Main method and view its IL. The first thing you'll see is .entrypoint. Now, go to the project properties and change it's output type from Windows Application to Class Library. Recompile, open in ILDASM, and look at the IL for the Main method again. Notice the .entrypoint line is gone, yet all the other IL is exactly the same. Above all else, that's the difference between EXEs and DLLs.