Cannot change Class being register with Autofac

Topics: Customizing Orchard, Troubleshooting, Writing modules
Aug 24, 2012 at 4:56 PM

Hi Folks,

I have an interface ICoolServiceSettings, with two implementations, FakeCoolServiceSettings and RealCoolServiceSettings. These are declared in a class libarary, referenced from an orchard module project. In the Orchard module project I have registered the classes with autofac as follows

public class AutoFacRegistration : Module
    {
        protected override void Load(ContainerBuilder builder)
        {
            builder.RegisterType<SomeService>().As<ISomeService>();
            builder.RegisterType<FakeCoolServiceSettings>().As<ICoolServiceSettings>();
            builder.RegisterType<JSomeHelper>().As<ISomeHelper>();
        }
    }
The contents of the class are extremely simple - one string property. When I try to register a different type by altering the registration from  FakeCoolServiceSettings to RealCoolServiceSettings Orchard bombs completely and I get the following in the log

 

System.TypeLoadException: Could not load type 'blah.blah.Services.RealCoolServiceSettings' from assembly 'blah.blah.Services, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
   at blah.blah.Orchard.Module.AutoFacRegistration.Load(ContainerBuilder builder)
   at Autofac.Module.Configure(IComponentRegistry componentRegistry)
   at Autofac.ContainerBuilder.Build(IComponentRegistry componentRegistry, Boolean excludeDefaultModules)
   at Autofac.ContainerBuilder.Update(IComponentRegistry componentRegistry)
   at Autofac.Core.Lifetime.LifetimeScope.CreateScopeRestrictedRegistry(Object tag, Action`1 configurationAction)
   at Autofac.Core.Lifetime.LifetimeScope.BeginLifetimeScope(Object tag, Action`1 configurationAction)
   at Orchard.Environment.ShellBuilders.ShellContainerFactory.CreateContainer(ShellSettings settings, ShellBlueprint blueprint) in d:\...\src\Orchard\Environment\ShellBuilders\ShellContainerFactory.cs:line 47
   at Orchard.Environment.ShellBuilders.ShellContextFactory.CreateShellContext(ShellSettings settings) in d:\...\src\Orchard\Environment\ShellBuilders\ShellContextFactory.cs:line 61
   at Orchard.Environment.DefaultOrchardHost.CreateShellContext(ShellSettings settings) in d:\...\src\Orchard\Environment\DefaultOrchardHost.cs:line 174
   at Orchard.Environment.DefaultOrchardHost.CreateAndActivateShells() in d:\...\src\Orchard\Environment\DefaultOrchardHost.cs:line 134
2012-08-24 16:41:56,921 [5] Orchard.Environment.DefaultOrchardHost - Done creating shells
2012-08-24 16:41:56,938 [5] Orchard.Environment.DefaultOrchardHost - EndRequest

I get the same issue if I rename the working registered class FakeCoolServiceSettings to Fake2CoolServiceSettings. Please note I rename this using VS2012 renaming functions, and I've checked every reference I can see, everything looks and builds correctly.

Does anyone have an idea why autofac cannot register my class (including the one that works when I simply rename it?

This one is driving me made. My only guess is some form of caching of registrations, but it persists through rebuilds and closing VS etc.

Help much appreciated.

Aug 28, 2012 at 10:23 AM

Has no one experienced this before?

Developer
Aug 28, 2012 at 11:39 PM

I haven't. But perhaps you could inject an IEnumerable<ICoolServiceSettings>, and pick the one you need?

Developer
Aug 28, 2012 at 11:41 PM

Oh wait, I totally misread the issue. You're not trying to register 2 implementations for one interface, you're having an issue related to the name of your concrete implementation. How weird.

Developer
Aug 28, 2012 at 11:44 PM

Just a wild guess, but when you rename the class and recompile, do you also recycle the application pool (or save web.config which causes a recycle)? Did you try a complete rebuild (manually deleting all bin & obj files from all modules, including orchard.web).

Aug 30, 2012 at 8:47 AM

Hi folks,

issue resolved. Being a VS coder, I was only looking for the solution within files in the solution. The real answer was I had a folder with a previous attempt at the module sitting on disk (no longer included in the solution). This folder also had a class of the same name, which caused the issue. It's one that has caught me several times.

Honestly, dynamic compilation is a real pain  when trying to work in a VS/source controlled environment rather than Webmatrix - as anyone retrieving all from source will still get these folders (as they are still in source control with their valid source history). I'm not sure if there are any good ways to avoid this issue recurring.