Krzysztof Kozmic

How to force Nuget not to update log4net to 1.2.11

Krzysztof Koźmic — Tue, 31 Jan 2012 12:28:00 GMT

That’s a quick one. There’s been a new release of log4net recently that’s signed with a new key, and therefore is incompatible with old version 1.2.10.

Therefore, due to near-ubiquity of the library in .NET space, it may cause some problems if you happen to have a dependency (direct or indirect) on it.

The matters are made worse by Nuget’s default of getting the latest available version of the package. I dealt with this problem the other day, and I saw a few people in my twitter stream struggling with the same issue.

The solution is quite simple. It’s not specific to log4net and I’m not picking on log4net here. Here’s how you can restrict Nuget’s package to specific version in your solution.

So imagine you install a package that has a dependency on log4net. In this case, the dependency is specified as specifically version 1.2.10 (as opposed to Nuget’s default: this version of newer).

If after that we install another package that also depends on log4net but doesn’t restrict the version, we’ll have a problem.

The package we were trying to install doesn’t get installed. Actually, even if it did, we would have a problem since it most likely was compiled against log4net 1.2.10 anyway, and if Nuget updated log4net to version 1.2.11 the app would throw an exception at runtime due to mismatched assembly.

So there is a solution to restrict version of the package to specific version (in this case 1.2.10) as specified in the documentation.

After adding allowedVersions=”[1.2.10]” we can try again and this time the package will install properly.

Notice it says it installed log4net 1.2.11. I checked my packages folder, and project dependencies and the version referenced was 1.2.10 so all is good.

Hope that helps

Testing framework is not just for writing… tests

Krzysztof Koźmic — Wed, 18 Jan 2012 13:06:00 GMT

Quick question – from the top of your head, without running the code, what is the result of:

var foo = -00.053200000m; 

var result = foo.ToString("##.##");

Or a different one:

var foo = "foo"; 

var bar = "bar"; 

var foobar = "foo" + "bar"; 

var concaternated = new StringBuilder(foo).Append(bar).ToString(); 

var result1 = AreEqual(foobar, concaternated); 

var result2 = Equals(foobar, concaternated);

public static bool AreEqual(object one, object two) 

{ 

    return one == two; 

}

How about this one from NHibernate?

var parent = session.Get<Parent>(1); 

DoSomething(parent.Child.Id); 

var result = NHibernateUtil.IsInitialized(parent.Child);

The point being?

Well, if you can answer all of the above without running the code, we’re hiring. I don’t, and I suspect most people don’t either. That’s fine. Question is – what are you going to do about it? What do you do when some 3rd party library, or part of standard library exhibits unexpected behaviour? How do you go about learning if what you think should happen, is really what does happen?

Scratchpad

I’ve seen people open up Visual Studio, create ConsoleApplication38, write some code using the API in question including plenty of Console.WriteLine along the way (curse whoever decided Client Profile should be the default for Console applications, switch to full .NET profile) compile, run and discard the code. And then repeat the process with ConsoleApplication39 next time.

The solution I’m using feels a bit more lightweight, and has worked for me well over the years. It is very simple – I leverage my existing test framework and test runner. I create an empty test fixture called Scratchpad.

This class gets committed to the VCS repository. That way every member of the team gets their own scratchpad to play with and validate their theories, ideas and assumptions. However, as the name implies, this all is a one-off throwaway code. After all, you don’t really need to test the BCL. One would hope Microsoft already did a good job at that.

If you’re using git, you can easily tell it not to track changes to the file, by running the following command (after you commit the file):

git update-index --assume-unchanged Scratchpad.cs

With this simple set up you will have quick place to validate your assumptions (and answer questions about API behaviour) with little friction.

So there you have it, a new, useful technique in your toolbelt.

Approval testing – value for the money

Krzysztof Koźmic — Mon, 16 Jan 2012 12:29:00 GMT

I am a believer in the value of testing. However not all tests are equal, and actually not all tests provide value at all. Raise your hand if you’ve ever seen (unit) tests that tested every corner case of trivial piece of code that’s used once in a blue moon in an obscure part of the system. Raise your other hand if that test code was not written by human but generated.

As with any type of code, test code is a liability. It takes time to write it, and then it takes even more time to read it and maintain it. Considering time is money, rather then blindly unit testing everything we need to constantly ask ourselves how do we get the best value for the money – what’s the best way to spend time writing code, to write the least amount of it, to best cover the widest range of possible failures in the most maintainable fashion.

Notice we’re optimising quite a few variables here. We don’t want to blindly write plenty of code, we don’t want to write sloppy code, and we want the test code to properly fulfil its role as our safety net, alarming us early when things are about to go belly up.

Testing conventions

What many people seem to find challenging to test is conventions in their code. When all you have is a hammer (unit testing) it’s hard to hit a nail, that not only isn’t really a nail, but isn’t really explicitly there to being with. To make matters worse the compiler is not going to help you really either. How would it know that LoginController not implementing IController is a problem? How would it know that the new dependency you introduced onto the controller is not registered in your IoC container? How would it know that the public method on your NHibernate entity needs to be virtual?

