I love reading code. I was recently glancing over the Sharp Architecture codebase looking for new and interesting ideas when I picked up an unexpected little trick. I tend to find little tricks in unexpected places whenever I am reading other people’s code. This trick isn’t so much coding related as it is tooling related. Visual Studio has an easily overlooked ability to link source files from directories outside of the project root. This same functionality can be used to share files between projects.
Sharing Files
Sharing files is relatively easy. Simply bring up the Add Existing Item dialog box (right click on the desired location in Solution Explorer and select Add > Existing Item) and highlight the desired file. Click the dropdown arrow to the right of the Add button and you will see another option labelled Add as Link. It’s that simple. Checkout this screenshot if you need clarification:
File Sharing Put to Use
The Sharp Architecture project takes advantage of file sharing for versioning assemblies. In order to stamp all assemblies with the same version numbers, a common assembly information file is placed at the root of the solution. All projects link to this file, so if the assembly information is modified from within one project, all other projects see the same changes. Obviously, this makes changing product versions very easy.
I am tinkering with the idea of using this approach to unit test my StructureMap configuration. I don’t want my unit test project to have a dependency on my WPF project, but I want to test my configuration bootstrapper. I am linking to the Bootstrapper.cs file in my WPF project from my unit test project. Be forewarned, I am not yet certain this is a particularly good way of going about this. Heck, I haven’t really given it a try yet!
Whether or not you currently have a need for linking files in this manner, it never hurts to have another tool in your arsenal.
I am using StructureMap as my IoC tool for Dependency Injection. I also use a generic contract for my repositories: IRepository<T>. When configuring StructureMap to use generic types, it must be done using the non-generic overload of the Registry.ForRequestedType method:
public class MainRegistry : Registry
{
protected override void configure()
{
. . .
ForRequestedType (typeof (IRepository<>))
.TheDefaultIsConcreteType (typeof (NHibernateRepository<>));
. . .
}
}
This allows me to receive a NHibernateRepository of the desired type when I request for an IRepository.
I am experimenting with Linq to NHibernate for building small applications. Although it is still in an infantile state, things look promising! Linq to NHibernate needs to be made a high priority project if we want to spread adoption for NHibernate. Many shops will not want to invest time (read: money) into learning NHibernate's awkward criteria API when LINQ offers rich querying capabilities that most developers will, nevertheless, be exposed to.