I've hit a snag while combining the Onion Architecture with a Windows Forms UI layer. The issue is that my IoC config method is never hit. IoC setup takes place in the dependency resolution assembly:
Project.Core
Project.Infrastructure
Project.UI <- Startup project
Project.DependencyResolution <- IoC configuration
And I'd like my UI layer to depend on nothing except Project.Core
.
In my web projects where I've used this architecture I've used WebActivatorEx and OutputTo to bootstrap my IoC. Since I'm familiar I decided to use the same here, but it's not behaving as expected. I'm not sure if I'm the problem or Windows Forms is the problem so here's my setup:
In Project.DependencyResolution:
[assembly: WebActivatorEx.PreApplicationStartMethod(
typeof (IocConfig), "RegisterDependencies")]
public class IocConfig
{
public static void RegisterDependencies() {
// this is never executed
}
}
OutputTo's OutputTargets.txt:
..\Project.UI\bin
In Project.UI:
static class Program
{
static void Main() {
WebActivatorEx.ActivationManager.RunPreStartMethods();
Application.Run(...);
}
}
OutputTo copies DependencyResolution's
DLL file over to Ui's
bin correctly, but IocConfig.RegisterDependencies
never runs.
So how can I setup IoC from its own assembly where the Windows Forms project is the startup project?
Just tested this with WebActivatorEx 2.0.0.5 (the latest in NuGet). Works fine. Checked by printing something to the console in
RegisterDependencies
.In any case, it doesn't have anything to do with it being a WinForms application (could be a console app, it should still work).
The only thing that crosses my mind now is that your UI assembly is not next to the other assemblies (including WebActivatorEx). I checked its source code and it relies on it being there, since that's where it looks for all DLLs. Can you make sure the assemblies are where they're supposed to be?
Additionally, WebActivatorEx has this in their source code:
So, if you don't find the cause in good time I suggest getting the WebActivatorEx source code and use it to debug the behavior. You will also be able to see what assemblies it loads in
ActivationManager.RunPreStartMethods
(it's actually the private staticAssemblies
property).