In some cases the tool you’re using will provide some level of validation itself. NHibernate knows the methods ought to be virtual and will give you quite good exception message when you set it up. You can verify that quite easily in a simple test. Not everything is so black and white however. One of diagnostics provided by Castle Windsor is called “Potentially misconfigured components”. Notice the vagueness of the first word. They might be misconfigured, but not necessarily are – it all depends on how you’re using them and the tool itself cannot know that. How do you test that efficiently?

Enter approval testing

One possible solution to that, which we’ve been quite successfully using on my current project is approval testing. The concept is very simple. You write a test that runs producing an output. Then the output is reviewed by someone, and assuming it’s correct, it’s marked as approved and committed to the VCS repository. On subsequent runs the output is generated again, and compared against approved version. If they are different the test fails, at which point someone needs to review the change and either mark the new version as approved (when the change is legitimate) or fix the code, if the change is a bug.

If the explanation above seems dry and abstract let’s go through an example. Windsor 3 introduced way to programmatically access its diagnostics. We can therefore write a test looking through the potentially misconfigured components, so that we get notified if something on the list changes. I’ll be using ApprovalTests library for that.

     [Test]

    public void Approved_potentially_misconfigured_components()

    {

        var container = new WindsorContainer();

        container.Install(FromAssembly.Containing<HomeController>()); 

        var handlers = GetPotentiallyMisconfiguredComponents(container);

        var message = new StringBuilder();

        var inspector = new DependencyInspector(message);

        foreach (IExposeDependencyInfo handler in handlers)

        {

            handler.ObtainDependencyDetails(inspector);

        }

        Approvals.Approve(message.ToString());

    }

    private static IHandler[] GetPotentiallyMisconfiguredComponents(WindsorContainer container)

    {

        var host = container.Kernel.GetSubSystem(SubSystemConstants.DiagnosticsKey) as IDiagnosticsHost;

        var diagnostic = host.GetDiagnostic<IPotentiallyMisconfiguredComponentsDiagnostic>();

        var handlers = diagnostic.Inspect();

        return handlers;

    }

What’s important here is we’re setting up the container, getting the misconfigured components out of it, produce readable output from the list and passing it down to the approval framework to do the rest of the job.

Now if you’ve set up the framework to pup-up a diff tool when the approval fails you will be greeted with something like this:

You have all the power of your diff tool to inspect the change. In this case we have one new misconfigured component (HomeController) which has a new parameter, appropriately named missingParameter that the container doesn’t know how to provide to it. Now you either slap yourself in the forehead and fix the issue, if that really is an issue, or approve that dependency, by copying the diff chunk from the left pane to the right, approved pane. By doing the latter you’re notifying the testing framework and your teammates that you do know what’s going on and you know it’s not an issue the way things are going to work. Coupled with a sensible commit message explaining why you chose to approve this difference you get a pretty good trail of exception to the rule and reasons behind them.

That’s quite an elegant approach to a quite hard problem. We’re using it for quite a few things, and it’s been giving us really good value for little effort it took to write those tests, and maintain them as we keep developing the app, and the approved files change.

So there you have it, a new, useful tool in your toolbelt.

API design challenge – builder

Krzysztof Koźmic — Sat, 31 Dec 2011 01:07:00 GMT

Now that Windsor 3 is released I can concentrate on some of my other ideas and projects. While working on one of them, called Cartographer, I encountered an interesting API design problem.

I have a class (a builder to be precise) that has a task of setting up a central object (an IMapper implementation) in Cartographer (If you’ve ever used Autofac, it is somewhat analogous to ContainerBuilder). What is interesting about it, is I have three goals for that class:

Provide API for high level configuration and extension points that are universal to and intrinsic to any IMapper implementation.
Provide API for low level configuration of the default IMapper implementation that the builder creates, that will meet the following criteria:
1. Not force user to customize anything, as the default setup should be enough to get started in most cases.
2. Allow users to easily swap/extend parts of the dependency chain of the default mapper.
3. Work well and be natural both with and without IoC container .
Be simple and discoverable to the users (and provide good Intellisense experience).

How would you design the API for this class?

Oh, and happy new year.

Castle Windsor 3.0 is released

Krzysztof Koźmic — Fri, 16 Dec 2011 12:55:00 GMT

After successful beta and RC releases final version of Castle Windsor (as well as Castle Core, and a whole set of facilities) has now been released. There are no major changes between final version and RC. The difference is some minor bug fixes, improved exception messages and some small improvements all over the place.

The packages are available now, on Nuget (with symbols), and via standard .zip download.

Last but not least - thank you to everyone who downloaded beta and release candidate and provided feedback. You guys rock.

Getting closer… Castle Windsor 3 RC 1

Krzysztof Koźmic — Sun, 20 Nov 2011 12:10:00 GMT

Few weeks later than originally expected but here it is – Castle Windsor 3.0 (along with its facilities and Castle.Core) achieved release candidate status.

There is one major new feature in this release: registration API gained ability to specify properties to ignore/require. There are some scenarios where that’s useful, for example where integrating with some 3rd party framework that forces you to inherit from a base class which exposes its dependencies as properties. Creating pass-through constructors for each inherited class can be mundane. In those cases you can simply mark those base class properties as required, in which case Windsor will not allow them to be resolved unless all base property dependencies are satisfied. PropertyFilter enum supports several other most common scenarios, and for advanced cases there’s an overload that gives you more control.

