Autofac registering a dependency for non-existent library
A case in which the problem wasn't in the code
Problem
Last week, our team ran into an issue which was, individually, leaving us scratching our heads. In the end, the entire process boiled down to one hidden checkbox.
We were receiving the following exception:
None of the constructors found with 'Autofac.Core.Activators.Reflection.DefaultConstructorFinder' on type '...[Type]...' can be invoked with the available services and parameters: Cannot resolve parameter '...[Interface]...' of constructor 'Void .ctor(...params...)
So, in a nutshell, your typical Autofac complaint when something isn't registered correctly.
But here is the weird part: The type that was throwing the error didn't appear exist in the codebase anywhere.
Background
I work in a small team, right now it's just two of us. Both of us have worked in this project for years along with several others who have come and gone, but neither of us created it originally. We both know the project inside and out. The project basically boils down to a set of jobs scheduled to run regularly on a large database. So when my partner asked if I had any idea what the job was that was throwing the exception, I was as mystified as he was.
Debugging
He'd already taken the obvious step of searching for the offending type in the code, with no success. As we were pulling up the Autofac registrations, I remembered an issue that a former teammate and I had experienced a couple of months ago. In that case, a dll file on the server wasn't replaced when we had published the project. We ended up manually deleting the dll on the server and republishing the project, which in turn solved the problem.
I recounted the experience to my partner and he showed me a checkbox option I'd never thought to look at in the publish profile: "Remove additional files at destination."
Sure enough, we selected the box, published the project and the problem was solved.
Lessons learned
During my time as an intern at Intel, testing products, I learned that sometimes the issue isn't the code and we, as developers, must look past the code. This experience helped to reaffirm this notion. It also validates my constant questions to co-workers. "Hey, have you seen this before" or "Do you have any ideas on this one." can both be critical to uncovering an issue. In this case, I knew the problem and my partner knew the fix. What could have taken hours to discover the fix individually took less than two minutes together.
tl;dr: Talk to your teammates because you'll solve issues faster.
Software Development Nerd