I’ve been writing a custom Unity extension for disposing build trees when a container is asked to tear down an instance. This has brought up some interesting ideas about the conditions in which an instance should be destroyed. This has lead to me come up with the Law of Instance Ownership.
An instance is owned by the highest stack frame that holds a direct reference to an instance, or the application domain for globally held instances.
I’ve been working with TFS Build in Visual Studio 2010 over the last week. It has been a lot of fun working with the new workflow support for build automation. I did hit an interesting issue the other day though.
My build workflow attempts to determine a “build version” for the build. The build version is used to update the build number and is then injected back into the version info files for the compilation of the solution. It is determined by finding all the version files in the solution. We tend to use a common ProductInfo.cs to contain this information so there really should be only one file found in this search. The “best” version is obtained from the set of version files using a set of business rules. There is also some logic in there for automatically incrementing the Build and Revision numbers and the ability to check the version changes back into source control so the version numbers keep incrementing on subsequent builds.
Sometimes things just don’t go to plan went you deploy your software to a server. Unfortunately servers don’t come with all your dev tooling so it can be hard to figure out what is going wrong when provided some cryptic exception message.
My current issue is testing deployment of a 4.0 framework built WCF service to a newly provisioned Windows Server 2008 R2 machine. I get the classic WCF error message saying that the service type could not be found for the endpoint. It doesn’t tell me why and I know the service assemblies are in place. Given prior experience I am guessing that the most likely cause is that other dependencies of my service assemblies are not on the machine.
I look to FUSLOGVW.exe to find out these answers. The issue is that this great utility is not on the server image as it comes out of the .Net SDK. With a bit of trickery, it can be used on a server. These are the steps to get this done.
I’ve been wanting to get dependency injection happening for ASP.Net pages like I have for WCF service instances (see here and here). The solutions that I found on the net use combinations of abstract ASP.Net pages or Global.asax with an IHttpModule. I didn’t like these solutions because it is messy to make multiple changes to your application to introduce a single piece of functionality.
My version uses a single IHttpModule without any other dependencies. The only impact on the application is to configure the module in web.config.
My UnityHttpModule looks like the following.
Back in 2007 I wrote a post about WinMerge support for TFS in Visual Studio. It turned out to be the most hit post on my blog ever since. I have just updated the post with some reg files that add the same support for VS2010 for both x86 and x64 platforms.
In Part 1, I described the code used to leverage ServiceHostFactory to create WCF service instances with dependency injection via Unity. Using a custom ServiceHostFactory is a really easy way to get dependency injection in WCF but comes with two drawbacks. The standard Unity configuration section name (“unity”) must be used and named Unity containers are not supported. Most applications will work within these constraints.
Using a configuration based service behavior is the answer to situations where these constraints are a problem. The UnityServiceElement class is used to define the configuration support for the UnityServiceBehavior. As outlined in the last post, the UnityServiceBehavior class is used to assign a custom instance provider to each endpoint in the service. The instance provider is used to resolve a service instance from a Unity container.
There are a few ways that Unity can be used to construct WCF service instances. The options are poor mans injection, service host factories and configured behaviours.
The poor mans injection option is to create a unity container within the constructor of the service type and resolve dependencies from within the service instance. This is not elegant and couples the IOC implementation (Unity in this case) to the service.
The second option is to create a custom service host factory. This option allows a service type to be created with constructor dependencies rather than a default constructor. It uses the mark-up in svc files to identify the custom factory to be used rather than the default one. The 4.0 framework also supports this configuration via web.config as svc files are no longer required.
I recently posted about how to resolve appSetting values for parameter injection in Unity. After seeing the news yesterday (here and here) of Unity 2 being released with EntLib 5, I decided to revisit this functionality to adopt the latest and greatest.
There are some issues with adopting Unity 2 in the short-term. Unity 2 isn’t actually released by itself (as noted in a comment by Grigori Melnik), although it is bundled with EntLib 5. This means that there is no documentation for the changes found in the new version of Unity. The EntLib documentation for Unity simply says that “Content for this topic is not yet available”.
Given these constraints, I have a working solution after several hours of surfing Reflector.
I’m writing a system that exposes several services. Each service is created using Unity and has many dependency slices including business layers, data access layers, caching, logging and exception management.
As I was writing the exception management slice, the code started to get incredibly duplicated. Each method in the class began to look like this:
I wasted a lot of time this afternoon trying to get some Unity configuration to work.
One of the issues I had was that I wanted to inject a concrete type that didn’t have an interface. This turned about to be simple as Unity natively supports it. You just don’t need to define a mapTo attribute on the type element. The issue that hit me was that Unity was not invoking the constructor that I was expecting. My type that has the following constructors: