search

castleproject / Core

Castle Core, including Castle DynamicProxy, Logging Services and DictionaryAdapter
http://www.castleproject.org/
Other
2.2k stars 467 forks source link

v4 to v5 upgrade when previously relying on Castle.DynamicProxy.Internal #681

Open rcocks-hl opened 2 weeks ago

rcocks-hl commented 2 weeks ago

Hello,

Is there a guide for transitioning from version 4 to 5 for users that previously used Castle.DynamicProxy.Internal ?

I see in the release notes they were removed, but cannot find guidance on how to deal with previous uses of ModuleBuilder and methods such as ObtainDynamicModule?

Kind regards,

stakx commented 2 weeks ago

There is no such guidance, and there likely won't be any in the future either, because those types were in all probability never intended to be used by external code... that's what the Internal namespace bit means after all.

If you rely on these bits of internal machinery, then probably stay with v4?

Out of curiosity, why did you need ObtainDynamicModule in the first place? Perhaps there's a better solution for your use case than going back to that...

rcocks-hl commented 2 weeks ago

Thank you for getting back to me.

An alternative approach would be fine. Our use case is building a dynamic proxy using ModuleBuilder.

I'll have to consult with management before getting permission to share detailed source code, but we were using ModuleBuilder to build the proxy types in a way that they could be compiled and injected into the assembly containing the unproxied types.

Looking at the documentation, I suspect IProxyBuilder may well be suitable for this use instead, I was just hoping there would be a migration guide I could follow, but if there isn't I'll be happy to research some more independently.

stakx commented 2 weeks ago

Yes, if you just want to build proxy types (as opposed to proxy objects) then IProxyBuilder and its implementations would be what you want to use. Those types are part of the public API.

There's one "wart" to that approach: there's nothing in DynamicProxy's public API that tells you how exactly to instantiate the proxy types built by implementations of IProxyBuilder. For instance, depending on the type of proxy type built (class vs. interface, with vs. without target, etc.) the proxy type ctor will take different arguments, in slightly varying ordering. The "knowledge" of how to instantiate these types is essentially buried within the ProxyGenerator implementation. That's something we should probably have remedied long ago (e. g. by exposing some kind of ProxyActivator helper).

Nevertheless, building proxy types via IProxyBuilder implementations is the closest thing you currently have to building proxy types without resorting to unsupported tricks.