When using TeamCity as my CI server, my personal preference is to use the Command Line runner. I feel that this gives me the ultimate flexibility, as it is easy to pass parameters to a batch file, and the batch file can in turn be invoked to run a Nant script. It also ensures that my local build experience is as close as possible to what is happening on the build server.
What can I say? I am a control freak when it comes to this stuff.
Recently I was setting up a new build configuration and was having trouble passing in TeamCity environment variables. I tries a stack of variations on the theme but couldn’t seem to crack the right syntax. So here preserved in all its glory is the correct way to pass the environment variables to the command line.
1. Select ‘Add New Variable’ under Environment Variables in your build configuration
2. Define your variable name and value
When saved the variable will be renamed slightly and will appear like…
3. Add the syntactically correct reference to your command line parameters
The trick is to include the '%' symbol markers and also the 'env.' prefix on the name that you defined.
Enjoy!
I have long been convinced of the worth of OpenId. I am unsure if it is the ultimate solution - but for now it is definitely the best solution we have (imho). When I heard about RPX, a new integration service from JanRain, my interest sky-rocketed. Previously, the thought of manually integrating into the current OpenId world seemed intimidating to me. RPX solves that problem - hands down.
And what does a developer do when confronted by an open API? He writes a custom wrapper in his language of choice - that's what he does.
So this post announces RPXLib, now available on Google Code. It is a .Net wrapper meant to take some of the pain out of RPX integration by handling most of the boring stuff for you. It presents a simplified service API and returns strongly-typed response objects for you to play with. Be sure to take a peek at the documentation wiki.
It is worth noting that this works well on my machine - but I am very interested to hear from others about the benefit that this provides (or lack of benefits, even more importantly). I figure it takes about 2-3 minutes to read the doco and about another 10 minutes to integrate this into your application. Your mileage may vary and I would love to hear your experiences.
In the past few weeks I have revisited the specification pattern using Linq. I have teased it, toyed with it and tricked it up. And today I announce the public availability of a project demonstrating my current thoughts. You can grab the solution from Google Code at http://code.google.com/p/linq-specifications.
I have no doubt that improvements can and will be made if this generates any wider adoption. For now, it suits what I am currently working on quite nicely. YMMV.
Below is a class diagram of the current core of the project. Use it as a quick reference but be sure to check out the code for a more in-depth view.
Shortly I will do up a few examples on the project wiki that will flesh out some of the gotchas I have come across already and I need some more testing around some of the elements. For now, however, I just wanted to get this out in the wild. Feel free to comment/flame. I look forward to any feedback.
Using the container scoping capablity of Autofac makes NHibernate session management a breeze. Obviously this only handles the most basic session-per-request scenario but we know that can cover a large percentage of most peoples requirements anyway. I am sure other containers could get to this functionality as well, but I was blown away by how easy it was aith Autofac. Below is my session management configuration:
builder.Register<NHibernateInstance>().SingletonScoped();
builder.Register(c => c.Resolve<NHibernateInstance>().CreateSession()).As<ISession>().ContainerScoped();
builder.RegisterGeneric(typeof (Repository<>)).As(typeof (IRepository<>)).ContainerScoped();
So the key points are:
- Plug in the Autofac HttpHandler for ASP.Net integration by following the instructions here
- Have a singleton instance of the NHibernate session factory (housed in my NHibernateInstance class)
- Have a method on that singleton registered instance that returns an ISession (CreateSession in my example)
- Configure a container scoped instance of the NHibernate ISession, thus ensuring that the created instance will not cross request boundaries
- Have the container dynamically inject the ISession into your IRepository implementation
For more information on container scoping in Autofac for ASP.Net web applications check out the Autofac wiki article.
In the previous to parts to this series (here and here) I showed the basic infrastructure framework for using Linq-based specifications with a flexible repository interface. In this article I dig deeper into the Expression based find functionality and it's implementation.
The Goal
Specification based query support on the repository is a great feature for encapsulation of any query logic. My major problem with this approach was the creation of trivial specifications on a per-domain-object basis. This would litter the code with specifications that had very little functionality contained within them. Generally this is not a bad thing but, in this instance, for the sake of maintainabilty and simplicity I wanted a to be able to perform ad-hoc queries.
The solution was to make my repository able to accept queries like :
var repository = new Repository<Person>(session);
var people = repository
.FindAll(p => p.Name == "steve");
The AdHoc specification
Since I have already made the decision that my MatchingCriteria are of type Expression, the AdHoc specification is trivial - but very cool. The implementation looks like :
public class AdHoc<T> : Specification<T> where T : IEntity
{
private readonly Expression<Func<T, bool>> expression;
public AdHoc(Expression<Func<T, bool>> expression)
{
this.expression = expression;
}
public override Expression<Func<T, bool>> MatchingCriteria
{
get { return expression; }
}
}
Simplifying the repository using the AdHoc specification
By utilising this simple but powerful specification class we can simplify the api to our IRepository. We are now able to add a FindOne and FindAll overload that accept Linq based queries in an AdHoc fashion. The implementation is as simple as :
public IQueryable<T> FindAll(Expression<Func<T, bool>> expression)
{
return FindAll(new AdHoc<T>(expression));
}
This functionality is able to be consumed in the following fashion (satisfying our goal for this task) :
var people = repository.FindAll(p => p.Name == "steve");
Conclusion
In combination with the flexibility built into the IRepository interface we now have a basis for a data access layer with maximum flexibility. Sql queries are created at execution time to reflect the criteria that we have applied through domain specifications - be they concrete or ad-hoc.
In Part 1 of this series I expressed my goal of a powerful Linq implementation for the specifications within my domain. In this part of the series I go into further detail and show I have implemented my repositories to support the pattern.
The IRepository definition
In the code below I have restricted my IRepository to be read-only for the purposes of the exercise. Obviously in reality there would be more functionality defined on this interface.
The use of the specification as a parameter to the Find methods is obvious. The use of an Expression is not so obvious at this stage and I will elaborate on this functionality later in the series.
public interface IRepository<T> where T : IEntity
{
T FindOne(Guid id);
T FindOne(Expression<Func<T, bool>> expression);
T FindOne(Specification<T> specification);
IQueryable<T> FindAll();
IQueryable<T> FindAll(Expression<Func<T, bool>> expression);
IQueryable<T> FindAll(Specification<T> specification);
}
The Repository
Implementing the repository means tying oneself to a particular Linq provider. In my case I chose Linq to NHibernate but switching it out for another implementation should be trivial.
See in the repository implementation that work is able to be integrated with the specifications by calling either SatisfyElementFrom (FindOne) of SatisfyElementsFrom (FindAll) and providing a candidate parameter provided by the Linq provider - in this case Linq to NHibernate provides a Queryable list proxy when we specify session.Linq().
public class Repository<T> : IRepository<T> where T : IEntity
{
private readonly ISession session;
public Repository(ISession session)
{
this.session = session;
}
public T FindOne(Guid id)
{
return session.Get<T>(id);
}
public T FindOne(Expression<Func<T, bool>> expression)
{
return FindOne(new AdHoc<T>(expression));
}
public T FindOne(Specification<T> specification)
{
return specification.SatisfyingElementFrom(session.Linq<T>());
}
public IQueryable<T> FindAll()
{
return (from t in session.Linq<T>() select t);
}
public IQueryable<T> FindAll(Expression<Func<T, bool>> expression)
{
return FindAll(new AdHoc<T>(expression));
}
public IQueryable<T> FindAll(Specification<T> specification)
{
return specification.SatisfyingElementsFrom(session.Linq<T>());
}
}
Conclusion
In this article I have shown an implementation of my repository facilitated by the use of Linq to NHibernate. The most striking part is the simplicity of the code. We have nicely seperated out our query concerns and the repository provides us with flexibility and also efficiency thanks to the power of Linq.