Container.Register(

    Classes.FromThisAssembly()

        .BasedOn<ICommon>()

        .Configure(c => c.Properties(PropertyFilter.RequireBase)));

To address performance hit at startup Windsor no longer enables performance counters by default. Now, you have to do it explicitly:

var container = new WindsorContainer();

var diagnostic = LifecycledComponentsReleasePolicy.GetTrackedComponentsDiagnostic(container.Kernel);

var counter = LifecycledComponentsReleasePolicy.GetTrackedComponentsPerformanceCounter(new PerformanceMetricsFactory());

container.Kernel.ReleasePolicy = new LifecycledComponentsReleasePolicy(diagnostic, counter);

Full changelog is included in the packages. Please, if possible, take the time to upgrade to this version and if you find any issues report them so that the final release is rock solid. If no major issues are found, the final release will be published in two weeks.

The binaries are available on Nuget right now, and soon on our website.

Connector: Simple, zero friction Github –> AppHarbor integration

Krzysztof Koźmic — Sun, 18 Sep 2011 09:53:00 GMT

Recently to play with some new technology I came up with an idea to build an integration layer between Github and AppHarbor. What that means, is give you ability to work with your Github repository, reaping benefits of all of it’s VCS-centric features, and automatically, continuously deploy your code to AppHarbor.

The actual scenario I had in mind is to be able to use that for deployment of Open Source projects. AppHarbor is fantastic, no-headache deployment in the cloud, but Github is perfect for keeping and developing your code in the open, in social way. To have the cake and eat it too, Connector was born.

I hope you find it useful. it is free, use-at-your-own-risk-and-don’t-sue-me-if-something-breaks software. There’s still some work to be done, feature-wise and a whole lot of polishing but I decided to announce it early and get early feedback. If you have any suggestions, ideas or (gulp) bugs, let me know!

link: http://connector.apphb.com/

Hope that helps.

Windsor 3 beta 1 – dozen of Nuget packages and SymbolSource.org support

Krzysztof Koźmic — Sun, 04 Sep 2011 10:47:00 GMT

As promised, I released Nuget packages for beta 1 of Windsor 3. This is my first major rollout of Nuget packages, so please report any issues working with them.

Nuget and beta packages

Nuget is quickly evolving and getting more useful with each release. However one feature it’s missing right now is support for pre-release packages (this is coming in the next version).

This is not really a big deal, however it means there are a few things you should be aware of.

Recommended version

Since the new package is a pre-release, while I would really like for everyone to start using it immediately and report all issues they find, I quite understand that many people will rather prefer to stick to the last official version for the time being. To accommodate that the new packages are not made recommended versions, so your Nuget explorer will still point to the last stable (2.5.3) version if you search for Windsor, Castle.Core or any other pre-existing package.

If you go to command line and install one of the packages without specifying version number, it will install the latest, that is beta 1 version.

SymbolSource.org and debugging into Windsor

Folks at SymbolSource.org added recently support for Nuget (and OpenWrap as well) and the new Castle packages take advantage of that. What it gives you, is you can now easily debug into Windsor’s code, just like .NET framework reference source (there’s a simple guide at SymbolSource on how to do it).

After you’re all set you can step into any of Castle methods in your debugger and watch the magic happen. Very cool thing, even if I say so myself.

List of packages

Here’s the full list of v3 beta 1 packages (notice those are not all Castle packages, just those that were published as v3 beta 1 rollout of Windsor):

Castle.Core – Contains Castle.Core.dll which includes DynamicProxy, DictionaryAdapter, EmailSender, logging abstractions and some other goodies.
Castle.Core-log4net – Contains Castle.Services.Logging.Log4netIntegration.dll, that is implementation of Castle logging abstractions for log4net
Castle.Core-NLog – Contains Castle.Services.Logging.NLogIntegration.dll, that is implementation of Castle logging abstractions for NLog
Castle.Windsor – Contains Castle.Windsor.dll which has Windsor itself and two most commonly used facilities – Typed Factory facility and Startable facility.
Castle.LoggingFacility – Contains logging facility.
Castle.Windsor-log4net – Empty package that just installs logging facility and Castle.Core-log4net (and their dependencies obviously).
Castle.Windsor-NLog – Empty package that just installs logging facility and Castle.CoreNLog (and their dependencies obviously).
Castle.WcfIntegrationFacility – Windsor’s WCF facility.
Castle.SynchronizeFacility – Windsor’s Synchronize facility.
Castle.RemotingFacility – Windsor’s Remoting facility (extracted out of Castle.Windsor.dll)
Castle.EventWiringFacility – Windsor’s Event Wiring facility (extracted out of Castle.Windsor.dll)
Castle.FactorySupportFacility– Windsor’s Factory Support facility (extracted out of Castle.Windsor.dll)

I hope this will make it easier for everyone to test drive Windsor. And if you find any issues, have any suggestions or ideas, do not hesitate to bring them up, either on our google group, or issue tracker.

Simple guide to running Git server on Windows, in local network (kind of)

Krzysztof Koźmic — Sat, 20 Aug 2011 07:50:00 GMT

