Windsor Installer best practices?
863 views
Skip to first unread message
Scott_M
Sep 11, 2012, 7:37:50 PM9/11/12
to castle-pro...@googlegroups.com
We are writing a .NET 4.5 WCF service hosted as a Windows NT service and plan to use latest castle windsor / wcf facility for dependency injection. The WCF service will have multiple dependencies:
1. Business Logic Components (INT and IMPL assemblies)
2. Data Access Layer Components (INT and IMPL assemblies)
3. Logging Components (INT and IMPL assemblies)
4. Various utilities (INT and IMPL assemblies)
For component registration, we have used xml configuration for similar projects in the past. However, this was slow, tedious, fragile, and not very re-usable for subsequent projects. What is best practice for structuring installers for a project of this nature? Do you write one giant installer project to cover 1-4? Do you write separate installers for each assembly implementation? How do you deal with installer dependencies so they are installed in the proper order? How do you prevent from installing a component twice?
Krzysztof Kozmic
Sep 11, 2012, 7:41:49 PM9/11/12
to castle-pro...@googlegroups.com
Does that answer the question?
--
Krzysztof Kozmic
--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-users/-/iVTa2_kh6DkJ.
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.
Berke Sokhan
Sep 12, 2012, 3:37:18 AM9/12/12
to castle-pro...@googlegroups.com
Blog post was a good answer in principle but, I want to add in my experience that gethering installers into one project instead of disturbuting to their target libraries is more managable.
If you gather all installers (but keeping in different files for their targets) in one project, you dont have to distribute Castle dll references all over your projects. And when you update with a new castle version making changes become easier (I know NuGet makes it easy to update across different projects, but still...) And when you want to change your container, or its lets say Castle IWindsorInstaller interface signature changed making changes will be easier...
Scott_M
Sep 12, 2012, 11:00:15 AM9/12/12
to castle-pro...@googlegroups.com
One question though regarding registration of components via XML config versus Windsor Installers....
In our previous projects, we had this massive config file with numerous components registered in no particular order. It just seemed to work (Component A depended on Component C but component A was registered before component C).
Are installers the same way (they just work without regard to order) or must you invoke the installers based upon your class dependency graph?
Thanks for the great tips.
On Wednesday, September 12, 2012 2:37:40 AM UTC-5, Berke Sokhan wrote:
Blog post was a good answer in principle but, I want to add in my experience that gethering installers into one project instead of disturbuting to their target libraries is more managable.If you gather all installers (but keeping in different files for their targets) in one project, you dont have to distribute Castle dll references all over your projects. And when you update with a new castle version making changes become easier (I know NuGet makes it easy to update across different projects, but still...) And when you want to change your container, or its lets say Castle IWindsorInstaller interface signature changed making changes will be easier...
A step towards architectural-POCO you may say :)
2012/9/12 Krzysztof Kozmic <krzyszto...@gmail.com>
Does that answer the question?--Krzysztof Kozmic
On Wednesday, 12 September 2012 at 9:37 AM, Scott_M wrote:
We are writing a .NET 4.5 WCF service hosted as a Windows NT service and plan to use latest castle windsor / wcf facility for dependency injection. The WCF service will have multiple dependencies:1. Business Logic Components (INT and IMPL assemblies)2. Data Access Layer Components (INT and IMPL assemblies)3. Logging Components (INT and IMPL assemblies)4. Various utilities (INT and IMPL assemblies)For component registration, we have used xml configuration for similar projects in the past. However, this was slow, tedious, fragile, and not very re-usable for subsequent projects. What is best practice for structuring installers for a project of this nature? Do you write one giant installer project to cover 1-4? Do you write separate installers for each assembly implementation? How do you deal with installer dependencies so they are installed in the proper order? How do you prevent from installing a component twice?--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-users/-/iVTa2_kh6DkJ.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-users+unsub...@googlegroups.com.
--
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-users+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages