Can a C# .dll assembly contain an entry point?

Question

My goal is to create an executable that will start a shadow copied application. The trick is, I want this starter program to have no external dependencies and not have to contain any knowledge about the program it has to start.

I also want it to be the only executable in the directory. In other words, I want it to "run" a .dll assembly not an .exe assembly. (I can require that the name of the .dll file being loaded into a new AppDomain be the same everytime, like Main.dll or something like that.)

It looked like AppDomain.ExecuteAssembly would do exactly what I wanted. It says it will start execution at the "entry point specified in the .NET Framework header.".

When I try to use that function I get the error "Entry point not found in assembly 'DllApp'".

The starter program I have, just trying to run the assembly:

static void Main()
{
    AppDomain domain = AppDomain.CreateDomain( "DllApp" );
    domain.ExecuteAssembly( "DllApp.dll" );
}

The application code, in a .dll file, with a default entry point:

static class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault( false );
        Application.Run( new Form1() );
    }
}

This page on Main() functions says that "Libraries and services do not require a Main method as an entry point". It doesn't say they cannot have a default entry point either.

I have tried all the various permutations of public/private static void main, an int return type, string[] args as arguments, with a namespace, no namespace, static/non-static class, etc.

I was able to change my code to inherit from MarshalByRefObject and then use CreateInstance to create an object, but that seems like it will more tightly couple the starter to the program it is supposed to start. If I could use ExecuteAssembly, the application being started would just need a static void Main, and that is really simple and hard to mess up.

Is it possible for a .dll assembly to have a default entry point, and for ExecuteAssembly to find it, or do I just have to resign myself to going another route?

Answer 1

You can compile a .NET app as an exe (which is an assembly) and rename it to a .DLL and it will act as a normal .NET .dll assembly. It will then have your Entry point.

Answer 2

I found the advice not so easy to follow. After some experimenting this is how I came to success:

I created a console application with a simple main and included the rest of the code from my original DLL. Below is a simplified program which includes a DLL:

namespace FIT.DLLTest
{
  public class DLLTest
  {
    [STAThread]
    static void Main(string[] args)
    {
      int a = 1;
    }

    public DLLTest()
    {
      int b = 17;
    }

    public int Add(int int1, int int2)
    {
      return int1 + int2;
    }
  }
}

After compilation I renamed the generated .exe to a .DLL.

In the mother program, which uses the DLL I first added the DLLTest.dll as a Reference, then I added the code to execute the DLL.

namespace TestDLLTest
{
  class TestDLLTest
  {
    static void Main(string[] args)
    {
      AppDomain domain = AppDomain.CreateDomain( "DLLTest" );
      domain.ExecuteAssembly( "DllTest.dll" );

      DLLTest dt = new DLLTest();
      int res2 = dt.Add(6, 8);
      int a = 1;
    }
  }
}

Violà I could execute and add a breakpoint in the DLLTest.Main method and see that I could invoke the Main of DLLTest. Thanks for the discussion folks!

Answer 3

Short answer is no. a .DLL file is a dynamically linked library which is code called by another library. I guess what Keith said would technically work.. you could probably rename it to what ever you want even .txt or .pdf as long as you start the application in the proper manner. The main question I have is this; What are you trying to do?? Unless you're trying to write malware why would you want to do this? Not that I condone the writing of malware for bad purposes but I know people like to experiment in their own lab so I for one don't condemn it. If you're writing malware something like c++, c or assembler might be a better bet I guess C# could get the job done but meh...