Commercial Support for Windsor?

[al...@iherb.com]

Hi,

We are planning to use a Dependency Injection framework in our projects across our company. At this stage we are trying to decide which framwork to use. So far and in terms of functionality we prefer Castle Windsor to other options like Microsoft Unity. But the big problem from the corporate point of view seems to be the question of commercial support. 

So far we have had some technical problems that we solved using the material available online, but we are concerned that if we make a commitment to convert all of our codebase but later encounter another big technical problem we might not be as lucky. Is there any company out there that offers help and support services for Castle Windsor?

Thanks,

Ali Lahijani

The information contained in this message is the sole and exclusive property of iHerb Inc. and may be privileged and confidential. It may not be disseminated or distributed to persons or entities other than the ones intended without the written authority of iHerb Inc. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it. Do not open any attachments. Please delete it immediately from your system and notify the sender promptly by e-mail that you have done so.

[Luke Hutton]

I wouldn't worry about "commercial" support, this mailing list or stack overflow should be sufficient if you have any challenging questions.

If you decouple your code from use of a specific container, you should fairly easily be able to swap it out with whatever DI framework you wish to use. 

Read up on Mark Seemann (author of Dependency Injection in .NET):

"A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."

i.e. Ideally there should be minimal change when swapping out containers. Stick to constructor injection, etc. and you should be fine.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

Luke Hutton

[Jonathon Rossi]

Hi Ali,

I agree with Luke that as much effort as possible needs to go into keeping the container implementation details out of your application code, it helps for many reasons not just if you decide to change container. One of the big anti-patterns I see people getting trapped into is injecting Castle's IKernel or IWindsorContainer directly into their application code to directly call the container's Resolve or GetHandlers methods, you really want to be using factories for this sort of thing. A comment I read ages ago is you should treat your container like Hollywood does actors, don't call it it'll call you. You should just about never see Windsor being used in unit tests, otherwise your coupling is too high.

With that aside, depending on a third party library in any capacity introduces some level of coupling and risk as you still have to implement and test all that work at the composition root and everything else around the sides. As far as I know Hammett, Henry and the Castle Stronghold team no longer offer commercial support or consulting, and I'm not aware of anyone that provides a Castle specific offering. As Luke mentioned there are a few of us that are available on the mailing list and quite a few also on StackOverflow.

Unfortunately (or maybe fortunately) sometimes we all get busy, so my advice to getting a quicker response is to isolate the problem you are having from your application you can't share and try to reproduce it with a code snippet or little demo project you can share.

At the end of the day our source code is completely open, was started over a decade ago and contains no magic, so there are a lot of people out there that understand what Windsor does internally so you should never be in a position you couldn't fix a problem yourself with some guidance.

Jono

[al...@iherb.com]

Thanks Luke, Jonathon for the reply.

Fortunately that's the approach we have been taking, using factories and not relying on the container's API. Hopefully switching between DI framewroks will be easy.

But do you think it's a bad idea to have each assembly define its own IWindsorInstaller, instead of a big installer at the Composition Root? Or, should we have multiple installers but keep them in the assembly that contains the Composition Root? Currently our installers are defined in their respective assemblies and it may be possible for developers to reference the container API without us knowing...

Thanks,

On Wednesday, December 31, 2014 4:31:55 AM UTC-8, Jonathon Rossi wrote:

Hi Ali,

I agree with Luke that as much effort as possible needs to go into keeping the container implementation details out of your application code, it helps for many reasons not just if you decide to change container. One of the big anti-patterns I see people getting trapped into is injecting Castle's IKernel or IWindsorContainer directly into their application code to directly call the container's Resolve or GetHandlers methods, you really want to be using factories for this sort of thing. A comment I read ages ago is you should treat your container like Hollywood does actors, don't call it it'll call you. You should just about never see Windsor being used in unit tests, otherwise your coupling is too high.

With that aside, depending on a third party library in any capacity introduces some level of coupling and risk as you still have to implement and test all that work at the composition root and everything else around the sides. As far as I know Hammett, Henry and the Castle Stronghold team no longer offer commercial support or consulting, and I'm not aware of anyone that provides a Castle specific offering. As Luke mentioned there are a few of us that are available on the mailing list and quite a few also on StackOverflow.

Unfortunately (or maybe fortunately) sometimes we all get busy, so my advice to getting a quicker response is to isolate the problem you are having from your application you can't share and try to reproduce it with a code snippet or little demo project you can share.

At the end of the day our source code is completely open, was started over a decade ago and contains no magic, so there are a lot of people out there that understand what Windsor does internally so you should never be in a position you couldn't fix a problem yourself with some guidance.

On Wed, Dec 31, 2014 at 6:32 PM, Luke Hutton <lukeh...@gmail.com> wrote:

I wouldn't worry about "commercial" support, this mailing list or stack overflow should be sufficient if you have any challenging questions.

If you decouple your code from use of a specific container, you should fairly easily be able to swap it out with whatever DI framework you wish to use. 

Read up on Mark Seemann (author of Dependency Injection in .NET):

"A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."

i.e. Ideally there should be minimal change when swapping out containers. Stick to constructor injection, etc. and you should be fine.

On Tue, Dec 30, 2014 at 5:27 PM, <al...@iherb.com> wrote:

Hi,

We are planning to use a Dependency Injection framework in our projects across our company. At this stage we are trying to decide which framwork to use. So far and in terms of functionality we prefer Castle Windsor to other options like Microsoft Unity. But the big problem from the corporate point of view seems to be the question of commercial support. 

So far we have had some technical problems that we solved using the material available online, but we are concerned that if we make a commitment to convert all of our codebase but later encounter another big technical problem we might not be as lucky. Is there any company out there that offers help and support services for Castle Windsor?

Thanks,

Ali Lahijani

The information contained in this message is the sole and exclusive property of iHerb Inc. and may be privileged and confidential. It may not be disseminated or distributed to persons or entities other than the ones intended without the written authority of iHerb Inc. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it. Do not open any attachments. Please delete it immediately from your system and notify the sender promptly by e-mail that you have done so.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

Luke Hutton

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Jono

[Jonathon Rossi]

I think that depends on how big your application is. It would be best to keep it at the composition root and use convention driven registrations to reduce the amount of code you have to write and maintain, especially that component lifetimes should be determined by how they are used by the composition root not how they are used individually. However if you've got a really big application this can sometimes get unwieldy and hard to maintain. If your application is composable, then the registrations should come along with each "plugin".

You could always write a static analysis check to ensure that Windsor (or any other container) doesn't get used directly by classes that don't implement IWindsorContainer. Personally I'd just write a unit test using the Mono Cecil library to check this (you could probably do this check with just System.Reflection checking constructor arguments and public property types), but there are other tools like NDepend that you could use without writing code.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Jono