Entry Point of a DLL

Question

I've a c# .net WPF application, now i need to register something(basically kernel of NInject IoC pattern) that has been used by the BLL and DAL layer.

I want to know the entry point or something like that for the dll where i could put that code(kernel registration).

For WPF section, i use App.xaml.cs , for WCF section i use Global.asax.cs as they are the entry point of these things. But what about standalone dlls , what is their entry point.

One approach is that, i could add a static class in my dll which fulfil this purpose and from app.xaml.cs i call this method of BLL and register my kernels. But this seems more like a workaround than approach.

Please guide me for something more to the point and logical.

Answer 1

Container configuration is done in the composite root of your application (The point where your code is called the first time). As you already said, in case of WPF this is the App.xaml.cs. Here you register the components of ALL layers. Preferably you have to UI code in another assembly than the App.xaml. This way the creation of the spplication is completely separated from the execution of the code.

I suggest to read Mark Seemans book where this is described in detail.

Answer 2

C# doesn't allow to run code on assembly loading, and static class constructors are lazily executed on first access to the class. However the CLR supports a static "assembly constructor", so to speak, which is executed when the assembly is first loaded. Mind you, references are still loaded lazily unless you put in special attributes to mark a referenced assembly to be loaded eagerly.

If you want you could put a static constructor into the assembly module through ildasm/ilasm. You could probably make some scripts to automate this on build.

I didn't do this myself yet, so I can't give any examples. Though if you consider doing it I can maybe dig up some links.

Answer 3

It almost sounds like your wanting a "plug-in" model where the app can dynamically discover components that are available. If so, then MEF might be a better option.

MEF seems to work well for cases where the app might not know about all it's dependencies ahead of time. Dependency injection, on the other hand, assumes that your app is fairly knowledgeable about these dependencies ahead of time.

I don't know if this is what you're after, but it might be worth a look.