|
|
|
  
 |
 |
Back Draft
But It Works On My Machine!
In a perfect world, you would develop and test your code on a local PC, then deploy it to a staging server for integration testing, followed by deployment to production. Along that path, everything would function and behave the same on the staging server and production server as it does in your development environment. You’re probably chuckling right now, because this ideal is not always the reality. There are gremlins at work, whose sole purpose is to make your life miserable. I’m sure you’ve either heard or said the stereotypical developer mantra, “but it works on my machine,” several times in the past.
There are myriad potential reasons why your code works in one environment and not another. For instance, in the world of ASP.NET development, your staging and production environments are typically running server operating systems, while development usually happens on Windows XP Professional. The way that IIS operates and the features available are different between the two, so that could be the reason.
The problem could also be a permissions issue. All too often, we as developers write code while logged in to our PCs as members of the Administrator’s role. Administrator powers are rarely granted (nor recommended) in production environments, so when those powers are taken away at deployment, issues can crop up. That is why you should learn to live the least privilege lifestyle. Keith Brown wrote a fantastic article entitled “How To Develop Code As A Non Admin” that will get you started in that direction (http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToDevelopCodeAsANonAdmin.html).
Of course, the reason your software doesn’t work correctly once deployed may have nothing to do with permissions — or any other configuration differences between the two environments. Sometimes the problem is rooted in the data that you are consuming in one environment versus another. Perhaps the data in staging or production roots out logic deficiencies in your code that weren’t present in your test environment data. I typically recommend to my clients that their test database contain data that is highly representative of the production environment. That means occasionally backwashing production data into development to keep test scenarios realistic and current. That may not always be possible or convenient, though. I also don’t recommend hitting the production database from your development PC — you’re really asking for trouble.
For the occasions where you absolutely must get insights about the way your code is running on a non-development PC, Visual Studio 2005 offers the Remote Debugging feature. Now, I know what you’re thinking. Remote Debugging in Visual Studio 2003 was a total disaster. It was cryptic to set up and permissions issues abounded. Getting it to work was a black art and was often more trouble than other (less savvy) trial-and-error methods of troubleshooting issues. Luckily, the setup process has been greatly simplified in Visual Studio 2005 (http://msdn2.microsoft.com/en-us/library/y7f5zaaa(VS.80).aspx). There is just a single installation package per processor type (e.g., x86, x64 or IA64) that is located on the Visual Studio 2005 CD/DVD in the \Remote Debugger folder. Once you install that, you have a nice GUI to run and manage your debug processes on the server. The name of the debugger application is msvsmon.exe; it is located in the [Install Path]\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\[Processor Type]\ folder.
There are a few things you need to consider, such as debugging across domains, but the link above contains easy to follow instructions for setting that up, as well. Essentially, it boils down to making sure that you have the same user id and password on both the local and remote machine, as well as some ports open for DCOM communication. To debug ASP.NET applications that are running under another account name (e.g., SYSTEM, ASPNET, or Network Service), you’ll need to be an administrator on the remote machine.
Attaching to a remote process in Visual Studio 2005 is very similar to how it was in Visual Studio 2003 (e.g., using the Attach to Process dialog), except that now it actually works. For ASP.NET applications, you can actually just run the application if you are connected to a remote IIS project. Lastly, I wouldn’t recommend debugging your production environment during normal business hours, as it requires you to put the application in debug mode in the web.config file, which restricts you to a single thread of execution. Because your staging and production environments should be identical, though, you should rarely (if ever) have to debug your production environment.
We will likely never reach a point where all our code works all the time after it is deployed, but that is one reason why the staging server environment exists. By leveraging a staging server environment that mirrors your production environment, as well as developing code using least privilege, you can prevent many deployment bugs from occurring in the first place. When you do hit those hard to solve issues, though, it is great to know that Microsoft finally has a usable Remote Debugging story.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:jon@aspsoft.com or through his angryCoder eZine at http://www.angryCoder.com.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||
