Why I needed this

• Save time when deploying – in the past when I would post my little hobby projects to the web I would sometimes get errors and spend hours trying to figure out why.
• Improve my skill set in the full system – building web pages and code files is all fine and dandy in a development environment but if you don’t understand the full system then finding problems in a production environment can take much longer.
• Had a problem when deploying locally – My project was working on my local IIS but when deployed to a real server 2003 running IIS6 it only showed a yellow screen of death.
• Local IIS and dev web server close but not the same – while visual studio provides a built-in development server and vista includes a local IIS this are still limited and do not exactly function like a real production system. In short these mock servers are good for rapid development but your code still needs to be tested in a production environment

How my environment is setup

• Recently I upgraded – My home computer is now a Quad-Core, 4gb Ram, Vista Ultimate x64, which I have been pleasantly satisfied with. This was a huge step up from my 7 year old 2ghz Pentium 4, 512mb, XP pro system…huge difference.
• Vmware workstation – I have been playing with virtual machines for the last 8 months but since I got my new system it has gone into overdrive. This allows me to setup all different types of environments in a virtual setup.
• Microsoft Dreamspark – through this program I was able to get free copies of Windows Server 2003, Visual Studio 2008 and Vista Business. Thank you!
• Modify hosts file – this is a tiny text file hidden in all windows systems that is looked at first before any other DNS information. With this I am able to point internet domain names to my local server to mock a real environment.

How I applied this

• Referenced MSDN article – I had heard of remote debugging but was not aware how it really worked. This document got me pointed in the right direction.
• Installed service on the server – I used remote desktop to login to my server and installed the service that allows remote debugging. This was found with the install files that came with Visual Studio 2008. After installing I just had to start the service
• Attached to process from inside of VS2008 – While Visual Studio is running on my development machine I opened a file system website that was located in my network on a Windows Server 2003 machine. In order to debug on a remote machine the source code needed to be located on my local machine and I needed to attach to the w3wp.exe process on the remote server. At this point I had to hit pause on the debugger to break all threads and then hit continue. At this point I was able to set break points anywhere in my code. With this I would go back to my internet browser and hit the page on the website that would hit the break point, which further allowed me to step through the code as it ran on the remote server. Caution if this is a real production server that others have access to it will halt all website operation!

What I learned

• This is a powerful tool – the ability to hook directly into a production server and step through the code is very powerful, sometimes there are unknown environment variables that only come into play when you are in a production environment
• Don’t forget the basics – The instructions for deployment of this open source project stated that the asp.net process needed to have write access to a directory – duh! So in reality I didn’t need to step through my source code just to view the error that stated the write of a log file failed because the asp.net process did not have permission to write to a directory.
• I know have a new tool in my arsenal – I have another tool in my bag of tricks to troubleshoot problems. And it turns out the environment I setup at home is extremely close to the development server at work…a virtualized Windows Server 2003. So I could do this same thing at work if needed.