Unity 2.0 throws FileLoadException instead of FileNotFoundException

Nov 29, 2011 at 1:01 PM

I am upgrading unity 1.2 to 2.1. I had used UnityConfigurationSection.Containers["containerName"].Configure(unityContainer) to configure the unity in my application but now I have changed the method to UnityConfigurationSection.Configure(unityContainer, "containerName") as recommended in Unity 2.1 documentation. I have a unit test which checks that if a file is missing then Unity should throw "FileNotFoundException" in Unity 1.2 but with Unity 2.0 I am getting "FileLoadException" instead of "FileNotFoundException". I couldn't find this change anywhere in the documentation. Can anyone please confirm that this has changed or do I need to dig a bit further to get the accurate answer.




Nov 29, 2011 at 11:08 PM

Unity itself does not explicitly throw a FileNotFoundException or a FileLoadException -- those are thrown by the .NET framework.  So, that is why you don't see it any Unity documentation.

Either the .NET framework behavior changed or Unity could be calling different .NET methods.  For example, in .NET 3.0 Type.GetType(string) would throw FileNotFoundException and FileLoadException (among others) but in .NET 4.0 Type.GetType(string) no longer throws FileNotFoundException.

If you are really interested in what the specific reason is check into the stack trace or download the Unity source and debug it (you could do the same with .NET source).


Randy Levy
Enterprise Library support engineer

Dec 20, 2011 at 6:05 PM

I've had this problem and fixed it. According to FusLogVw.exe stemmed from the VJSharpCodeProvider, which I knew was definitely not the problem! Here is my code, that was unchanged, when it broke

IUnityContainer diContainer = new UnityContainer();
var unitySection = (ConfigurationManager.GetSection("unity") as UnityConfigurationSection);
unitySection.Configure(diContainer); //<-- Error here!!

To solve it, I commented out all registrations and re-introduced them 1 at a time. Ensure the <container> section is still there, <alias> seems to work fine in there.

I found I'd somehow reverted to an old mapping, which didn't exist and the framework said it was a VJSharpCodeProvider, when it was actually a mapping that didn't exist.

Hope this helps,