Why am I getting an exception raised from Spring.NET on the call to ContextRegistry.GetContext()?

ChrisF picture ChrisF · Apr 19, 2009 · Viewed 13.4k times · Source

Even though the solution is so obvious I should have never have posted this, I'm leaving it up as a reminder and a useful point of reference to others.

I've got the following in my app.config file:

<sectionGroup name="spring">
  <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
  <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>

Followed by:

<spring>
  <context>
    <resource uri="config://spring/objects"/>
  </context>
  <objects xmlns="http://www.springframework.net">
    <object name="mediaLibrary" type="AlbumLibraryWPF.AlbumLibrary, AlbumLibraryWPF"/>
  </objects>
</spring>

Then in my app I've got:

using Spring.Context;
using Spring.Context.Support;

public partial class AlbumChecker : Window
{
    private DataTable dataTable;

    private Library library;
    private Thread libraryThread;

    public AlbumChecker()
    {
        InitializeComponent();

        CreateToolTips();

        IApplicationContext ctx = ContextRegistry.GetContext();
        library = (Library)ctx.GetObject("mediaLibrary");

        // Other initialisation
    }

    // Other code
}

It all compiles quite nicely, however, I'm getting an exception raised on the call to GetContext():

Error creating context 'spring.root': Could not load type from string value
'AlbumLibraryWPF.AlbumLibrary, AlbumLibraryWPF'.

I've checked the Spring.NET documentation and can't see what I'm doing wrong - but I clearly have got something wrong, otherwise it wouldn't raise the exception!

AlbumLibraryWPF is the namespace and AlbumLibraryWPF.AlbumLibrary is the fully qualified name of the class I want to instantiate. I'm guessing that it's this I've got wrong, but can't see how.

Answer

ChrisF picture ChrisF · Apr 19, 2009

I feel such a fool.

It was because I'd failed to copy the AlbumLibrary.dll to the correct output directory. That meant that Spring couldn't find it - even after I'd fixed the assembly name problem Kent highlighted.