July 2009 Entries
Tim already let the cat out of the bag - I've been accepted as a blogger to Devlicio.us.. I'm very thrilled to be onboard and blogging alongside of so many great people, many of whom I know from twittering, gtalking etc...
If you're subscribed to this blog, don't worry - it's not going away. It's still going to stay around. I think I'm gonna cross-post technical posts to both blogs, and keep more personal stuff, and things not really in line with devlicio.us here.
So, having said that, thanks guys for having me, and I'll do my best to keep up with...
If you, like Mario (or me today), ever accidentally hit F1 in Visual Studio, and spent next couple of minutes looking at similar screen, I have a remedy. How often do you really use F1 to access Visual Studio help anyway? Wouldn’t it be good to just disable this shortcut? Well, as I learned today – you can do this. Go to Tools –> Options… navigate to the option above, find the command Help.F1Help and click Remove, et voilà! Happy coding.
When you have a WCF service that is not a singleton, and you want to use non-default constructor, you enter a world of pain. There's a lot of hoops that you have to go through to plug an IInstanceProvider into the service. Even worse if you have many services. To alleviate the pain, I created a small helper method. private ServiceHost GetService<TService>( string address, Func<TService> createServiceInstance )
{
var service = new ServiceHost( typeof( TService ) );
var serviceInstanceFactoryBehavior = new ServiceInstanceFactoryBehavior(...
I was really surprised that quite a few people started using my… hack that let you post to Twitter using Launchy. Due to popular demand (hey, few people really asked for that) I decided to create an actual Launchy plugin that would let you do that. And so Ty was born. I know it’s not the best name in the world, but all Launchy plugins are required by law to end with y and Twitty was already taken, so I abbreviated it to simply Ty. The word ty means also ‘you’ in Polish. All the...
All .NET delegates inherit (indirectly) from System.Delegate class (and directly from System.MulticastDelegate) which has a static CreateDelegate method. The method has two powerful characteristics that are not widely known. All delegate types are implemented by the runtime. What do I mean by that? Let’s have a look at how any delegate type looks at the IL level: All methods are runtime managed, meaning that, in a similar fashion you provide implementation for interface methods, runtime provides implementation for delegate methods. Take a look at the constructor. Regardless of delegate type it always has two arguments:...
One more thing I mentioned in the 11th part of the Dynamic Proxy tutorial, was that I think behavior of class proxy when the class implements the additional interfaces was a result of an omission, and that it’s a bug. The issue was raised by Kenneth Xu actually roughly by the same time,on the Rhino Mocks discussion group. Anyway, this is now fixed in the trunk, and will be in version 2.2. There’s just one thing to be aware of – you will get the old behavior (no target) for members that are implemented explicitly. This is the...
In the 11th part of the Castle Dynamic Proxy tutorial, I mentioned that surprising behavior of additional interfaces in case of interface proxy with target is not considered a bug. Coincidently, just few days later a user started a thread on our discussion group regarding this issue. After some discussion we decided to change that, so starting with version 2.2 (or now, if you’re using daily builds) this behavior is no longer true. We aligned it with how interface proxy with target works. Actually, this (not real) part of code illustrates the new behavior. Let’s assume we’re calling...
If you’ve been following the tutorial, you should remember that Castle Dynamic Proxy provides proxying capabilities by generating types at runtime. Dynamic code generation is not a lightweight operation, so pretty important aspect of Dynamic Proxy is its caching mechanism which we’ll going to cover in this post.
Let’s consider the following piece of a test:
var proxy1 = generator.CreateClassProxy<Foo>(new FooInterceptor());
var proxy2 = generator.CreateClassProxy<Foo>(new BarInterceptor(), new FooInterceptor());
Assert.AreEqual(proxy1.GetType(), proxy2.GetType());
Will it succeed? The answer is – yes. In this simple case both proxies would be semantically identical, so generator (or more precisely IProxyBuilder that the generator is using) caches the type that...
So far in the tutorial we’ve covered most of the basics. However, we were always proxying just one type, be it a class or an interface. There is quite often a need to do more. What if a class implements more than one interface, and we want them all proxied? What if we want the proxy to implement interfaces the target type does not implement. Today we’ll talk about how to do just that, so let’s get straight to it. If you look into the API you may notice that for every kind of proxy there are overloads that...