Pay attention to tiny annoying little files that don't exist.

I'm not sure if this will help anyone or not.  However, it's an interesting story so I thought I'd share. 
I've been working on project XYZ.com (named changed to protect the innocent) trying to stablize it for the owners because the morons who built it were ... well... morons.  (You can only work a project so long before you come to these type conclusions.  I am probably being a bit harsh.)  In any event, there is a couple parts of the application that makes heavy use of the session to manage dynamic search results. (remember that I'm coming back to it.)  This application current supports three out of the four major browsers (at least by my standards) IE, FF, and Safari and one browser (Chrome) had been turned off almost a year ago because it was "acting too flaky" and "not rendering images or pages properly" according to the owners.  As I've come to find out, actually all of the browsers behave a little flaky now and then but not as bad a Chrome which in some features of the app just refused to work.

So today I was trying to address another major flaw in the site.  The whole site is HTTPS (for no good reason except that Firefox "seemed to have issues with images in http") so I'm trying to at least make it somewhat intelligent on which protocol is used when.  Turns out this was no small feat with these monster size controllers that do everything.  (Did I mention this was a .Net MVC 1.0 application?)

So I decided that I should turn on Chrome to do some testing and I immediately got frustrated with the crapy results.  In fact, I was about to give up totally and disable it again when a bit of blind luck happened.  I was using the Visual Studio Debugger and  I had Fiddler open (as I often do now)  I actually noticed that Chrome was being freaky agressive about asking for the favicon.ico file.  I mean like freaky, every 3 or four requests it would ask again (like if that file is not there the first time it's going to somehow magically appear seconds later, and who really cares anyway?) and on top of it it was doing that (as it should) in a separate request.  The only problem was,  the file does not exist on this site. It never has. So the MVC framework (I think) or who the hell knows what because I haven't dug any deeper yet, was doing a redirect to "Index" which Chrome followed the redirect (on the file which is technically only suppose to be in one location) which caused app to serve up the home page.  This is where things started to get ugly.  This caused caused the  session data (did you remember?  it used heavily in a couple key places) to be wiped totally clean.  So when you try to create that user account or store your search results they vanish before your eyes!  Bingo!  Flaky results at random intervals!

Moral of the story... You must pay attention to tiny annoying little files that don't exist.

I love Fiddler... I love the debugger ...  the end.

Capistrano deploy from Windows failing in transfer.rb

I recently ran into an issue with deploying from Windows using Capistrano.  The project I was using had been setup as a multi-staged deployment with Capistrano and had been working quite nicely deploying to my staging and production environments.  Unfortunately, the project sat for a few months and collected some dust while I was busy earning a living.  When I finally got around to working on it again I discovered that capistrano was now failing on the deploy command.  The error I was getting looked liked this:

capistrano/transfer.rb:156

C:/Ruby1.8.7/lib/ruby/gems/1.8/gems/capistrano-2.5.19/lib/capistrano/transfer.rb:156:in `[]=': undefined method `[]=' fo
r nil:NilClass (NoMethodError)
        from C:/Ruby1.8.7/lib/ruby/gems/1.8/gems/capistrano-2.5.19/lib/capistrano/transfer.rb:207:in `handle_error'
        from C:/Ruby1.8.7/lib/ruby/gems/1.8/gems/capistrano-2.5.19/lib/capistrano/transfer.rb:48:in `process!'
        from C:/Ruby1.8.7/lib/ruby/gems/1.8/gems/capistrano-2.5.19/lib/capistrano/transfer.rb:43:in `loop'
 
Although not completely obvious, the clue to the failure is in the location of the failure.  Failed in capistrano in transfer.rb and it's failing there because tar didn't execute and therefore didn't create the archive file to transfer to the server.


I truly love that when capistrano runs it identifies each command it's going to execute so you can see what it's trying to do.  I'm sure it would have been a much longer trouble shooting session if I had to dig through source to figure that out instead of it just telling me.  When I received that error, knowing that it was working fine a few months ago, it was obvious to me that I had made some changes to my environment that introduced the problem.  As it turns out, I was missing unix utilities in my PATH and in particular I was missing tar.  Once I added a path to my Cygwin/bin folder to my PATH everything started working again. 

Hope this helps someone avoid a few minutes of trouble shooting.

Upgrade Windows 2008 Standard to 2008 Enterprise

I've recently needed to upgrade Windows Server 2008 Standard Edition to Server 2008 Enterprise Edition to take advantage of additional memory on the server. I'm running the 32 bit version OS not the 64 bit. The 32 bit of Windows 2008 Standard only supports up to 4 GB of memory but the Enterprise Edition will handle up to 64 GB. (memory limits MSDN)  All the documentation I could find (blog posts, MSDN, TechEd, etc) suggested that the upgrade could be done in place but that there were some considerations depending on certain roles the server plays.  Fortunately my server didn't fall into any of those special circumstances.  However, when I ran the install and selected Enterprise Edition I received the message:

"Upgrade has been disabled.
The upgrade can not be started.  To upgrade, cancel the installation and then choose to upgrade to a version of Windows that is more recent than the version you are currently running."

and the button I would use to perform the upgrade in place was disabled.  Naturally I was a bit confused since my current installation was Windows 2008 Standard Edition SP2 and I'm trying to upgrade from Enterprise Edition 2008 SP2.

After a bit more digging on Google I found this blog post (Thanks Network Steve) that suggested that maybe SP2 was the issue causing the button to be disabled. So, not feeling very good about this approach, but with no other real options, I decided to go for it.  After making all the necessary backups I uninstalled the service pack. Yes, the OS still booted and seemed to work and fortunately for me this actually solved the issue with the installer.  I was able to do the upgrade in place from Standard to Enterprise Edition.

Hope this helps someone else!