Last year I found myself in a sudden and quick need to set up working environment for a team of four, and as I like Git very much, I wanted to use it as our VCS. The problem was, we weren’t allowed to use any third party provider, so GitHub was off the table. As I searched the Internet there were a few guides to set up team Git environment on Windows, but they all seemed very complicated and time consuming. For our modest needs we experimented a little and came up with a solution that was very simple, didn’t require any additional software to be installed anywhere and worked like a charm.

Recently I used it again on my current engagement, and one of my colleagues suggested I should blog it, so here goes.

Ready, steady, go

The guide assumes you already have your local Git set up. For that, there are plenty of resources on the Internet, including my own blogpost about Windows Git tooling.

The entire tricks works like this – expose folder containing your shared Git repository as Windows network share.

Step one – bare git repository

There are two twists to the entire solution – one of them is – your shared repository needs to be initialized with --bare flag.

Step two – Windows share

Second step is to expose the folder with our newly created repository on the Windows share. You also use your standard Windows mechanisms to control and limit access to the folder (make sure you give the developers write access!).

Step three – Map the share as network drive

This step is perhaps not exactly necessary but I couldn’t get it to work otherwise, so here comes the second twist. In order for your developers to be able to access the shared folder via Git they need to map it as network drive.

Step four – Add remote repository in Git and code away

Last step is the standard Git procedure – every developer on your team needs to add the repository sitting under their newly created network drive as remote. Notice the use of “file:///” prefix in front of the mapped drive name.

Step five

That’s all. I hope you find it useful, and if you know a way to eliminate step three, let me know in the comments.

Windsor 3 beta 1 is released (along with other goodies)

Krzysztof Koźmic — Mon, 15 Aug 2011 10:49:00 GMT

The title says it all. If you can’t wait grab the binaries here (Windsor with Castle Core and facilities) and here (just Core). Nuget package will hopefully follow soon.

What’s in it?

This is a major release and there’s quite a lot of new features, as well as some significant changes under the covers. There’s a high level overview of highlights for the release in the wiki, so please have a look there. More detailed changelog, and list of breaking changes is available as part of the package.

Remember it’s a beta release. Documentation and samples are still being updated and some features are not yet implemented or not fully baked. However it is very important that you don't wait for the final release to upgrade, so that we can find and fix all the issues before final release. I'm not asking you to use it in production, but I'd really appreciate if you'd take the time to branch your apps, try to upgrade, run your unit tests, play with new version, and report any issues you may find. And ask your colleagues, friends and random people on the street to do the same!

And if you find any issues, do report them.

Have fun and happy coding,
I hope you like it

What's new in Windsor 3: Container debugger diagnostics improvements

Krzysztof Koźmic — Sun, 24 Apr 2011 23:56:00 GMT

As we're nearing the release date of Castle Windsor 3.0 (codename Wawel) I will be blogging about some of the new features and improvements introduced in the new version.

In the previous post I introduced one new diagnostic, and in this post we’ll explore other improvements in this area.

Overview

In the screenshot below (and all other) the upper window is Windsor 2.5, lower window is Windsor 3. All screenshots were taken running one of open source applications.

As you can see there are some additional diagnostics present in the new version. Altogether the number rose from 4 in previous version to 7 in Wawel (you’re not seeing all of them in the screenshots above because some of them only activate if they have something to show). The new ones are:

Default component per service – if you have multiple components exposing one service this will show you which one of them is the default (that is which one will be used primarily to satisfy dependencies of that type).
Potential Service Locator usage – was discussed previously

Objects tracked by release policy

This one is pretty self explanatory. It shows you all objects tracked by release policy in your container, grouped by component. Do not underestimate the value of it. This is a fantastic tool for locating objects with mismanaged lifetime (in other words – objects that should have been released but weren’t). If you see a number next to any of your components is suspiciously high or rising you may have just discovered a flaw in lifetime management in your app.

It is worth noting that there were some significant changes around release policies in Windsor 3 and what is tracked by the policy has changed as well. Those changes will be covered in a future post.

Components view

Most of the debugger views deals with showing components and there are some improvements in this area. Let’s go through most notable of them.

Top level view no longer shows a sequence number as “Name”. The number had no real meaning and we’re showing instead a much more important information – lifestyle of the component.
If lifestyle was not set explicitly (and Windsor falls back to its default for it) there will be an additional star (*) next to the lifestyle, like the “Now” component on the screenshot.
How we display the component was also greatly simplified to make it much more readable.
- We’re not showing the name Windsor’s using for the component, unless you explicitly set it. Otherwise it’s just noise.
- We’re showing C#-ified names of types so that they are much easier to read.
- To show open generic services we put dots (·) around generic parameters, so that they stand out from normal types.

Several other more minor improvements were introduced as well, but I won’t go into too much detail here.

Accessing diagnostics in code

Ever since the feature was introduced there were requests to provide programmable access to those diagnostics. It is now possible. Thanks to changes in internal infrastructure you can use new IDiagnostic<> interface (and it’s subinterfaces) to write code like this:

var host = Container.Kernel.GetSubSystem(SubSystemConstants.DiagnosticsKey) as IDiagnosticsHost;

var diagnostic = host.GetDiagnostic<IUsingContainerAsServiceLocatorDiagnostic>();

var serviceLocators = diagnostic.Inspect();

Assert.IsEmpty(serviceLocators);

