A twenty year veteran of the software industry, Andrew brings considerable experience to electrongoo. From design, development, project management, and product usability; he delivers on all levels
A router is a woodworkers best friend. The PRL from Woodpeckers makes it the perfect friend! I’ve been using my PRL V1 for almost 15 years without issue. The PRL V1 is no longer for sale – the PRL V2 has taken its place. Recently, the handle crank became hard to turn. After some digging-around and unscrewing, it turns out this was caused by dust between the nylon gear and the faceplate. Here’s how I fixed the issue.
Place the PRL on a sturdy surface:
You will need some tools: 9/16″ wrench, 4.5mm Allen wrench, and some lubricant (I used 3-1 oil but WD-40 or similar will work fine):
Place the PRL on its side with access to the 9/16″ bolts which hold the router in place:
Remove the router from the PRL for easier access to the gears and chain:
Once the router is removed, flip the PRL on its face with access to remove the gears and loosen the chain. Locate the gear underneath the crank handle (it’s the one with large metal stop-system and two Allen nuts) :
Unscrew the two Allen nuts to remove the stop-system:
One the adjacent side of the PRL, remove the single Allen nut holding the metallic gear:
the chain should flow freely to create slack to access the gears:
Now loosen the chain from around the nylon gear located below the hand crank:
Turn and pull the nylon gear by hand until it comes free from the face plate:
Now comes the fix! Clean the base of the gear and the inside hole on the face plate. First with a dry cloth or paper towel to get ride of the larger debris. Finally spray the areas with oil/WD-40. No need to use very much as it will dry eventually; use just enough to slide the gear back into the faceplate.
Once it’s all clean, slip the nylon gear back in the faceplate, place the chain back on the nylon gear, place the chain back on the metal gear, and screw the Allen nut so the metal gear is secure and the chain flows around all four gears. Re-secure the metal stop-system to the top of the nylon gear with the two Allen nuts. Finally, re-mount the router into the Lift.
Give the crank a whirl! Hopefully it’s back to new and cranks easily.
I run windows 10 and once in a while my second video monitor will remain dark after coming out of a suspend mode (sometimes even just turning off the monitors and turning them back on!). I believe this is an issue with the NVidia video card I have installed since I can get the monitor to refresh by restarting the device (or rebooting the PC).
Here’s how I solve this issue …
1. On the Windows Desktop (or some other folder if you prefer) create a new file named ResetVideoAdaptor.bat. You can use Windows Notepad or any text editor to do this. Just make sure the file extension is named ‘.bat’ and not ‘.txt’
2. Add the following lines to your ResetVideoAdaptor.bat file (see additional steps ‘how to customize for your system’ below)
@echo off
REM see details on blog.electrongoo.com to set your specific adaptor id!
SET MY_VID_ADAPTOR_ID=*PCI\VEN_XXXX*YYYY*
"C:\Program Files (x86)\Windows Kits\10\Tools\x64\devcon" disable %MY_VID_ADAPTOR_ID%
"C:\Program Files (x86)\Windows Kits\10\Tools\x64\devcon" enable %MY_VID_ADAPTOR_ID%
3. To use this batch file, whenever one of your video monitors goes dark, run ResetVideoAdaptor.bat as Administrator (right-click on ResetVideoAdaptor.bat and select “Run as Administrator”) and the video adaptor will be reset and the video monitor will come back to life.
You must update the vendor id and device id in the ResetVideoAdaptor.bat file for your specific video card. You can find these values using Windows Device Manager. In the Windows Search bar type “Device Manager” and press Enter. You should see a window similar to this
Locate your video card under “display adaptors” and right-click and select Properties. From the Properties page select the Details tab and select “Hardware Ids” from the Property drop-down listbox. You should see something similar to this
Now jot-down the vendor id which will be the four digits after the “VIN_” tag (see example below) and the device id which will be the four digits after the “DEV_” tag (see example below).
Finally update your specific four digit vendor id and four digit device id in the ResetVideoAdapter.bat file. Search for “XXXX” and “YYYY” and replace those values with your specific id’s. As an example, for my video card I updated the line
SET MY_VID_ADAPTOR_ID=*PCI\VEN_XXXX*YYYY*
to
SET MY_VID_ADAPTOR_ID=*PCI\VEN_10DE*1187*
Save your final changes to ResetVideoAdapter.bat and your done.
I have a multi-user configuration setup on my Windows 10 PC at home. My entire family can log into their own Windows account and have their own desktop and storage space. This works nicely but I noticed that iTunes is not very friendly with this multi-user configuration – iTunes hangs after sync’ing with an iPhone/ipad and can’t be used again until after a system reboot. Here’s how I resolved this issue: I created a batch file which terminates iTunes and creates a “clean” state …
On the Desktop create a new file called ResetITunes.bat. You can use Windows Notepad or any text editor to do this.
Add the following to the ResetITunes.bat file
@echo off
taskkill /F /IM itunes.exe
taskkill /F /IM distnoted.exe
3. Now, whenever you close iTunes, simply run ResetITunes.bat as Administrator (right-click and select “Run as Administrator”) and iTunes will terminate and be ready for the next user to sync their iPhone or iPad.
When managing projects I use a few different off-the-shelf products. But, it always seems there is some task I need to do that can’t be done efficiently with these tools so I make sure to include MS Excel (Office 365) in my suite of project management utilities. VBA macros within Excel give me the power to complete any custom tasks I require.
I needed to copy a set of folders (an entire recursive tree) to a new location. VBA does not natively include this feature. I searched the web for solutions but it seemed all were either out-of-date (non functional) or simply incomplete (never worked!). So, I thought I’d share my solution built on the VBA scripting.filesystemobject. Hopefully it will help others. Here it is …
Public Sub TestCopyFiles()
' Call the recursive copy operation
CopyFiles "c:\temp\a", "c:\temp\b"
End Sub
Public Sub CopyFiles(ByVal strPath As String, ByVal strTarget As String, Optional ByVal basePath As String, Optional ByVal baseTarget As String)
If basePath = "" Then basePath = strPath
If baseTarget = "" Then baseTarget = strTarget
Set FSO = CreateObject("scripting.filesystemobject")
' First loop through files in this folder
For Each nextFile In FSO.getfolder(strPath).Files
fullTargetPath = strTarget + "\" + nextFile.Name
mkdir (strTarget)
' Copy one file
FileInFromFolder.Copy fullTargetPath
Next
' Next loop through folders in this folder
For Each nextFolder In FSO.getfolder(strPath).SubFolders
nextStrTarget = baseTarget + Right(nextFolder, Len(nextFolder) - Len(basePath))
mkdir (nextStrTarget)
CopyFiles nextFolder.Path, nextStrTarget, basePath, baseTarget
Next
End Sub
Private Sub mkdir(folder As String)
' Create a folder if it doesn't exist
Set FSO = CreateObject("scripting.filesystemobject")
On Error Resume Next
FSO.CreateFolder (folder)
On Error GoTo 0
End Sub
As a recent cross-over user of Subversion to Git, I occasionally need a refresher of some command-line git operations … and I find myself searching the web. So, I created this list in a single, easy to locate post. Here is a list of Git operations I find most useful. Listed in order of a typical workflow. Hence more interesting (and more easily forgotten) operations are listed at the end.
Both Hyper-V and Virtual Box are excellent virtualization tools. Unfortunately, they compete for the BIOS virtualization feature. I’ve been using the HoloLens emulator recently which requires Hyper-V.
I created some simple batch files to easily enable/disable Hyper-V as I move to/from the HoloLens emulator. Create two new files (add the contents specified below) , right-click and run as Administrator, a reboot is required.
hyperv-enable.bat
@echo off
echo "NOTE: you must run this script at administrator level"
bcdedit /set hypervisorlaunchtype auto
echo "press enter to reboot ..."
pause
shutdown /r
hyperv-disable.bat
@echo off
echo "NOTE: you must run this script at administrator level"
bcdedit /set hypervisorlaunchtype off
echo "press enter to reboot ..."
pause
shutdown /r
to switch hyper-V on/off simply right-click on the bat file and select ‘run as administrator’ … after a reboot, the hyper-V service will be updated.
Creating new C# scripts in Unity3D is a simple process with a click of a mouse; although I find myself updating the default behavior script to match my coding preferences each time I create a new script.
Here’s how I update the default script to simplify my development process.
Browse to the Unity3D installation folder (typically named “C:\Program Files (x86)\Unity\”) and locate the sub-folder “Editor/Data/Resources/ScriptTemplates”
Here you will see the template files used to create new scripts. On my system I have five templates: javascript, C#, Boo, shader, and computer shader. I am interested in the C# template.
Open the file named “81-C# Script-NewBehaviourScript.cs.txt”
Update the layout file
Save the file
Now, when I create a new C# script in Unity3D it uses my preferred coding style layout.
Note: if you re-install Unity3D then you will need to update the layout file again.
Unity3d is an excellent cross-platform tool for developing interactive content. Unfortunately some desirable work-flow features are just not available. One such feature is the ability to change the default Project Location where all new Unity projects are saved. With Unity, I find myself creating new projects quite often to test new features and ideas. Being able to set a custom default Project Location would be a great time-saver so I would not have to drill-down into a file dialog to locate a specific folder.
While searching for a solution I found many otherslooking for the same feature. Unfortunately, no solutions were available. I found one mention of a registry key which could be altered but that did not work. I used the Microsoft Process Monitor to view registry and file access by the Unity process but I never saw any interesting data being read.
After some quick tests I found that Unity always uses the personal documents folder. The personal documents folder is located by Unity using the Microsoft SHGetFolderPath API. By default, Unity saves new projects under a folder named “New Unity Project (X)” under your personal documents folder. So, the task is to get Unity to read a different value for the personal documents folder.
The following details how to update Unity running on Windows. These steps are not valid for Unity running OSX or Linux.
Instructions:
In order to get Unity to display a custom Project Location folder when you select File | New Project … you must update a value in the Windows registry. To accomplish this, create a simple Visual Basic script to update the personal folder name, launch Unity, then revert the personal folder name when Unity is closed. Here are the step-by-step instructions …
Create a new empty document (e.g. within Windows Explorer Right-click New | Text Document)
rename the file LaunchUnity.vbs
Open the Windows registry (e.g. regedit.exe) and browse to the key named HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. Find the value named Personal. This is the value returned by the Microsoft SHGetFolderPath API. It should be of the form C:\Users\<yourname>\Documents.
Make a note of this value. You will use it later to update your Visual Basic script.
Now, right-click on your Unity3d icon and select Properties. Select the Shortcut tab and locate the Target textbox which contains the path to Unity3d on your system. It should be of the form “C:\Program Files (x86)\Unity\Editor\Unity.exe” but can vary based on where you installed Unity and if you are running 32-bit or 64-bit Windows.
Make a note of this value. You will use it later to update your Visual Basic script.
Now create the Visual Basic script to update the folder name and launch Unity. Right-click on the “LaunchUnity.vbs” file you created and select Edit.
Copy and paste the following Visual Basic script code into the LaunchUnity.vbs file
Replace the three strings “C:\YOUR\PROJECT\FOLDER”, “c:\Program Files (x86)\Unity\Editor\Unity.exe”, and “C:\YOUR\PERSONAL\FOLDER” with the default path you want to save Unity projects, the path to unity.exe, and your existing personal folder respectively. Warning: make sure you do not use a trialing \ on the paths or that will break the vbs script.
For example, here is my final vbs script using “G:\UnityProjects” as my custom project location and “C:\Users\andrew\Documents” as my existing personal folder.
When you want to use the new custom project location, simply launch Unity via the new LaunchUnity.vbs script you just created.
Verify the custom project location
Launch Unity via the LaunchUnity.vbs script you just created. Unity should launch as usual. If it does not then go back and verify you followed all steps correctly.
From Unity, select File | New Project … and you should see your new custom project location. Easy!
While Unity is running, you can view the Personal key in Windows regedit.exe. Press F5 in regedit to refresh the view. You will notice that it is set to you custom folder name.
When you close Unity, the Personal key will automatically revert back to its previous value.
Wrap up:
So, when ever you want to create a new project in Unity, simply open Unity with the LaunchUnity.vbs script. As a benefit, once the new project is created, Unity will automatically close itself and re-open so the Personal folder will be reverted back to normal after your new project is open!
Pros:
Simplify new project creation in Unity3d
Guarantee all new projects are placed within your developer storage
Easy one-click launch of Unity3d configures the project location folder and terminating Unity3d automatically reverts your personal folder to its default value
Since Unity automatically closes and re-opens after creating a new project the Personal folder will be reverted automatically after creating a new project
Cons:
All programs requesting the Personal folder via the Microsoft SHGetFolderPath API while Unity3d is running will get the custom folder you defined for Unity3d. You can shut-down Unity to automatically revert the original folder name
The amazing global economy opens many doors to your software product. Localizing your software in different languages will improve its success. While many people whose primary language is not English can probably trudge their way through your non-localized English software, a localized version of your software will always be a benefit; both to your customers and your product viability.
The task of localizing software varies based on the platform (iOS, Android, Windows desktop, Linux, etc) as well as the language being used (Java, C#, C++, Objective C, etc). Many old-school software engineers might recall a time when localization was designed and coded in-house; typically once, and then that software code was re-used on other projects. Regardless, the process was typically tedious and prone to bugs and glitches. Fortunately, today, the major development platforms offer simple localization features built-into their developer stack. This post will discuss localization of Windows applications using C#. View this other post regarding localization in Java on Android.
The task:
Okay, so you just created a cool Windows application in C# and now you’ve been tasked with localizing it into fourteen different languages. After staring at your non-localized application project in Visual Studio and searching the Internet you probably have some confusion about how difficult localizing your project actually is. I’ve seen many people obfuscate the simplicity of the task. There are various methods, but if you follow some simple rules, the process can be very painless. Adding new languages to a localization-ready project at any time in the project cycle is a simple process too!
Step by step:
Open your project in Visual Studio. From the solution Explorer right-click on you project name and select Add | New Folder and name the folder Resources
Create resource folder in Visual Studio
From the Installed Templates section, select Visual C# Items and then select Resource Files. This first resource file will contain your default native English resources strings. Name the file generically resources.resx to simplify the process.
Select Resource Dll to add to project
A new resource file will be created and will be displayed in Visual Studio ready for you to add the resource strings.
New native English resource file created
Enter each of the strings used in your project in the resx file. In the Name column enter a unique name that you can reference the string from within your code. I recommend prefixing each of your string names with str_ to make your source code easier to read. Enter the string as it will appear to the user in your software under the Value column. You will do this for each string in your project. Don’t worry if you don’t enter all of the strings at this time, you can always return and enter more strings. The key to success here is to ensure that your first resource file is complete, and contains ALL strings, before you begin to create additional resource files. You can add new strings at any time but make sure you add each new string to ALL resx files you create.
Native English resources added to resx file
From the Solution Explorer, open one of your dialog files. Note, you will obviously have multiple dialog files for a single project; you will need to process each file. In the Design layout window make sure the dialog is selected then go to the Properties page and select the Events button (this will appear as a lightning bolt).
Add the Load() event handler to each dialog resource
Scroll down to the “Load” event and double-click. The wizard will automatically create a new Load function, if it does not exist, which will be called by the Windows framework when the dialog is loaded but before it is displayed to the user. This is the preferred Windows event to handle updating resources in dialog boxes.
Event handler automatically added
Now, within the Load() event handler, set the Text field for each of the controls within your dialog to a string you created in the resource file. You will use the Resources.Resource class to resolve each string
Now, simply repeat the steps above for each dialog in your project. If you do this during initial development of your project it makes the task much easier. At this point, you have a fully ready to localize project.
Now that you have all your dialogs using resources files and you have a base native English resource file, you can start creating new resources files; one for each language you want your project to support. The steps are similar to creating the base English resource file above. Right-click on the Resources folder and select Add | New Item then select Resources File and name the file based on the language being added. You must use the filename convention resources.XX.resx where XX is the two-letter language identifier. Doing so will greatly simply the localization process. For example, to create a German resource file create the file named Resource.de.resx and to create a French resource file create the file named Resource.fr.resx.
Create a new resource file for localized text
Now you have a new resource file to contain the strings for a new language. Now return to the base native English Resource.resx file and click on the box in the upper-left corner (or press Control-A) to select all of the strings and press Control-C to copy the strings to the Windows clipboard. Return to the newly created Resouce.de.resx file and press Control-V to paste the strings from the Windows clipboard into the new resx file.
Copy existing English resource strings into the new resource file
It’s that simple! Now, you have a localization-ready project which supports two languages. You can easily add new languages by creating new resources files under the Resources folder at any time. The key is to use the naming convention Resource.XX.resx as discussed above.
When you build your project, the resource files will automatically be created under subfolders named XX, where XX is the language code of the Resource.XX.resx file you created.
Language folders automatically created during Visual Studio build
Each subfolder will contain the resource strings for the specific language
Language dll located in its language folder
Finally, provide the Resource.XX.resx files you created to your localization provider such as inwhatlanguage.com for localization. When the resx files are returned to you, simply drop them into your project overwriting the previous temporary English versions and rebuild your project.
Make sure your project installer creates an identical folder structure under the folder containing your executable (this folder structure should look identical to the folder created by Visual Studio after a build). When you project starts it will automatically search that folder structure for a supporting language id. If the resource dll for that language exists then the resource file will be loaded. If it does not exist then the default native English resource file will be used.
Debugging:
Debugging new localization files is simple. Simply add the following lines of temporary code to the primary Load() event handler in your project
using System.Globalization;
private void Form_Login_Load(object sender, EventArgs e)
{
Thread.CurrentThread.CurrentCulture = new CultureInfo("de-DE"); //e.g. de-DE zh-CN ja-JP
Set the CultureInfo string specified in the constructor to the language-region code you wish to test. For example, to test German in Germany use “de-DE” and for Chinese in Hong Kong use “zh-HK.” A full list of language and region codes can be found here. Rebuild and run your project and the strings from the specified locality will be displayed automatically.
Tips:
Even if you don’t have current plans to support localization, always build new projects targeted for localization by moving your text strings into a resource file and use the Resources.resource class to update all your user visible components
Always name resource files with the format Resource.XX.resx (where XX is the two-letter language id) to simplify the build process
Make sure your first native English resource file contains all of the strings before creating localized resource files. Adding new (or forgotten) strings to each localized resource file can be a painful repetitious task prone to errors
In a perfect software development environment, an engineer can design, develop, and debug on a single system. Conveniently, building and debugging a project can be accomplished a single key stroke: for example, pressing F5 in Microsoft’s Visual Studio. Unfortunately, many projects do not allow for local debugging. Some examples of this:
Resolving bugs which only occur on specific systems
Developing for a project which only runs on an operating system which is not a beneficial development system (e.g. Windows Home Server or simply an older version of Microsoft Windows such as Windows Vista or Windows XP)
While most software projects allow for simplified build and debug options via a software test-harness project or limited project build. There are typically times when remote debugging is required. Fortunately, Visual Studio offers a very robust remote debugger feature.
Requirements:
Microsoft Visual Studio 2013, 2010, 2008, or 2005 (VS Express not supported)
Remote Tools for Visual Studio
A host (development) PC running Windows and Visual Studio
A target (debug) PC running Windows
Your software project, symbol files, and source code
One-time setup of host system:
Setting up the host system is fairly easy. Simply install Visual Studio, which should already be installed if you’re using your existing development system then configure the firewall to allow network communication between the host and the remote systems. Here are the three typical firewall options you have:
If you do not have a firewall installed then there is nothing to do.
If you are running a third-party firewall such as Norton Internet Security then simply disable the firewall temporarily during remote debugging. This is my personal preference since I rarely remote debug and I prefer not to permanently open ports in my firewall. I accomplish this by right-clicking on Norton Internet Security located in the tray icon and select Disable Smart Firewall and then select “15 minutes.” This usually provides me enough time to debug and it also automatically re-enables the firewall in case I forget. You can always disable the firewall for extended times if debugging is taking longer than expected
If you’re running Windows built-in firewall then type “firewall” in Windows search to locate and run “Windows Firewall with advanced security” then create the following rules
Windows firewall utility
Allow Visual Studio application: Inbound Rules (on left side) | New Rule (on right-side) | Program | This program path | locate the path to your Visual Studio dev e.g. %VSInstallDirectory%\Common7\IDE\devenv.exe | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
Allow DCOM services on port 135: Inbound Rules (on left side) | New Rule (on right-side) | Port | TCP | Specific Local Ports = 135 | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
Allow IPSec services on ports 500 and 4500: Inbound Rules (on left side) | New Rule (on right-side)| Port | UDP | Specific Local Ports = 500,4500 | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
See the “One-time setup of remote system” below for example screen-shots of the firewall wizard. Now your host system is all configured. Now it’s time to configure the remote system.
One-time setup of remote system:
The initial setting up the remote system involves opening ports in your firewall for communication and providing privileges to the Remote Debugging Monitor utility.
First, locate the Remote Debugging Monitor utility. This is included with the Visual Studio install set. Two versions of the utility are included, one for debugging on 32-bit applications (x86) and a second for debugging 64-bit applications (x64). The utilities are found on the installation drive under the Visual Studio install folder (for example, Visual Studio 2010 can be found here %SystemDrive%\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger). If you do not have this folder in your Visual Studio install-set then you can re-install Visual Studio and select “All Components.”
The two versions of the Remote Debugging Monitor will be located in their x86 folder (for 32-bit) and x64 folder (for 64-bit). For example, for Visual Studio 2010:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86
Which version of the utilities do you need? You’ll need to install the version which matches the “bit-ness” of the application you are debugging. Examples:
Debugging a 32-bit application on a 64-bit target system: use x86
Debugging a 32-bit application on a 32-bit target system: use x86
Debugging a 64-bit application on a 64-bit target system: use x64
Copy the entire utilities folder (either “x86” or “x64”) from the Visual Studio folder to a folder of your choice on your remote debugging system. I prefer to copy the folder directly to the Desktop and then rename the folder to identify the version of Visual Studio the tools came from as well as the “bit-ness” (for example x86_vs2010, x64_vs2013, x86_2005, etc).
desktop shortcuts
Configuring the firewall is very simple by letting the Microsoft msvsmon.exe utility configure itself on first-run. To do so, launch msvsmon.exe on the remote debugging system. You will be prompted, “do you want to automatically configure the firewall?” Select Yes, and all the ports and privileges will be configured for you. If you find this is not working or you want to configure the firewall manually then follow the following steps (otherwise continue to the next section, “Configuring a debug session”). Here are two common options to configure the firewall on the remote system:
If you do not have a firewall installed then there is nothing to do.
If you’re running Windows built-in firewall then type “firewall” in Windows search to locate and run “Windows Firewall with advanced security” then create the following rules
Windows firewall utility wizard
Allow Remote Debugging Monitor application: Inbound Rules (on left side) | New Rule (on right-side) | Program | This program path | locate the path to the Remote Debugger Monitor e.g. msvsmon.exe | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
Allow DCOM/NETBIOS/SMB services on port 135, 139, 445: Inbound Rules (on left side) | New Rule (on right-side) | Port | TCP | Specific Local Ports = 135,139,445 | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
Allow NETBOIS services on ports 137 and 138: Inbound Rules (on left side) | New Rule (on right-side)| Port | UDP | Specific Local Ports = 137,138 | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
Allow IPSec services on ports 500 and 4500: Inbound Rules (on left side) | New Rule (on right-side)| Port | UDP | Specific Local Ports = 500,4500 | Allow the Connection | Domain=checked, Private=checked, Public=checked | provide any rule name you wish
Now your remote debugging system is all configured. It’s time to setup a debug session.
Configuring a debug session:
Now that the one-time configuration of the host system running Visual Studio and the remote debugging system running the Remote Debugging Monitor is complete, you can setup a debugging session quickly and easily.
The general steps for starting a new debug session are:
Build your project via Visual Studio (this ensures the latest code, symbols, and executable files are all in-sync and available)
Copy the executable files and symbol files to the remote system
Register/install all executable files necessary to your project on the remote system
Launch the Remote Debugging Monitor utility on the remote system
Launch your application on the remote system
Attach the Visual Studio debugger on your host system to your running application on the remote system
You will repeat these six steps every time you create a new debug session. I recommend automating steps 2 – 5 via a batch file or Power Shell script. Not only will automation make the setup process quick, it will also make it less error-prone. As an additional side-benefit you can use the script as a source of documentation; making it easy to recall what files must be installed, registered, and started before a debug session for your specific project.
Each script you create will be unique to each project. Scripts will have commonality since they tend to accomplish the same actions (stopping services, copying files, registering services, starting the remote debugger, etc). Here is an example of a script I use after building my project with Visual Studio. It takes care of all the heavy lifting; making sure my project is configured on the target debug system.
echo on
REM *** stop my service if it’s currently running
net stop "Jojo Manager Service"
REM *** unregister the service with Windows
"C:\Program Files\Jojo\jojoserve.exe" /UnRegServer
REM *** copy all project files from host development system
REM *** to the local debug system. Including debug PDB symbol files
copy /Y "\\MyShare\Code\Projects\Jojo\jojoserve\Debug\jojoserve.exe" "C:\Program Files\Jojo\"
copy /Y "\\MyShare\Code\Projects\Jojo\jojoserve\Debug\jojoserve.pdb" "C:\Program Files\Jojo\"
copy /Y "\\MyShare\Code\Projects\Jojo\UI\WHSAddIn\bin\Debug\HomeServerConsoleTab.Jojo.dll" "C:\Program Files\Windows Home Server\"
copy /Y "\\MyShare\Code\Projects\Jojo\UI\WHSAddIn\bin\Debug\HomeServerConsoleTab.jojo.pdb" "C:\Program Files\Windows Home Server\"
copy /Y "\\MyShare\Code\Projects\Jojo\UI\WHSAddIn\obj\Debug\Interop.jojoserveLib.dll" "C:\Program Files\Windows Home Server\"
REM *** register the new debug version of the service
"C:\Program Files\Jojo\jojoserve.exe" /Service
echo off
pause
An example debug session:
Now that you understand the general configuration and flow of Remote Debugging and how to connect the host and target systems, let’s run-through an example of the remote debugging process.
Build your project using Visual Studio
I recommend performing a full rebuild before a debug session. This will ensure you are running the latest code as well as getting the latest symbol and executable files.
Run your automated batch file to copy and register project files
Copy your project executable (.exe and .dll) and symbol (.pdb) files to the remote debugging system. Ensure they are all re-registered with the operating system if necessary (e.g. COM objects, Windows services). See above to view a sample batch file to assist with copying and registering files. Note, if you are debugging a native executable then you do not need to copy the .pdb symbol files to the remote system; native symbol files are only required on the local host system.
Launch the Remote Debugging Monitor utility on the remote system
Locate the Microsoft Debugging utility named msvsmon.exe which you copied to the remote debugging system during the one-time setup. Double click to launch the Remote Debugging Monitor.
Remote Debug Utility waiting for connection
The remote system is now waiting for a connection from your host system running the Visual Studio debugger.
Launch your application on the remote system
Launch your project executable on the remote system and return to your host system to establish the debug connection.
Attach the Visual Studio debugger on your host system to your running application on the remote system
Return to the host system and open Visual Studio. From the main menu bar select Debug | Attach To Process…
Attach host to remote process
Select the following options to connect the Visual Studio debugger to the remote host:
Transport: set this value to “Default.”
Qualifier: this value specifies the name of the target debug system. Its full form is DOMAIN\USER_NAME@PC_NAME. If your local network uses a Domain then you must use the full syntax. If your local network does not use a domain then you can specify the name of the target PC (you can locate the PC name in the Remote Debugging Utility output window or via Computer | Properties | Computer Name). The user name is the name of the user logged into the remote system. You can find this name in the Remote Debugging Utility output window.
Remote debugging system connected to host
Attach To: press the Select button to specify the type of executable you are attaching to. For example, native, managed .NET 2x, or managed .NET 4x
Select the type of executable you are attaching to
Locate the name of the process you want to attach to. The Available Processes list-box will display all of the processes running on the target system specified in the Qualifier field
Select the process you have setup to debug on the remote system and press Attach. Visual Studio will then attach to the remote system and give you the ability to debug exactly like you would debug a local process. Very powerful!
Remote debugging system connected to host
As you can see, Microsoft Visual Studio offers a very powerful debugger allowing you to debug across multiple systems. Your first choice of debugging platforms will always be local but if that cannot be accomplished then rest assured, with a little bit of setup, you have access to the same debugging features across a remote system.
Tips:
Keep a copy of the Remote Debug Tools on a local server share for easy access. If you develop for multiple systems then you’ll need to access various versions (x86, x64, ARM) of the tools. Easy access and setup are key to a happy day
Use batch files or power-shell scripts to copy required files (exe, dll, symbols, etc) to the target PC and initialize your project requirements. If you create these scripts during your first debug session then you can use them as reference documentation in the future to easily recall which files are required to setup a debug session. Automating your development processes always make you more successful and less error prone
Each version of Visual Studio includes its own version of the Remote Debugging Utilities so if you develop products with multiple versions of Visual Studio then keep multiple copies of the utilizes stored on an easily accessible network share
Create an Administrator account on the target debugger machine with the same username and password that you use on your host development system. When remote debugging, log in with those credentials on the remote system. This makes the process of connecting your host and target much easier since you have the same account privileges on both systems
Save hard drive space on the remote debugging system when debugging a native application. Symbol files (.pdb) for native applications only have to exist on the host system while symbol files for managed applications (such as C#) must exist on the remote debugging system in the same folder as the application. Don’t copy large .pdb files to the remote debugging system for your native components
If you cannot create any break-points within Visual Studio after you have connected to your remote process then terminate the debug session (Debug | Terminate Process) then rebuild your project, copy all project and symbol files from your build to the remote system and reconnect the debugger. When attaching to the remote process, verify that you have the correct executable type (e.g. native, managed .NET 2x, managed .NET 4x, etc) set in the “Attach To” within in the Attach To Process box
