Setting up Silverlight 2 remote debugging on Mac OS X

Let’s face it: Silverlight is awesome! So are the Visual Studio Tools for Silverlight. One reason why it is so awesome is that you can run your applications on Windows and Mac OS X. But what if you need to debug an application while it is running on a Macintosh? Since there are no development tools for the Mac we have to resort to remote debugging which will allow us to debug the application running on OS X using Visual Studio on Windows. In order to do this we need to set up the CoreCLR debugging proxy on the Mac and then configure VS accordingly.

We start off by configuring the Mac. Everything we need on the Mac is part of the VS Tools for Silverlight installation and can be found in the directory %ProgramFiles%\Microsoft Visual Studio 9.0\Silverlight\MacIntel\ (or %ProgramFiles(x86)\Microsoft Visual Studio 9.0\Silverlight\MacIntel\ if you’re running a 64-bit version of Windows). We just copy the whole folder over to the Mac e.g. into /Applications/ (you may also want to rename the copy on the Mac as MacIntel doesn’t really describe the content that well). After that we have to mark the files configcoreclrdebug and coreclr_dbg_proxy as executable and then run configcoreclrdebug which will set up the debugging proxy and create a Windows executable containing all the information required to set up VS. It only requires two inputs: A port number in the range from 49152 to 65535 which will be used by the proxy to listen for incoming connections (you can also just hit Enter to accept the default in squared brackets) and a password used to protect the data in the Windows executable.

  HOSTNAME:~ username$ cd /Applications/MacIntel/

  HOSTNAME:MacIntel username$ ls -la

  total 384

  drwxr-x—   6 username  admin    204 Mar  3 05:25 .

  drwxrwxr-x+ 42 root      admin   1428 Mar  3 05:26 ..

  -rw-r—–   1 username  admin  62464 Mar  3 05:25 ConfigureWindowsCoreCLRDebuggingBase.exe

  -rw-r—–   1 username  admin  55383 Mar  3 05:25 MacDebuggingReadme.rtf

  -rw-r—–   1 username  admin  23604 Mar  3 05:25 configcoreclrdebug

  -rw-r—–   1 username  admin  48944 Mar  3 05:25 coreclr_dbg_proxy

  HOSTNAME:MacIntel username$ chmod u+x configcoreclrdebug

  HOSTNAME:MacIntel username$ chmod u+x coreclr_dbg_proxy

  HOSTNAME:MacIntel username$ ./configcoreclrdebug


  Generating debugger certificate and private key…





  Select a TCP port number to be used for debugging: (49152-65535) [58752]:




  Please specify a password at least eight characters long that will be used to

  protect the debugging private key during transportation to the Windows machine

  from which debugging will be performed.



  Re-type password:


  The CoreCLR debugging environment has been successfully configured on this

  machine for the current user. In order to enable debugging from a remote machine

  running Windows it will be necessary to propagate these same configuration

  settings. To aid in this a Windows executable has been created in the following






  HOSTNAME:MacIntel username$


We now copy ConfigureWindowsCoreCLRDebugging.exe from the location mentioned in the output of configcoreclrdebug back to our Windows machine and execute it. All it will ask us for is the password we used to generate the executable.


  Password: ********

  This machine and user account has been successfully configured.




And we’re done. We can now test this by creating a little app, copy the ClientBin folder over to the Mac and execute it there. Then we’ll attach to it by using the Attach to Process… command from VS’ Debug menu. We select CoreCLR Remote Cross-platform Debugging as the transport and enter the name or IP address of the Mac as the qualifier which will get us a list of the processes running on the remote machine. We just need to select the right instance of the web browser hosting the Silverlight runtime (its type will be CoreCLR Remote) and hit Attach. After that we can set breakpoints, check the value of variables and so on as usual.

This posting is provided “AS IS” with no warranties, and confers no rights.

Comments (3)

  1. Well, I published a post on Tuesday and haven’t ever since (not counting the remote debugging post which

  2. Back when Silverlight 1.1 (the predecessor to today’s Silverlight 2 release ) was first announced at