I hope you’ll find all of those improvements useful.

What's new in Windsor 3: Service Locator usage detection

Krzysztof Koźmic — Sun, 24 Apr 2011 09:41:00 GMT

As we're nearing the release date of Castle Windsor 3.0 (codename Wawel) I will be blogging about some of the new features and improvements introduced in the new version.

One of the features that were introduced in current version 2.5 was support for debugger diagnostic views in Windsor.

In Wawel one of the improvements is addition of a new diagnostic - detection of cases where the container is being used as Service Locator. For those unfamiliar with what Service Locator is, it's an approach that breaks the basic rule of Inversion of Control, by explicitly calling out to the container from within application.

Here's where I tell you Service Locator is bad

I spent last two days reading through the StackOverflow archive of IoC related questions and one of the most common sources of problems is that container is being used as Service Locator.

I wrote why Service Locator (particularly when implemented via IoC container) is a bad idea on few occasions (for example here). Also Mark has a good overview of drawbacks of this approach so I won't rehash it again.

Good news is - even if someone from your team starts using the container as Service Locator, Windsor will now help you detect those cases.

Here's where I give you an example

Take a look at the following class:

[Singleton]

public class ComponentFactory

{

    private readonly IKernel kernel;

    public ComponentFactory(IKernel kernel)

    {

        this.kernel = kernel;

    }

    public object Create(String name)

    {

        return kernel.Resolve<object>(name);

    }

}

It is part of the application layer (and not infrastructure layer) and as such it should not be aware of the container, yet it depends on IKernel. Also quick look at its Create method is enough to see that it most likely is passed around throughout the application and used to pull components from the container without giving it much thought, which as you're surely guessing by now is a recipe for trouble.

Here's where I show you how it looks

If you navigate in debug mode to a container instance where components like the one described above exists a new entry in the debugger view will appear listing those components.

Here's where I tell you how it works

Windsor doesn't have the whole picture of your application, so it can only detect a subset of cases of Service Locator usage. In particular it is unable to detect the case when a Service Locator is built completely on top of the container as commonly found, where container is assigned to a public field of a static class and accessed through that field.

Since Windsor only knows about the components you register with it, it looks for components that depend on the container and are not extending infrastructure of the container itself (like for example Interceptors are). All such components are flagged as potential service locator and presented to you.

I hope you'll find this feature useful.

Here's where you tell me what you think

Working with NHibernate without default constructors

Krzysztof Koźmic — Sun, 20 Mar 2011 05:58:02 GMT

In the previous post we established that the usage of default constructor required by NHibernate is theoretically not required. The fact that NHibernate does use them though has to do with technical limitations of CLR. Turns out in most cases there is a workaround, which is not perfect but was a fun experiment to implement.

The code presented here is just an experiment. It is not of production quality – it is merely a proof of concept so if you use it in production and the world blows up, don’t blame me.

Interceptor

The place that NHibernate lets you plug into to instantiate entities and components as they are pulled from database is in NHibernate’s IInterceptor (not to be confused with Castle DynamicProxy IInerceptor) interface and its instantiate method. NHibernate has also a IObjectsFactory interface but that one is used to instantiate everything including NHibernate’s own infrastructure (like IUserTypes for example) and we want to override only activation of entities and components.

     public class ExtensibleInterceptor : EmptyInterceptor

    {

        private readonly INHibernateActivator activator;

        public ISessionFactory SessionFactory { get; set; }

        public ExtensibleInterceptor(INHibernateActivator activator)

        {

            this.activator = activator;

        }

        public override object Instantiate(string clazz, EntityMode entityMode, object id)

        {

            if (entityMode == EntityMode.Poco)

            {

                var type = Type.GetType(clazz);

                if (type != null && activator.CanInstantiate(type))

                {

                    var instance = activator.Instantiate(type);

                    SessionFactory.GetClassMetadata(clazz).SetIdentifier(instance, id, entityMode);

                    return instance;

                }

            }

            return base.Instantiate(clazz, entityMode, id);

        }

    }

The code here is straightforward. The INHibernateActivator is a custom interface that we’ll discuss in details below. That’s where the actual activation happens. We’re also using ISessionFactory so that we properly set the id of retrieved instance.

Proxy validator

Turns out that is not enough. In the interceptor we activate objects we fully obtain from the database. However big part of NHibernate performance optimisation is to ensure we don’t load more data that we need (a.k.a. lazy loading) and to do it transparently NHibernate uses proxies.

For every persistent type NHibernate uses object called proxy validator to ensure object meets all the requirements it has to be able to properly proxy a type and that work is done by IProxyValidator.

Part of the work of proxy validator is to check for default constructor so we need to override that logic to reassure NHibernate we have things under control.

    public class CustomProxyValidator : DynProxyTypeValidator

    {

        private const bool iDontCare = true;

        protected override bool HasVisibleDefaultConstructor(Type type)

        {

            return iDontCare;

        }

    }

Proxy factory

