As part of correcting issues in an isolated lab environment, it is often necessary for developers to connect to one or more machines within the isolated network.  While the concepts of remote debugging are pretty straight forward, I decided to go ahead and put together something that our developers could use as a guide to perform those types of activities.  Our codebase is 100% managed code, for whatever reason, it is more difficult to get attached and debugging across domains with managed code than it is with Native code.  Honestly, I don't understand why that is, but it can be a bit frustrating unless you fully understand how to get such an environment configured properly.

The first thing you need to do is install the Visual Studio Remote Debugging tools (x86 or x64) on the target machine.  The install is pretty straight forward, so I won't go into that directly.  We actually include the remote debugging monitor (MSVCMON) as part of our base lab images.  In our case we don't configure the tool to run as a service, instead, we place a short cut on the desktop so that it can be started when needed.

Once of the key aspects of remote debugging is that you have to use the same user account on your developer machine, as well as the target machine.  This means Local Accounts on both machines.  So the first step is to create a local account on your desktop, lets call it "Remote.Debugging" for our purposes.  This account doesn't necessarily need to be in any special local groups.  Create the same user name and password on the target machine.  This time, however, you need to put the account in the target machines Administrators group (the local administrators group, not the domains).

Once you have the accounts created, you need to update the permissions in the Visual Studio 2010 Remote Debugger. Once opened, use Tools->Permissions and add the account as part of the security.  Below is a screen shot of what you should see when you do this.

Now you are ready to attach and debug, should the need arise. Notice that the user signed into the desktop is from the isolated domain called "LAB", and the user name is Lab.Administrator.

When you need to debug, simple hold the shift key down and right-click on the Visual Studio 2010 Remote Debugger Icon on the desktop, you will get a pop up menu that looks something like this:

Notice that there is a option for 'Run as Different User'.  Select that, and you are presented with a credentials pop up window as follows:

It is important that you enter the local machine name in the windows credential dialog (because the account is local to this machine. A little known shortcut is that you can use the "." as the machine name for local accounts.

 Once you have successfully authenticated, you will have a Monitor window like the one below.  Notice that the user name now indicates Remote.Debugging@LabDesktop01.

This means that you are now ready to connect from Visual Studio.  On your workstation, follow the same process, hold the shift key down and right-click on the visual studio shortcut, you will see a pop up menu like this

 As before, select Run as Different user.  When prompted enter the credentials of the local account 'Remote.Debugging'.  If this is the first time you are performing this procedure, you will be asked the various initial-setup questions, such as your default environment settings, etc.

Generally, I open the solution that has the executable that I am debugging so that I have access to all of the source code within the environment.  If you are opening a project that is corrected to TFS, you will get a pop up asking you for your TFS credentials.  This is normal because you are running as the local user you created. Once you have opened the solution, and are ready to attach, select Debug->Attach to Process.

Enter the machine name (you know the long with that starts with LAB_), or the IP Address and press enter.  Once attached, within visual studio, you will get to select the process.

 You can select the "Show processes from all users" checkbox to see the other processes.  Once you find your process select it and click Attach.  Notice that the "Attach to" field currently indicates Automatic: Native Code; If you have connected as outlined here, this will change when you select your process to whatever is suitable.  Over in the Lab, the Visual Studio Remote Debugging monitor shows this

 Notice that both screens show that you are attaching as the user created specifically for this purpose.

And now a brief word about security...  Since many organizations have multiple developers, I recommend that you disable the account you created on your developer workstation until you need it for debugging.  This helps prevent unauthorized access to your computer.

As you can probably tell by some of these posts, I have been working on automating some of the build-test tasks as it relates to deploying into a testing environment.  Today I found myself wondering how to fail a deployment workflow that has issues inside of a batch file.  As it turns out, this was quite easy...

Inside the batch file, when you detect a problem, you can execute a statement like the following:

exit /b 1

The /b tells the batch file processor that you do not want to exit the full command shell, but rather just termiante the batch file.  The number afterwards is the desired exit or errorlevel code.  A practical example of this functionality would be detecting whether or not the deletion of a file succeeded as follows:

del application.exe
if exist application.exe exit /b 1

The above would return from the batch file with the errorlevel set to 1

In our environment, we use a series of batch files to help automate the creation of a uniform environment when a developer or tester gets a branch of code from TFS.  It has always been annoying to have to open up visual studio to create the various virtual directories, and it is been on my list a long time to clean that up.  This weekend, I had a little down time and decided to investigate just how to do that (Besides this has been on my list for a very long time).

It is probably worth mentioning that the way our environment is configured, developers and testers can all have multiple branches of the code locally on their computers, and they can switch to a new branch just by opening the solution.  Each branch has several solutions that all work together to form the product we are developing.

As part of our internal tooling, I have written a series of utilities that include batch files when appropriate to easily prepare a branch to work as a specific client-environment.  These activities include things like configuring Web Application Directories and project reference paths within the project files, along with a variety of updates to various configuration files to point to the correct WCF Services, Databases, and Directories.

Here is the batch file that works the "magic" of detecting whether or not the Web Application already exists, and if not creates it.

@ECHO OFF
   REM --------------------------------------------------------------------------------
   REM Check for and create WEBAPP under Default Web Site
   REM
   REM %1 is the WEBAPP to create
   REM %2 is the Physical path to the VDIR 
   REM --------------------------------------------------------------------------------

   IF "%1"=="" GOTO BadCommandLine
   IF "%2"=="" GOTO BadCommandLine

   REM Detecting if Web Application Already Exists...
   %windir%\system32\inetsrv\AppCmd.exe list app "Default Web Site/%1" | find "%1" > nul
   IF NOT ERRORLEVEL 1 GOTO AlreadyExists

   ECHO Creating %3 Web Application...
   %windir%\system32\inetsrv\AppCmd.exe ADD app /site.name:"Default Web Site" /path:/%1 /physicalPath:%2 >nul
   GOTO End

:AlreadyExists
   ECHO Virtual Directory already exists.
   GOTO End

:BadCommandLine
   ECHO.
   ECHO Web Application Name and Physical Path Required
   ECHO.
   ECHO CreateVirtualDirectory VirtualDirName PhysicalPath
   ECHO.

:END

The above batch file is called like this.

SET WebAppVDIR="WebService"
SET BinDirectory="C:\Projects\Test\test\bin"

REM Create Web Application...
CALL CreateWebApplication %WebAppVDIR% %BinDirectory%

The resulting call will create a Web Application (Using the Default Application Pool) that points to the specified Bin Directory "C:\Projects\Test\test\bin".

Hopefully, this will be useful to someone else. If you have questions or other ideas about how to improve upon this, please leave me a comment.