This project has moved. For the latest updates, please go here.


Could not load file or assembly 'Nito.AsyncEx.Enlightenment'


  1. PCL (net45+wp8+win8) which has ref to Nito.AsyncEx NuGet.
  2. Windows Phone 8 app with ref to the PCL and Nito.AsyncEx NuGet.
After using AsyncLock inside the PCL there is error:

Could not load file or assembly 'Nito.AsyncEx.Enlightenment, Version=, Culture=neutral, PublicKeyToken=09d695329ca273b7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Closed Dec 30, 2013 at 9:47 PM by StephenCleary


inTagger wrote Dec 20, 2013 at 9:43 AM

Actually it seems that any method call of any class from Nito.AsyncEx throws this exception.

StephenCleary wrote Dec 20, 2013 at 2:48 PM

I have been able to duplicate this.

For now, you can remove the reference to Nito.AsyncEx.Enlightenment from your Windows Phone 8 app. This will allow it to run; it just won't be quite as efficient as it could be.

In the meantime, I will look into a permanent fix.

StephenCleary wrote Dec 21, 2013 at 8:42 PM

It's fixed now, as of 2.1.3.

The bug was introduced in 2.1.0 when I changed the enlightenment assemblies from PCLs to platform-sepecific dlls (i.e., the WP7 and WP8 enlightenments previously were PCLs and are now WP7/WP8 libraries). AFAICT, WP7/WP8 projects do not support strong name signing, so those enlightenments are not (cannot be) signed. Meanwhile, the core PCL was looking for an enlightenment dll matching its own signature, causing the problem.

This bug was compounded by an error in the enlightenment dll loading logic, which would throw exceptions instead of loading the default enlightenment. This was due to my not reading the documentation for Type.GetType; it turns out that if you pass false for the throwOnError argument, the method will still throw exceptions for some errors (including a signature mismatch).

The permanent solution put in 2.1.3 is to relax the enlightenment dll search to find enlightenments that are not strong name signed. Furthermore, the enlightenment logic has been made more robust, so that if the enlightenment dll is corrupted or whatnot, the default enlightenment will be loaded instead. There are still just a handful of situations where an exception could happen (e.g., if a static constructor for the platform enlightenment threw an exception), but that should never occur.

inTagger wrote Dec 22, 2013 at 4:48 AM

Good. Thank you.