Help while Migration from 4.4.1 to 5.0.0

[shoaibshakeel381]

Hello this is not an issue but more of a help request while migrating from 4.4.1 to 5.0.0.

In our code we've been using some methods from Castle.DynamicProxy.Internal namespace. Speciifically:

• AttributeUtil.CustomAttributeInfo CreateInfo(Type attribute, object[] constructorArguments)
• AttributeUtil.CustomAttributeInfo CreateInfo<TAttribute>()
• AttributeUtil.CustomAttributeInfo CreateInfo(CustomAttributeData attribute)

Now that AttributeUtil class is internal which methods should we use instead? Would CustomAttributeInfo.FromExpression(Expression<Func<Attribute>> expression) work here? Also how would we pass CustomAttributeData to it. Should we copy code from AttributeUtil class instead?

Also what are the alternatives to extending ClassEmitter and MethodEmitter?

[stakx]

All of those types and methods were never really intended for public consumption. They have been made internal without any intention of providing alternatives. If you rely on those types, perhaps you shouldn't update to version 5? Other alternatives: fork the project and make the required types public there; or reproduce the required members from version 4.4.1 in your own code for local usage?

[shoaibshakeel381]

I see. Let me explain what I am trying to do with these types.

In asp.net core controllers extend from ControllerBase class. And decalre [HttpVerb] and [HttpRoute] attributes on methods of controllers. But we want to instead have interfaces for our controllers where these attrbites are declared on method declarations. So we use castle.core to create interface proxy with target type, while copying interface attributes to generated proxy methods via ProxyGenerationOptions and set ControllerBase as base class.

This way we can distribute out interfaces/contracts via nugets. And client code knows how to build urls to access these remote apis while staying statically typed.

How does this kind of use-case be supported by castle.core 5.0.0? Also was there any special reasons for making these types internal?

[stakx]

How does this kind of use-case be supported by castle.core 5.0.0?

I'm afraid I cannot help you there, I am not familiar with ASP.NET Core. Your question is probably a little out of scope here; this repo is about the development of the facilities in the Castle.Core library.

All of that being said, you haven't really explained why you needed AttributeUtil methods and ClassEmitter / MethodEmitter to be public in the first place. What you described seems mostly related to ProxyGenerator and ProxyGenerationOptions, and those have remained unchanged.

Also was there any special reasons for making these types internal?

Yes. Making DynamicProxy internals actually internal gives us (maintainers) the freedom we need to refactor DynamicProxy. This was next to impossible when everything was public and everything immediately became a breaking change. It is a fairly difficult to understand code base as is, and in order to advance it, we need to be able to change & simplify things.

[shoaibshakeel381]

Thanks for the reply. I will see if I can simply use public interfaces for my scenarios.