Can static methods be intercepted with Castle DynamicProxy?
And if so, how?
No, Castle DynamicProxy can only proxy types and members that you could have written proxies for by hand, it uses runtime code generation and must comply with the constraints of the CLR.
The DynamicProxy documentation describes the two general forms of proxy objects it supports, inheritance and composition-based.
Related
I am using NSwag to create typed http clients with interfaces and registering them with DI using AddHttpClient() and injecting them where they need to be used in calling APIs.
I read about some limitations of the httpclient class such as socket exhaustion & not detecting dns changes and the recommendation to use httpClientFactory and its CreateClient method to create httpclients to alleviate these limitations.
I haven't used the httpClientFactory in a new app that I started working on.
It's using .NET 6 and my question is.. Is httpClientFactory still a recommended way to use explicitly or is it used implicitly in DI because of the use of AddHttpClient() and I don't have to worry about those limitations? I didn't see a clear direction on how to use typed clients, or http clients in general, and whether .NET 6 has introduced improvements in this area.
HttpClient can be injected only inside typed clients
For other usages IHttpClientFactory is required
As the docs state for either case underlying infrastructure (HttpMessageHandler) is managed by the framework so in general you don't need to worry about it (unlike when creating and managing HttpClients manually which could lead to incorrect disposal).
Using typed clients registered via HttpClientFactoryServiceCollectionExtensions.AddHttpClient<TClient> handles IHttpClientFactory for you. When adding typed client internally AddTypedClientCore is called which registers resolver via AddTypedClientCore, which uses IHttpClientFactory:
IHttpClientFactory httpClientFactory = s.GetRequiredService<IHttpClientFactory>();
HttpClient httpClient = httpClientFactory.CreateClient(builder.Name);
ITypedHttpClientFactory<TClient> typedClientFactory = s.GetRequiredService<ITypedHttpClientFactory<TClient>>();
return typedClientFactory.CreateClient(httpClient);
Related:
Make HTTP requests using IHttpClientFactory in ASP.NET Core
Use IHttpClientFactory to implement resilient HTTP requests
Does MOQ give access to Castle's DynamicProxy generation? Or are there configurable static methods or something in the Castle namespace that would allow me to tune MOQ's proxy gen behavior?
Some Background
I am Mocking a WCF Service endpoint (IWhatever). WCF automatically adds Async call back options for methods (e.g. IWhatever.DoWork() is also realized as IWhatever.DoWorkAsync()).
I'm looking to use the Mock<IWhatever> object while self-hosting this service mock'd; basically spoof this external web service to my system. However, when [self-hosted] WCF tries to create a DoWorkAsync() method; it already exists... which ultimately throws errors when opening the self-hosted/mock'd IWhatever endpoint. ((NOTE: I don't have access to original contract to use directly)).
Sooo.. looks like Castle DynamicProxy allows for one to define which methods should be generated (see: http://kozmic.net/2009/01/17/castle-dynamic-proxy-tutorial-part-iii-selecting-which-methods-to/). I was thinking I would use to not intercept calls on methods ending with "[...]Async". However I don't see where I would add this customization rule in the proxy generation within MOQ; hence my question.
I want to inject some aspects in to methods/properties regardless whether it is private, public or protected.
I have gone through many blogs and forums and couldn't find a helpful article on this.
Can any one guide me on this ?
There are limitations on how Unity intercept certain methods. Certainly it is a value-added feature on top of standard DI facilities provided by the framework. As far as I know, non of the Unity versions do not support AOP style interception on private methods, and constructors. TransparentProxyInterceptor would only intercept only the type's implemented interfaces or the type used by MarshalByRefObject And the VirtualMethodInterceptor would only intecept on virtual methods.
I don't think any new interceptors have been added to the Interception in v3.
Also note that usual private/protected even internal methods require special intervention for AOP style interception. This is more less out of bound for Unity because it requires IL re-writing which usually handled by dedicated AOP framworks such as PostSharp.
I have a solution with several projects (MyApp.Data, MyApp.BLL, MyApp.Web). I register types in Global.asax file in MyApp.Web (main web application):
builder.RegisterType<SomeService1>().As<ISomeService1>().InstancePerHttpRequest();
builder.RegisterType<SomeService2>().As<ISomeService2>().InstancePerHttpRequest();
//...etc
And I wonder whether it's a bad practice to register types and their scope using attributes in the other assemblies (for example, in MyApp.BLL). See below:
[Dependency(typeof(ISomeService1), ComponentLifeStyle.Transient)]
public class SomeService1 : ISomeService1
{
//methods and properties go here
}
Using local attributes or other ways to indicate wiring for a DI Container tightly couples the service to the DI Container, so I don't think that's a good idea.
Additionally, it may constrain your future options. If, for example, you specify the lifestyle scope, you can't reuse the service with a different scope.
In general, you should compose the application in a Composition Root (global.asax), which gives you a single location with a clearly defined responsibility where all classes are composed.
That would be much more manageable and maintainable that spreading the configuration data all over your classes.
As your question implies, it makes some sense to delegate responsibility for registration to the assembly that knows what needs to be registered. For example, if you
use the SolrNet library, it provides a method that performs component registration, to encapsulate the knowledge of what needs to be registered and to spare the library's consumer from having to learn all about the library before getting started.
However, there is a potential issue with this approach. Would your registration requirements change if you used the dependent assemblies in other applications? For example, would it make sense to register something as ComponentLifeStyle.HttpRequestScoped and then use it in a non-Web application? By delegating registration to the dependency, you are coupling the dependency to its consumer's registration requirements (and to its choice of IoC container).
Autofac (I can't speak for other IoC containers) provides a way round this. It enables you to override registrations so that the most recently registered component is used when a service is resolved. This means that you can call a library's registration method and then register your own services to override the defaults.
There is another problem with your proposed attribute-based registration - it doesn't enable you to specify a lambda expression as a component creator. How would you implement a registration like this with attributes?
builder.Register(c => new A(c.Resolve<B>()));
It might be preferable to define an IRegistrar interface, and then use reflection to search all loaded assemblies for implementations and invoke them. Perhaps something like this:
public interface IRegistrar
{
void RegisterComponents();
}
Preferablly with a simple example.
The spec can be found at: http://msdn.microsoft.com/en-us/library/ms972319.aspx
From http://en.wikipedia.org/wiki/Provider_model
The .NET extensible provider model allows a "component" to have multiple implementations using an abstract factory pattern approach. Providers are a subclass of the ProviderBase class and typically instantiated using a factory method.
An example would be membership providers. At runtime it works out which provider to use based on configuration settings. The provider must adhere to a specification (defined usually by an interface). It creates an instance of the type specified that can fulfill the requirements of the specification, and then calls methods on it to do the work.
This lets you augment and enhance default functionality to provide your own implementation (ie: custom authentication logic) using a standard interface.
Very similar to abstract factory and builder patterns.