Now that we told NHibernate we can handle proxying types without default constructor it’s time to write code that actually does it. That’s the task of ProxyFactory which uses Castle DynamicProxy under the cover.

    public class CustomProxyFactory : AbstractProxyFactory

    {

        protected static readonly IInternalLogger log = LoggerProvider.LoggerFor(typeof (CustomProxyFactory));

        private static readonly DefaultProxyBuilder proxyBuilder = new DefaultProxyBuilder();

        private readonly INHibernateActivator activator;

        public CustomProxyFactory(INHibernateActivator activator)

        {

            this.activator = activator;

        }

        public override INHibernateProxy GetProxy(object id, ISessionImplementor session)

        {

            try

            {

                var proxyType = IsClassProxy

                                    ? proxyBuilder.CreateClassProxyType(

                                        PersistentClass,

                                        Interfaces,

                                        ProxyGenerationOptions.Default)

                                    : proxyBuilder.CreateInterfaceProxyTypeWithoutTarget(

                                        Interfaces[0],

                                        Interfaces,

                                        ProxyGenerationOptions.Default);

                var proxy = activator.Instantiate(proxyType);

                var initializer = new LazyInitializer(EntityName, PersistentClass, id, GetIdentifierMethod, SetIdentifierMethod,

                                                        ComponentIdType, session);

                SetInterceptors(proxy, initializer);

                initializer._constructed = true;

                return (INHibernateProxy) proxy;

            }

            catch (Exception e)

            {

                log.Error("Creating a proxy instance failed", e);

                throw new HibernateException("Creating a proxy instance failed", e);

            }

        }

        public override object GetFieldInterceptionProxy()

        {

            var proxyGenerationOptions = new ProxyGenerationOptions();

            var interceptor = new LazyFieldInterceptor();

            proxyGenerationOptions.AddMixinInstance(interceptor);

            var proxyType = proxyBuilder.CreateClassProxyType(PersistentClass, Interfaces, proxyGenerationOptions);

            var proxy = activator.Instantiate(proxyType);

            SetInterceptors(proxy, interceptor);

            SetMixin(proxy, interceptor);

            return proxy;

        }

        private void SetInterceptors(object proxy, params IInterceptor[] interceptors)

        {

            var field = proxy.GetType().GetField("__interceptors");

            field.SetValue(proxy, interceptors);

        }

        private void SetMixin(object proxy, LazyFieldInterceptor interceptor)

        {

            var fields = proxy.GetType().GetFields(BindingFlags.Public | BindingFlags.Instance);

            var mixin = fields.Where(f => f.Name.StartsWith("__mixin")).Single();

            mixin.SetValue(proxy, interceptor);

        }

    }

It is pretty standard and not very interesting. We’re again using the INHibernateActivator, we’ve yet to discuss, to create instances. Also since we’re not calling any constructors to do it, we have to set the proxy dependencies that would otherwise by provided via constructor inline. For that we’re using some internal knowledge about how DynamicProxy lays out its proxy types.

Good news is – we’re almost there. Actually we might want to also override NHibernate reflection optimizer. As its name implies replaces some actions that are performed via reflection with faster, compiled versions. The default one works with assumption that default constructor is available and may fail otherwise but we can disable that feature for our simple proof of concept application.

Proxy factory factory

There’s one more step actually – we need to attach out proxy factory and proxy validator to session factory and we do that via ridiculously named IProxyFactoryFactory

    public class CustomProxyFactoryFactory : IProxyFactoryFactory

    {

        public IProxyFactory BuildProxyFactory()

        {

            return new CustomProxyFactory(new NHibernateActivator());

        }

        public bool IsInstrumented(Type entityClass)

        {

            return true;

        }

        public bool IsProxy(object entity)

        {

            return (entity is INHibernateProxy);

        }

        public IProxyValidator ProxyValidator

        {

            get { return new CustomProxyValidator(); }

        }

    }

Putting it all together

Now that we have all these pieces let’s see how we put them together (with some help from FluentNHibernate)

    var config = Fluently.Configure()

        .Mappings(c => c.FluentMappings.AddFromAssemblyOf<Program>())

        .Database(MsSqlConfiguration.MsSql2008

                    .ConnectionString(s => s.Database("NHExperiment").Server(".").TrustedConnection())

                    .ProxyFactoryFactory<CustomProxyFactoryFactory>())

        .BuildConfiguration();

    var interceptor = new ExtensibleInterceptor(new NHibernateActivator());

    config.Interceptor = interceptor;

    NHibernate.Cfg.Environment.UseReflectionOptimizer = false;

    var factory = config.BuildSessionFactory();

    interceptor.SessionFactory = factory;

We set up our standard stuff – mapping and connection string. Then we need to tell NHibernate to use our custom ProxyFactoryFactory. Then we build configuration object and set our custom interceptor to it. Having done that we can build session factory and give the interceptor reference to the session factory. Certainly not the smoothest ride but gets the job done. Oh – and as I mentioned we disable reflection optimizer so that we don’t have to override yet another class (two actually).

That is all it takes to be able to get rid of all the seemingly superfluous constructors and have a much simpler model.

Well not quite – what about the activator

Right – the activator. How do we make that happen? Here’s all the code in this class.

    public class NHibernateActivator : INHibernateActivator

    {

        public bool CanInstantiate(Type type)

        {

            return true;

        }

        public object Instantiate(Type type)

        {

            return FormatterServices.GetUninitializedObject(type);

        }

    }

