Support for Castle Windsor DI Container Integration in Prism

[TaviTruman]

Dear Prism Development Team,

I request official support for the Castle Windsor Dependency Injection (DI) Container within Prism. This request stems from our longstanding use of Castle Windsor in conjunction with Prism and the challenges we are currently facing with maintaining this integration after the release of Prism 9.

Background:

Longstanding Usage: Our team has successfully utilized Castle Windsor as our DI container with Prism for over ten years. This combination has served us exceptionally well, allowing us to maintain a robust and scalable application architecture.

Self-Maintained Integration: Up until the release of Prism 8, we managed to maintain our integration with Castle Windsor independently, ensuring compatibility with each Prism release. However, with the release of Prism 9, we have encountered significant challenges in doing so due to several factors:

Enhanced Design and Technical Constraints: The enhancements and changes in Prism 9 have introduced new design patterns and technical constraints that make it increasingly difficult to adapt Castle Windsor to the latest version.

Limited Source Code Access: Portions of the Prism source code critical for DI integration are no longer publicly accessible, further complicating our ability to maintain this integration independently.

Request:

Given Castle Windsor's widespread usage in the .NET community and proven reliability, we kindly request that the Prism team consider including official support for it in future releases. This would benefit our team and support other developers who rely on Castle Windsor alongside Prism.

Benefits:

Community Support: Official support for Castle Windsor would provide a standardized and reliable solution for the broader Prism community, reducing the need for individual teams to maintain separate integrations.

Enhanced Compatibility: With official support, Castle Windsor users would be assured of compatibility with future Prism releases, allowing them to take full advantage of new features and improvements without compromising their DI strategy.

Conclusion:

Adding official support for Castle Windsor would be a valuable enhancement to the Prism framework, aligning with its goal of providing flexible and powerful development tools for the .NET ecosystem. We appreciate your consideration of this feature request and are happy to provide additional information or assistance.

Thank you for your continued work on Prism and attention to this request.

Best regards,

Tavi Truman
CTO
RocketUrBiz, Inc

[dansiegel]

@TaviTruman out of curiosity what is it that you get from Castle Windsor that drives your continued use over updating your code to use the Prism Container Abstractions which really just future proofs your app since your code would then not care what backs it?

Also have you looked at the benchmarks? It's not a particularly fast DI Container. DryIoc, Grace, Microsoft and even Unity are all more performant containers.

[TaviTruman]

We've been using castle Windsor for a decade now, the code stable and our performance has never been an issue for us. We have been following the Prism design implementation pattern for DI containers for a while now the use the same ones to implement the currently supported DI containers. We did so with Prism 8 source. I did forward our current Prism 8 implementation to Brian. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Dan Siegel ***@***.***> Sent: Friday, August 30, 2024 8:02:13 AM To: PrismLibrary/Prism ***@***.***> Cc: Tavi Truman ***@***.***>; Mention ***@***.***> Subject: Re: [PrismLibrary/Prism] Support for Castle Windsor DI Container Integration in Prism (Issue #3243) @TaviTruman<https://github.com/TaviTruman> out of curiosity what is it that you get from Castle Windsor that drives your continued use over updating your code to use the Prism Container Abstractions which really just future proofs your app since your code would then not care what backs it? Also have you looked at the benchmarks<https://github.com/danielpalme/IocPerformance>? It's not a particularly fast DI Container. DryIoc, Grace, Microsoft and even Unity are all more performant containers. — Reply to this email directly, view it on GitHub<#3243 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABLN3DFJVBS4CSZLUKLHXHTZUCCPLAVCNFSM6AAAAABNLE5S7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRRGUZTOOBXGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>