I recently wasted over an hour dealing with a horrible development experience that made me wonder if I had strayed into some sort of sadistic alternate universe. And since bumping into this little slice of hell was so simple, I thought I’d share what I learned as a public service—lest anyone else bump into this same problem and question their sanity as I did.
Confusion Abound
What made this problem so difficult and confusing was the fact that I’ve come to heavily rely on IntelliSense (but haven’t we all?). More specifically, I was working on one of my own development efforts in a Visual Studio 2010 solution that was composed of six different projects. A number of the projects were simple class libraries where core functionality, interfaces, and other requisite members had been defined. However, one of these projects was also tasked with data access and persistence.
In order to make my problem easier to understand, the namespace in my solution roughly looks like the following:
- MyProject
- MyProject.Communication
- MyProject.Data
- MyProject.Localizatiion
- MyProject.Service
- MyProject.Tests
Each namespace listed above is a C# project, and the MyProject.Service project is just a placeholder ConsoleApp that is dependent on everything else in the solution, except for the MyProject.Tests project, which stores my unit tests.
Initially, the MyProject.Data assembly was using a NoSQL backend, but upon receiving intermittent ‘service unavailable’ errors when testing a hosted NoSQL offering, I decided to ditch that approach and go with a SQL Server storage solution backed by PLINQO.
After adding in all requisite PLINQO dependencies and generating a SQL Server backed persistence layer, the MyProject.Service simply would not build, claiming that it wasn’t able to find objects clearly defined in the MyProject.Data namespace and assembly. Like any good .NET developer, I cleaned my solution, and manually rebuilt each dependent project to make sure that build errors in my lower assemblies weren’t preventing the requisite objects from being visible.
Although everything was built correctly, Visual Studio was still telling me that it didn’t recognize classes that were clearly defined in the MyProject.Data assembly. Was I missing an assembly reference it politely asked? So, I tried voodoo—meaning that I removed and re-added these assembly references. Nothing changed.
When the Universe Stops Making Sense
Still thinking that this was just a minor setback or a simple hiccup, I went into the .cs files where Visual Studio was having a hard time finding necessary references. For kicks and giggles, I deleted the ‘using MyProject.Data; statement at the top of one of my files. Then, things got very interesting because in the lines below where I was working with these classes, Visual Studio prompted me to include the exact statement that I had just removed.
Baffled, I repeated this exercise a few times, trying to think of what might cause the C# compiler to miss these references, even though Visual Studio was able to see those same classes by prompting me to include the correct namespaces needed to use them. So, I cracked open the Object Browser and pointed it at the MyProject.Data assembly. Sure enough, the classes and objects in question were all there, just as I had assumed they would be.