Remember how I said that NHibernate can be viewed as fancy serializer? Here we make it obvious by using System.Runtime.Serialization.FormatterServices class to give us an uninitialized instance of given type. Uninitialized means that all the fields will be null or 0 and no code will be ran. This however is precisely what we want for the reasons outlined in previous post. We then throw the object to NHibernate machinery to perform all the necessary initialization for us, so that when the object is returned from the session it is fully created and usable. We could also implement a mechanism similar to one of the options that standard .NET serialization provides to allow the object to initialize its volatile state.

Final words

That is all it takes to make the model a bit more persistence ignorant. Like I said this approach won’t work always. It requires full trust environment and probably if you have complex volatile state the solution will be too simplistic. I would be interested to hear what do you think about the approach in general. Can you spot any severe shortcomings or flaws? Do you like it? Would you use it?

NHibernate and default constructors

Krzysztof Koźmic — Sat, 19 Mar 2011 08:48:00 GMT

One of the first things you learn about NHibernate is that in order for it to be able construct your instances and take advantage of lazy loading every persistent class must have the default, parameterless constructor. This leads to having entities looking like this (standard blog with posts and comments example).

public class Post

{

    private readonly IList<Comment> comments = new List<Comment>();

    private Blog blog;

    [Obsolete("For NHibernate")]

    protected Post()

    {

    }

    public Post(string title, string body, Blog blog)

    {

        Blog = blog;

        Title = title;

        Body = body;

        Published = DateTimeOffset.Now;

    }

    public virtual int Id { get; private set; }

    public virtual DateTimeOffset Published { get; private set; }

    public virtual string Title { get; set; }

    public virtual string Body { get; set; }

    public virtual IEnumerable<Comment> Comments

    {

        get { return comments; }

    }

    public virtual Blog Blog

    {

        get { return blog; }

        set

        {

            if (blog != null)

            {

                throw new InvalidOperationException("already set");

            }

            blog = value;

            if (blog != null)

            {

                blog.AddPost(this);

            }

        }

    }

    [EditorBrowsable(EditorBrowsableState.Never)]

    protected internal virtual void AddComment(Comment comment)

    {

        comments.Add(comment);

    }

}

Notice the first constructor. It doesn’t do anything. As the obsolete message (which is out there to get compilation warning in case some developer accidently calls this constructor in their code) points out – this constructor is there only so that NHibernate can do its magic. Some people do put there initialization logic for collections, (especially when you use automatic properties) but I use fields and initialize them inline. In that case the constructor is pretty much useless. I started thinking why is it even there and that perhaps it doesn’t really belong to the class. But let’s start at the beginning.

What is a constructor

As basic as the question may seem, it is useful to remind ourselves why we need constructors at all. The best book about C# and .NET defines them as follows:

Constructors are special methods that allow an instance of a type to be initialized to a good state.

Notice two important things about this definition. First, it doesn’t say that constructor creates the instance or that constructors are the only way to create the instance. Second, constructors initialize newly created object to their initial state so that anything that uses the object afterwards deals with fully constructed, valid object.

Constructors and persistence

The above definition very well applies to the other constructor we have on the Post class. That constructor initializes the Post to a valid state. In this case valid means the following.

Post is part of a blog – we can’t have a post that lives on its own. Our posts need to be part of a blog and we make this requirement explicit by requiring a Blog instance to be provided when constructing Post.
Post requires a title and a body and that’s why we also require those two properties to be provided when constructing a post.
Posts are usually displayed in a inverse chronological order hence we set the Published timestamp.

We do none of the above in the other, “nhibernate” constructor. That means that according to the definition of a constructor it is not really doing what a constructor is supposed to be doing. It is never used to construct an object.

Hydration

Let’s take a step back now. What NHibernate is doing with objects in nutshell is serialization. You create an object in your code and initialize it using constructor, do some stuff with it and then you save the object away, so that it can be retrieved later, after your app has been closed, or perhaps on another server instance. You save away the state of the object so that the state representation of the object can live longer than volatile, in-memory representation of the object. If you follow this path of though the next obvious conclusion is that if you have a load-balanced system and two server instances work with Post#123 they both are dealing with the same object, even though they are two separate machines.

The conclusion of that is that when NHibernate is retrieving an object from the persistent store it is not constructing it. It is recreating an in-memory representation of an object that had been created and persisted previously. Hence we are merely recreating object that already has a well known state and had been initialized and just providing different representation for it. This process is called hydration.

Persistent and Volatile state

The full picture is a bit more complicated than what I painted so far. The database and in-memory object are two representation of the same entity but they don’t have to be fully one to one. Specifically it is possible for the in-memory representation to have state beyond the persistent state. In other words the in-memory object may have some properties that are specific to it, and not relevant to the in-database representation. A convenient example that most people will be able to relate to would be a logger. Please don’t quote me as advocating using logging in your entities but logger is one of the things you may want to have on your in-memory object and use it while executing code in your application but then let them go once you no longer need the object and not persist them. If we had one in the Post class the empty constructor would change to the following:

[Obsolete("For NHibernate")]

protected Post()

{

    logger = LoggerProvider.LoggerFor(typeof(Post));

}

