The Problem I got a compilation error in my ASP.NET MVC3 project that tested my sanity today. (As always, names are changed to protect the innocent) The type or namespace name 'FishViewModel' does not exist in the namespace 'Company.Product.Application.Models' (are you missing an assembly reference?) Sure looks easy! There must be something in the project referring to a FishViewModel. The Confusing Part The first thing I noticed was the that error was occuring in a folder clearly not in my project and in files that I definitely had not created: %SystemRoot%\Microsoft.NET\Framework\(versionNumber)\Temporary ASP.NET Files\
App_Web_mezpfjae.1.cs
I also ascertained these facts, each of which made me more confused than the last:
Rebuild and Clean had no effect.
No controllers in the project ever returned a ViewResult using FishViewModel.
No views in the project defined that they use FishViewModel.
Searching across all files included in the project for “FishViewModel” provided no results.
The build server did not report a problem.
The Solution
The problem stemmed from a file that was not included in the project but still present on the file system:
(By the way, if you don’t know this trick already, there is a toolbar button in the Solution Explorer window to “Show All Files” which allows you to see files all files in the file system)
In my situation, I was working on the mission-critical Fish view before abandoning the feature. Instead of deleting the file, I excluded it from the project.
However, this was a bad move. It caused the build failure, and in order to fix the error, this file must be deleted.
By the way, this file was not in source control, so the build server did not have it. This explains why my build server did not report a problem for me.
The Explanation
So, what’s going on? This file isn’t even a part of the project, so why is it failing the build?
This is a behavior of the ASP.NET Dynamic Compilation. This is the same process that occurs when deploying a webpage; ASP.NET compiles the web application’s code. When this occurs on a production server, it has to do so without the .csproj file (which isn’t usually deployed, if you’ve taken your time to do a deployment cleanly). This process has merely the file system available to identify what to compile.
So, back in the world of developing the webpage in visual studio on my developer box, I run into the situation because the same process is occuring there. This is true even though I have more files on my machine than will actually get deployed.
I can’t help but think that this error could be attributed back to the real culprit file (Fish.cshtml, rather than the temporary files) with some work, but at least the error had enough information in it to narrow it down.
The Conclusion
I had previously been accustomed to the idea that for c# projects, the .csproj file always “defines” the build behavior. This investigation has taught me that I’ll need to shift my thinking a bit to remember that the file system has the final say when it comes to web applications, even on the developer’s machine!
