I first came across the RealProxy class three years ago when trying to figure out better ways of handling WCF client proxies (correct connection disposal, reusing faulted channels etc). I was intrigued about how ChannelFactory<T> could return an instance of a service contract that had the implementation of a WCF client for an interface definition it knows nothing about.

With a decent amount of Reflector surfing I followed the rabbit hole down to the usage of RealProxy. In my opinion this has to be one of the most interesting classes in the CLR. I finally founds some time to post some information about this amazing class.

Imagine a scenario where you want to have an action that you want to take when a method on a type is invoked when you do not have any prior knowledge of the type definition. The RealProxy class is able to run some magic that will return you a proxy instance of that type and provide notification when method invocations occur on that proxy. The main downside with RealProxy is that the type to proxy must either be an interface or a class that inherits from MarshalByRefObject.

I previously posted about how to get Unity support in WCF services via a ServiceBehavior. I found a glaring omission in this implementation when preparing for my .Net Users Group presentation. The existing code supports named configuration sections and named containers. Unfortunately it left out the more common named instance resolutions.

I have checked in a new code version that supports this. See UnityServiceElement, UnityServiceBehavior and UnityInstanceProvider for the updated code line.

I’m going to be presenting at this months .Net Users Group in Canberra. The topic will be Unity injection for ASP.Net and WCF with some Unity extensibility added in as well.

Here is the abstract for the session.

Unity is the Microsoft Patterns and Practises implementation of an inversion of control (IoC) container. Using IoC containers facilitates the dependency injection pattern which helps to decouple code from its dependencies.

A common way to implement IoC in ASP.Net and WCF services is to couple the hosted application to the IoC container. The first half of this session will look at how ASP.Net and WCF applications can be extended to leverage the benefits of IoC while decoupling the hosted application from the container.

The second half of the session will look at how Unity can be extended to provide a recursive disposal pattern for build trees created by the container.

If you are local then I hope to see you there.

I posted recently about my Unity extension that disposes build trees when a container tears down an instance it previously created. The extension makes an assumption that a Unity build operation will either succeed completely or fail completely. Normally you expect this to be the case. I have however now come up with an edge case.

I am writing another Unity extension that adds support for injecting proxy instances as dependencies. Part of this design allows for custom proxy handlers to be injected. Defining a custom proxy handler is optional and can either be specifically defined in configuration at the injection definition or be automatically resolved by the Unity container from contextual information. If a custom proxy isn’t defined or can’t be automatically resolved then the injection will fall back to a default proxy handler type.

I have previously posted about supporting AppSetting value resolution for Unity injection (Unity 1.x here and Unity 2.0 here). Today I had a requirement to inject connection string values from application configuration. Like the AppSetting implementation, this creates a nice redirection of injection values as developers and administrators are more familiar with the connection string section in application configuration compared to finding the right value in large amounts of Unity configuration.

This implementation leverages the AppSettingParameterValueExtension class from the prior examples and renames it to SectionExtensionInitiator. This class now configures a Unity section for multiple element extensions rather than a single specific implementation.

I knew that I should address the popular MVC model for ASP.Net as soon as I had finished my post on Unity dependency injection for ASP.Net. A different implementation for Unity injection is required here as the MCV model has a different method of processing ASP.Net pages.

Like the posts for Unity injection with WCF and ASP.Net, there are similar implementations already published on the internet to support MVC. The main issues I have with the examples posted elsewhere are that:

• global.asax application events are used which are not easily portable between projects
• there is no support for teardown operations of the controllers created via Unity (especially important when Unity creates disposable build tree hierarchies)

I have been putting together a customised build process with TFS Build 2010. Several parts of the functionality added to the build process involve custom types that are used as arguments for the build definition. Deploy and configuration update information are some examples of this. I wanted to get the same designer experience out of the Process tab property grid that is available for properties like the test list definition.

The Automated Tests property seen here has a set of sub-items for each test item specified (items in the collection property). Each of these is expandable and the display text of each parent property is customised according to the values of the child properties.

WiX has a great little utility called Heat.exe (formally Tallow). Heat is used to harvest WiX project references to determine their contents. The content harvested is grouped by Binaries, Satellites, Content, Source, Symbols and Documentation. The benefit this provides to WiX is that you do not need to manually define each item to include in the MSI from a referenced project. If the referenced project changes, such as the contents of a website project, then these updates will be automatically put into the MSI when it is compiled.

Take the following solution for example.

Heat generates a wxs file at compile time for each harvested project (found in obj\Debug or obj\Release).

A Unity container is used to create objects for use by an application. There are several reasons why it is also responsible for cleaning up the instances that it creates.

• A Unity container owns the instances according to my Law Of Instance Ownership as the container would typically be near the top of the call stack and higher stack frames don’t hold a reference to container created instances
• Container management in a WCF Service (see here and here) or an ASP.Net application (see here) result in the container being held outside of the scope of the application code
• The container is already responsible for the lifetime management of instances with respect to instance creation

Code outside the container should not be concerned with the lifetime management of instances created by the container for these reasons.

I have a new machine at work that is a nice beefy machine. It has eight cores and 12Gb of RAM. I was a bit surprised to see that a load test I was running was maxing out the CPU.

It’s a shame that I only have one core being used for the load test. It would be great if I could really load up this code base on all eight cores.