views:

460

answers:

6

I'm using Castle Windsor for dependency injection in my test project. I'm trying to create an instance one of my 'Repository' classes. "It works fine on my machine", but when I run a nightly build in TFS, my tests are not able to load said classes.

private static readonly WindsorContainer _container = new WindsorContainer(new XmlInterpreter());


    public void MyTestInitialize()
    {
        var testRepository = (IBogusRepository)_container[typeof(IBogusRepository)];

    }

xml configuration:

<castle>
    <components>
      <component id="primaryBogusRepository" type="Example2008.Repository.LALALALALA, Example2008.Repository" service="Example2008.Domain.Repository.IBogusRepository, Example2008.Domain" />
      <component id="primaryProductRepository" type="Example2008.Repository.ProductRepository, Example2008.Repository" service="Example2008.Domain.Repository.IProductRepository, Example2008.Domain" />
    </components>
  </castle>

When I queue a new build it produces the following message:

Unable to create instance of class Example2008.Test.ActiveProductRepositoryTest. Error: System.Configuration.ConfigurationException: The type name Example2008.Repository.LALALALALA, Example2008.Repository could not be located.

Castle.Windsor.Installer.DefaultComponentInstaller.ObtainType(String typeName) Castle.Windsor.Installer.DefaultComponentInstaller.SetUpComponents(IConfiguration[] configurations, IWindsorContainer container) Castle.Windsor.Installer.DefaultComponentInstaller.SetUp(IWindsorContainer container, IConfigurationStore store) Castle.Windsor.WindsorContainer.RunInstaller() Castle.Windsor.WindsorContainer..ctor(IConfigurationInterpreter interpreter) Example2008.Test.ActiveProductRepositoryTest..cctor() in d:\Code_Temp\Example Project Nightly\Sources\Example2008.Test\ProductRepositoryTest.cs: line 19

From this message, it seems that my configuration is correct (it can see that I want to instantiate the concrete class 'LALALALALA', so the xml configuration has obviously been red correctly)

I think I have my dependencies set up correctly as well (because it works locally, even if I clean the solution and rebuild).

Any thoughts?

(using VS2008, TFS 2008.Net 3.5, Castle 1.03, by the way)

A: 

It sounds like the assembly that holds the repository implementations is missing from the bin directory (or wherever your executing directory is for the build).

I would first check to see if the assembly exists in the build server's executing directory.

If it does exist, then I would check to make sure the version of the assembly is the right one, i.e. has the repository implementation on it in the same namespace etc.

It may be that your build server is executing/building the objects somewhere else than where VS is executing/building.

Gilligan
A: 

that sounds plausible, but how do I get it there? which directory does TFS perform it's tests in?

I checked, and the repository dll is apparently not deployed to

server\Build_output\Example Project Nightly_20080919.9\TestResults\9598f1df-cd1d-49b2-a915-4ee06532ef9f\Out

(while the rest of the files are)

should it not be copied there automatically? (it is a project reference, after all, and copy local is set to true)

ampburner
A: 

I am not sure how exactly TFS builds its solutions, but the build path information looks like it may be putting it one of the parent directories, perhaps in server\Build_output\Example Project Nightly_20080919.9.

Is this the only project reference that is not deployed to the folder?

As for now, I might try the following things:

  • add an msbuild target that manually copies the assembly to the TFS Out directory. I unfortunately know not how to do this in TFS.

  • On your Test Setup method log the value of AppDomain.CurrentDomain.BaseDirectory. This will tell you what directory the app is using to find its assemblies.

Gilligan
A: 

hmmm.... AppDomain.CurrentDomain.BaseDirectory is apparently D:\Microsoft Visual Studio 9.0\Common7\IDE\ ?

ampburner
A: 

That is...interesting. I found this blog post that may help your issue. It looks like MSTest is using that as its working directory, which is annoying to say the least. The blog post shows how to change the directory, so that you can have consistent results. I would also do some Googling to find out if a more elegant solution exists.

Gilligan
A: 

Thanks! First of all I wanted to say that I really appreciate your help Gillian :)

That works in the sense that the tests now run out of Example Project Nightly\TestResults\service-tfs1_BION 2008-10-04 11_36_46_Any CPU_Debug\Out

But it still only deploys the test project dll, and not it's dependencies or config files. I guess that could be fixed with an msbuild deploy target.

I had actually given up on this, and decided that I didn't really NEED to use dependency injection in my unit tests - that in my case, it was sufficient to just instantiate my classes directly, so I had left it at that. I probably won't be using this in the direct future, but I'm sure I might need to do this again some time, so thanks.

If anything, I'll be sleeping a lot better ;)

ampburner