I am currently working on a project where I am using the NVelocity templating engine, which is a .NET port of the open source Apache Velocity project.  So I downloaded the package from SourceForge and dropped the NVelocity.dll file into my /bin folder thinking all would be well.  And it was locally, no problems at all.  It wasn’t until I went to deploy my Web Application Project that I started to run into issues.  It seemed that the .dll had some dependencies that were not documented ( at least not obviously! ) as I was getting the following on publish:

“Could not load file or assembly NVelocity.dll or one of its dependencies. The system cannot find the file specified.”

So I loaded up Dependency Walker to see what was going on and I noticed the following:

Error: Modules with different CPU types were found.

OK, so I am running a x64 system, that can be expected.  It also noted that IEShims.dll was missing, though that seemed to be a bit of a redherring.  After a while of wading through Dependecy Walker screens and wondering if I had just wasted the past half day of work it dawned on me that I hadn’t even checked NuGet.  And lucky enough NVelocity is available as a package there.

So I ran the NuGet package, it installed fine, and it deployed without any issues on the first try!

So the moral of the story is check NuGet first, there are tons of packages available and you might even find something new and interesting.

I have a fairly large form that I have been working on that I have wrapped up in a .NET UserControl.  I had to switch focus onto another project for a couple of weeks so it became a bit of a distant and not so pleasant memory!  When I came back to it and added a button control to test some UpdatePanel postback issues I got the following error:

‘btnTest does not exist in the current context’

Now I hadn’t worked nor thought about this particular project for over a week so I wasn’t really sure what was going on.  It was a run-time error, everything compiled fine.  I ended up spending a couple of (expletive filled!) hours going down dead ends and getting nowhere.  Something just didn’t feel right about this but I couldn’t see what it was until I noticed a ContactForm_copy.ascx file in the UserControls folder in Visual Studio.  How did that get there?!  It seems I had made a filesystem copy of the UserControl and somehow managed to include it in my project.  After deleting the copy of the file everything worked as normal, problem solved.

So the moral of the story is: Don’t leave backup copies of your project files in the same folder as the original.  It seems like a reasonable thing to do to keep a backup copy around while experimenting, and everything compiles fine since we are dealing with partial classes in code-behind.  But save yourself some trouble and move your backups to a designated folder and avoid the dreaded  ‘Object Does Not Exist’ error that we all know and (don’t)  love.