If we don’t use constructor for recreation of the object, how can we get the logger in? How do we make NHibernate hold the contructor semantics and give us fully initialized object? Remember I said one way of looking at NHibernate from the object’s perspective is that’s just a fancy serializer/deserializer. Turns out serialization mechanism in .NET offers us four(that I know of, possibly more) ways of tacking this issue

you can use serialization surrogate that knows how to recreate the full state of the object
you can use deserialization callback interface to be notified when the object has been fully deserialized and then initialize the volatile state.
you can use serialization callback attributes to be notified when various steps in the serialization/deserialization process happen and initialize the volatile state.
you can use ISerializable interface and implement serialization constructor which is used to deserialize the object.

Notice that only one of those approaches uses special constructor. Since as we discussed NHibernate doesn’t really need the default constructor (in theory that is), can we really get rid of it? Turns one we can (in most cases), and we’ll look at how to do it in the next post.

Testing conventions

Krzysztof Koźmic — Wed, 09 Mar 2011 03:52:00 GMT

I already blogged about the topic of validating conventions in the past (here and here). Doing this has been a fantastic way of keeping consistency across codebases I’ve worked on, and several of my colleagues at Readify adopted this approach with great success.

Recently I found myself using this approach even more often and in scenarios I didn’t think about initially. Take this two small tests I wrote today for Windsor.

[TestFixture]

public class ConventionVerification

{

    [Test]

    public void Obsolete_members_of_kernel_are_in_sync()

    {

        var message = new StringBuilder();

        var kernelMap = typeof(DefaultKernel).GetInterfaceMap(typeof(IKernel));

        for (var i = 0; i < kernelMap.TargetMethods.Length; i++)

        {

            var interfaceMethod = kernelMap.InterfaceMethods[i];

            var classMethod = kernelMap.TargetMethods[i];

            Scan(interfaceMethod, classMethod, message);

        }

        Assert.IsEmpty(message.ToString(), message.ToString());

    }

    [Test]

    public void Obsolete_members_of_windsor_are_in_sync()

    {

        var message = new StringBuilder();

        var kernelMap = typeof(WindsorContainer).GetInterfaceMap(typeof(IWindsorContainer));

        for (var i = 0; i < kernelMap.TargetMethods.Length; i++)

        {

            var interfaceMethod = kernelMap.InterfaceMethods[i];

            var classMethod = kernelMap.TargetMethods[i];

            Scan(interfaceMethod, classMethod, message);

        }

        Assert.IsEmpty(message.ToString(), message.ToString());

    }

    private void Scan(MethodInfo interfaceMethod, MethodInfo classMethod, StringBuilder message)

    {

        var obsolete = EnsureBothHave<ObsoleteAttribute>(interfaceMethod, classMethod, message);

        if (obsolete.Item3)

        {

            if (obsolete.Item1.IsError != obsolete.Item2.IsError)

            {

                message.AppendLine(string.Format("Different error levels for {0}", interfaceMethod));

            }

            if (obsolete.Item1.Message != obsolete.Item2.Message)

            {

                message.AppendLine(string.Format("Different message for {0}", interfaceMethod));

                message.AppendLine(string.Format("\t interface: {0}", obsolete.Item1.Message));

                message.AppendLine(string.Format("\t class    : {0}", obsolete.Item2.Message));

            }

        }

        var browsable = EnsureBothHave<EditorBrowsableAttribute>(interfaceMethod, classMethod, message);

        {

            if (browsable.Item3 == false)

            {

                message.AppendLine(string.Format("EditorBrowsable not applied to {0}", interfaceMethod));

                return;

            }

            if (browsable.Item1.State != browsable.Item2.State || browsable.Item2.State != EditorBrowsableState.Never)

            {

                message.AppendLine(string.Format("Different/wrong browsable states for {0}", interfaceMethod));

            }

        }

    }

    private static Tuple<TAttribute, TAttribute, bool> EnsureBothHave<TAttribute>(MethodInfo interfaceMethod, MethodInfo classMethod, StringBuilder message)

        where TAttribute : Attribute

    {

        var fromInterface = interfaceMethod.GetAttributes<TAttribute>().SingleOrDefault();

        var fromClass = classMethod.GetAttributes<TAttribute>().SingleOrDefault();

        var bothHaveTheAttribute = true;

        if (fromInterface != null)

        {

            if (fromClass == null)

            {

                message.AppendLine(string.Format("Method {0} has {1} on the interface, but not on the class.", interfaceMethod, typeof(TAttribute)));

                bothHaveTheAttribute = false;

            }

        }

        else

        {

            if (fromClass != null)

            {

                message.AppendLine(string.Format("Method {0} has {1}  on the class, but not on the interface.", interfaceMethod, typeof(TAttribute)));

            }

            bothHaveTheAttribute = false;

        }

        return Tuple.Create(fromInterface, fromClass, bothHaveTheAttribute);

    }

}

All they do is ensure that whenever I obsolete a method on the container, I do that consistently between the interface and the class that implements it (setting the same warning message, and the same warning/error flag state). It also validates that I hide the obsolete method from Intellisense for people who have the option enabled in their Visual Studio.

Those are kinds of things, that are important, but they neither cause a compiler error, or compiler warning, nor do they fail at runtime. Those are kinds of things you can validate in a test. Those are small things that make a big difference, and having a comprehensive battery of tests for conventions in your application, can greatly improve confidence and morale of the team.