Unity cannot find named component when assembly is built with optimize setting

Nov 21, 2014 at 11:40 AM
I've asked this same question on Stack Overflow but thought I'd try here too.

I'm having a strange issue with Unity not resolving my named instance when I build my solution in Release configuration with the optimize code setting checked.

I've enabled fusion logging and it doesn't seem to be an assembly binding issue.

I've opened the compiled assembly using a decompiler and the class seems to be there so it;s not being optimised out because it's not referenced anywhere.

The assembly reference seems okay because my application doesn't throw any errors when it's trying to register the class with the container.

I'm not sure what else to check.

This is how I register the dependencies.
// these updaters are one assembly with lots of other code, they're resolved okay
Container.RegisterType<IClientUpdater, MayriseUpdater>("Client1");
Container.RegisterType<IClientUpdater, MayriseUpdater>("Client2");
// this updater is in an assembly with nothing else in it 
Container.RegisterType<IClientUpdater, RutlandUpdater>("Client3");
This is how they are resolved
updater = this._container.Resolve<IClientUpdater>(client.Name);
A few last things to add, this only seems to happen in IIS. IIS Express seems to work fine.

I do get an assembly binding error for an assembly which the RutlandUpdater depends on but the MayriseUpdater also depends on the same one and works okay so I think this might be a red herring.
Nov 21, 2014 at 7:22 PM
That does seem strange. Do you have the exception information along with Stack Trace? My first thought is something related to the ASP.NET shadow copy folder since that can sometimes be a source of problems.

Is it possible to upload a sample solution that reproduces the issue?

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Nov 23, 2014 at 11:45 AM
randylevy wrote:
My first thought is something related to the ASP.NET shadow copy folder since that can sometimes be a source of problems.
I thought that as well but it seems unlikely as it's happened on our server and my local dev environment.

I'll try and create a solution which reproduces the error and upload a stack trace on Monday.

Thanks
Ben
Nov 24, 2014 at 12:24 PM
Well I feel silly, I never actually checked the exception before, I just assumed it wasn't resolving an instance. It was resolving an instance perfectly well, it was a component within that which has an issue. FYI the CommonLogging log manager doesn't work as an instance variable in Release config, it needs to be static.

Thanks
Marked as answer by BenCrinion on 11/24/2014 at 7:02 AM