I'm trying to use Spring.NET's support for AOP to do dependency injection/inversion of control/aspect-oriented programming (sorry for the slew of buzzwords - maybe I'll post a separate question asking someone to clarify the difference :) ).
Specifically, I want to have intercept a recursive method call, so that every time that the method is invoked, the AOP advice/interceptor will be called.
Spring.Net doesn't appear to intercept anything other than the very first method call. I think that Spring.Net is maintaining exactly 1 chain of interceptors per instance, and not call any more interceptors until that first method invocation has finished.
Does anybody have any info about getting the interceptor (the advice) to be triggered for EVERY method invocation, including recursive calls?
I can provide code/example output, if that's helpful.
Thanks!
See http://forum.springframework.net/showthread.php?t=5331
If you are using proxy-based AOP then this will not work for recursive method calls. The first call against the target will be intercepted by the proxy and your advice will run. Then the method on the target will be invoked, and subsequent calls will stay within the target class, ignorant of the proxy. The only way to make this work is to actually modify your bytecode so that class itself contains the behavior.
I actually haven't worked with Spring.NET (only Spring with Java) so I'm unfortunately ignorant about what kinds of bytecode weaving options exist in the .NET universe.
I know this isn't Spring.NET per se, but have a look at PostSharp. It gives you compile time weaving that doesn't rely on dynamic proxies, and would handle the recursive method call. The configuration is slightly different though...
Related
I would like to make the retry logic transparent, ideally utilizing Microsoft's Transient Fault Handling Application Block, instead of wrapping every database-accessing piece of my code into a function that retries.
What I can do is creating a custom IDbConnectionFactory
that produces custom IDbConnection objects of type MySqlAzureConnection:
MySqlAzureConnection dbConn = myConnFactory.OpenDbConnection();
dbConn.Insert(new Employee { ... });
I have two choices:
Add an .Insert() method to MySqlAzureConnection to hide
the same extension method of OrmLite, to provide my retry logic.
Actually my .Insert() will contain exactly the same source code
as in OrmLite: call dbConn.Exec(), but that .Exec() will be
my implementation that provides the retry logic.
The problem is that (in order to be sure that queries and writes
in my program always use the retry logic) this way I will end up
with copy&pasting all the 120+ methods in the
[OrmLite][Read|Write]ConnectionExtensions static classes,
just to extend the behaviour of the very single dbConn.Exec().
Not sounds too good.
Omit using ServiceStack.OrmLite; to make sure that the non-retrying
implementations of OrmLite won't get called. In this case how can I use
OrmLite? I'll have to write full namespace-qualified names all the time.
Sounds terrible, too.
EDIT:
I realized that there's a third choice: giving up the requirement of
the retry logic being 'transparent'. In other words, admit the explicit use
of a wrapper function at every piece of code that uses OrmLite, and
implement the retry logic in that wrapper function. In fact, the Transient Fault Handling Application Block
does the very same thing: introduces ExecuteCommand(), a new method
(non-standard in an IDbConnection) and makes the developer responsible
for using it as a high-level wrapper around any database-accessing code.
Whilst this solution sounds better than the first two, I'm still not
satisfied with it. The Entity Framework (6.0) has managed to make
this resiliency transparent, and I'm looking forward to a similiar
solution here. (It would be easy to wire into OrmLite's
ReadConnectionExtensions.Exec() method – if it weren't a static extension
method. Even better is an injectable module, as done in the Entity Framework)
.
Did some further research on this and it turns out that transient error handling is now built into SqlConnection under the hood from .Net 4.6.1 onwards. Therefore as a raw Ado.net SqlConnection underpins Ormlite any custom approach should be rendered unnecessary.
Dan
We have small lifetime scopes in our applications. It would be interesting to be able to intercept all services registered in autofac. By doing so we can see exactly which path the code takes for every lifetime scope and which method arguments are used. Not really usable for production but when really great for debugging/diagnostics/refactoring as you ge the whole picture and not just unit level.
But AFAIK it's only possible to register an interceptor for each single registration?
Nothing like this is supported out of the box with the Autofac.Extras.DynamicProxy2 library. You could potentially implement something like a module that handles OnActivating for every component using code similar to the stuff in Autofac.Extras.DynamicProxy2, but you'll run into trouble like...
Do you want class interceptors or interface interceptors? The type of service being resolved vs. the limit type of the component backing it will influence what kind of dynamic proxy you want to make. I believe the current A.E.D2 code only generates interception for either/or - not every interface a class implements, etc.
Do you use WCF client proxies? Client proxies are an interesting beast of their own so you have to special-case them. You'll see that in A.E.D2.
Generally problems like this get solved by aspect-oriented programming solutions (e.g., PostSharp) or profilers (e.g., ANTS)... or a combination of both. You might want to look into those solutions if you have the ability.
For an example of what sort of module implementation I'm talking about, check out the log4net integration page on the Autofac wiki. That shows how to handle OnPreparing for every component in the system. You can do the same thing, but handle OnActivating instead and use the sample on the Lifetime Events wiki page to show you how to swap one resolved thing for another (swap the real object for the generated proxy).
I have an .net assembly at C#. I have both: binary and source which has no logger, for example.
All I need is to insert property which will be initialised specific logger. Then I need to introduce logger invoker in all methods. The first way - is manually write property and their invokes. And the second way - is to write another class\method (I suppose in the same assembly) which will do it automatically.
Is it possible? Any suggestions?
I think it is possible, cause it was one of the questions at the interview. But there is no proof that this is possible, and they wanted to hear "no, do this manually".
This is what we call in architectural terms a 'cross cutting concern'. Logging is something that straddles many aspects of an application.
There are features to take care of it in the Microsoft Enterprise Library. The part you want is the Policy Injection library. You can then specify, in the config, methods to match (based on method name/structure) and a function to be called. In this way you can include logging as a proper cross-cutting concern of your app, rather than something which must be manually coded into every method.
It is not possible to alter the execution of a method without altering the source code and recompiling. You could write a wrapper class that would expose all classes and methods which would first call your logger and then the methods, but that's not what they asked.
So the answer to their question is 1. is possible, 2. isn't possible, and if you would have to add logging support, you would need to add it to each method manually.
I'd like to intercept and inject custom code when calling 3rd party code in C#. I am using an external library (AutoIt) for GUI automation. The AutoIt dll is provided without source code.
All actions done with this framework are performed from a single class (AutoItClass) providing access to all the methods. I'd like to be able to inject custom code when calling methods on this class, is this possible? For example:
Log some information from within the called method.
Perform any other action from within the method (wait for X seconds).
This would be possible very simply by inheriting from this class and overriding all its methods (which is a must since this is a COM object), but this is not the preferred way. Any comments will be helpful!
I wouldn't use inheritance - you can use composition here. Create your own class which has the same methods - or in fact only the ones you're interested in - and delegate through that. That way you can be sure you won't "miss" any methods accidentally, because anything you don't implement won't be callable through the rest of your codebase... so long as you make sure the rest of your code doesn't refer to the original library class, of course.
You can investigate PostSharp, which is a commercial product that can inject IL into compiled assemblies to perform aspect oriented programming. You can define different kind of behaviour that should happen before and after a method gets executed, for example, which seems to be what you want. This way, as PostSharp handles this in a post-compilation step, you don't need to create any inherited classes from the classes that you want to intercept.
Otherwise if you want a more "pure" solution I would follow Jon's advice about creating a new class that wraps the functionality of the one that you want to intercept. (see Decorator pattern) .
I want to be notified whenever a specific method has been called. I was hoping I could accomplish this using Reflection, but my attempts haven't gotten me anywhere. How can I be notified?
I figured using MethodInfo was the way to go, but like I said, I found nothing there that could help me accomplish what I wanted to do.
I cannot change the method or decorate it with attributes or anything. If I could do something like that, I wouldn't need to do this, I could just change the method itself.
Have you considered AOP (aspect-oriented programming)? Something like PostSharp.
I believe the only way to do this is either rewrite the method body so that it notifies you when the method has been called or use CLR Profiling Api.
The first way can be accomplished by using AOP framework. You can use Postsharp (which was turned into a commercial product) to achieve it with OnMethodBoundaryAspect. Here is an example: Derive the class from OnMethodBoundaryAspect
Reflection is half the solution. You need to wrapperize the objects being observed in order to intercept the method calls. Usually thi is done via remoting proxy objects.
Enterprise Library has the Unity Interception block which does exactly what you want. Also you may want to look into Castle framework's DynamicProxy, which gives you extremely thorough control of this interception process.
Googling for Aspect Oriented Programming will give you more information.
you can use extension methods
so you can use different attributes and modify everything before or after the actual method