How best to organise my Visual Studio solution for Unit Tests and Dependency Injection

I have a fresh Visual Studio 2012 solution which consists of the following projects:

x1 Asp.Net Web API project (This holds my MVC/API controllers)

x1 Services project (based on the ASP.NET Empty Web Application template)

I've created two additional projects for the above (based on the ASP.NET Empty Web Application template) which I've labelled as my test projects.

I'm slowly getting my head around the whole TDD and DI approach to development hence my brain is a little swiss cheesed at this late hour.

I would like guidance on where I should setup DI and my unit tests. The approach I'm taking is to put as many of my methods in to my 'services' project. My main Web API project has a reference to my services project, so I can access all my public methods from that class library (I think that's the correct terminology).

I've now hit a brain block! I want to unit test as much as possible all the methods I expose in my services project. However my DI container (Castle Windsor) is only setup in my main API project, given that it has controllers etc.

So question:

1. For my services project do I just forget DI and write my unit tests direct to the concrete classes/interfaces? The reason I ask is because the Castle Windsor examples I've seen have been around setting up a container for my controllers/MVC web application and then instantiating the container via the application startup in global.ascx. If I should be using DI in my services project, how would I instantiate a container and where?

2. Following on from question 1, I wanted to gauge peoples opinions on where/how to structure all my unit tests. The easiest place to stick my tests would be in my main Web API project, given that everything I'm doing is either directly coded in that project or pulled in as a reference (my services project in this case).

That said I would imagine it would be better to have tests written exclusively for my services project, of which are contained in their own project. That way I can test my methods without the Web API project being involved at any level. Who knows, the Web API project might get canned but the services project is recycled for a different platform (hopefully you can see where I'm going with this).

The end goal of all this is to have most of my methods held in a services project, reusable for other projects in whatever form they may come. To have my Web API and other future MVC web applications pull functionality from my services library. All the while I have maintainable, manageable and above all 'testable' projects.

I'm at the start of my development cycle and doing all that I can in reading articles and reaching out to those in the know to get best advise so I can create solid foundations for my project.