Windsor config xml or code?

[bdaniel7]

Hello,

Is there a recommended (or best) way to configure Windsor?

I think that xml config has the advantage that I can just deploy the
"new" implementations, modify the bindings in the xml and restart the
app.
While with code I have to recompile and redeploy the entire app.


Your thoughts?

Daniel

[Ryan Langton]

I far prefer configuring the container inside code.  Leave stuff that network admins should be changing in the config, stuff that developers should change in the code.  This has the advantage of keeping your config files clean as well.  Not having to recompile and redeploy the app doesn't really buy you that much IMO.

Ryan

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.

[Maximilian Raditya]

I think that certainly depends on your needs.

 

In my experiences, at the first time I used to put Windsor config in app.config because I read that I can configure things without recompiling app, just like what you said. But then, after a period of experience and evaluation, I observed when I changed the config, I also had to modify the code. I haven't found a scenario where I can change to config only without recompile app. Also, configuring things in app.config is bit pain in the ass since I don't have compile-time checking, especially when it involves generic types configuration. Based on those reasons, I decided to move all config from file to code. And importantly, I feel better now :D.

 

 

 

 

 

--
Regards,

Maximilian Haru Raditya

 

 

[Tomek Pluskiewicz]

Agreed. There aren't many situations where you can change xml config without modifying the code.

The only one that comes to my mind is when you want to switch 2 implementations of a service. If you have implemented both version in advance, simply change the relevant pieces of your config and you're done. Still the need to change the code (create extra implemntations) doesn't go away. 

On the other hand, you could implement new classes in separate assemblies. That way you won't have to recompile your core solution. It could save a reasonable amount of time in case of big projects.

Personally I ususally leave xml configuration simply to override default dependencies and default values for injected properties. Vast amount of configuration goes to C#. As Maximilian wrote, you benefit from compile-time checking. It really does spare one a lot of frustration ;)

Regards

Tomasz