We had a nasty little bug in one of our development stage Episerver projects.
Everything ran and worked smoothly, but one day Episerver’s error logs started to report an exception regarding the Episerver.Find.Commerce module.
However, the site seemed to work properly so the bug hunt could be scheduled to another day.
Things escalated when Episerver made some error handling changes in the Episerver.Find.Commerce version 10.1.1.
When the new version was applied to our project, the only thing we were able to get was a 500 error.
Logfiles told the same story as before, but because of the version update there was no more excuses to move the bug hunt any further.
First suspicions were that there must have been something wrong with our initialization modules regarding the Episerver.Find.Commerce.
Through “extensive” debugging and basically removing every custom code that could even remotely have an impact to the Find.Commerce. But. Only one thing was left, the same error in the error log.
Now what? Maybe cleaning the solution, rebuilding it, removing asp.net temporary files, removing bin and obj -folders.
Perhaps the previous installation of the nugets failed for some reason. Removed nugets and reinstalled them. Restarted Visual Studio.
Still. The same error was there.
Ok. At this point it was obvious that there must be a DLL missing or some other reference related problem. And it probably isn’t even related to Episerver.
Even though the error in the log indicated that there might be a problem in Episerver.Find.Commerce, there was also another hint regarding how to get more specific information about those missing references.
Key to resolve this issue were the loader exceptions.
While I first started to investigate this, I noticed that some our custom initialization modules where firing and I was able to get a breakpoint there before the 500 error. That was a one place to put some temporary debugging code in.
And there it was. A third-party integration through DI (structuremap), having not any other relation to Episerver, was missing a DLL, but it was hidden behind someway misleading error information.
After putting the DLL in place, everything started to work again, and the error was resolved.
So, the teaching of this story is: Check those loader exceptions first, as it was mentioned in the original error message.
Thank you for reading. Feel free to give me a comment on Twitter.