Debugging Windows Phone 7 device network access with just a laptop

It’s a strange world. Today I needed to debug an iPad’s web traffic, and ended up getting instructions from the Dutch Windows Phone 7 DPE Matthijs Hoekstra. To dry run the solution I tried hooking up my own Windows Phone 7 an so was able to see Birdsong actually sending and downloading messages.

Now there are numerous sources around the internet describing what you should do to get this far but most only show pieces of the puzzle, so I decided to do a quick write-up on how to do this for Windows Phone 7.

Prerequisites

• One laptop running Windows 7 with a WiFi card. I used a HP Probook 4720s
• Connectify
• Fiddler2
• One Windows Phone 7 device (duh)

Make sure you laptop has internet connectivity, either by WiFi or by cable.

Install and configure Connectify

Download and install Connectify. Now installing this might be a little scary – it wants to install an unverified driver, and the first time I tried it the install got stuck, I had no network connectivity anymore, rebooted, uninstalled Connectify and then painlessly re-installed.

Anyway, it comes with a simple wizard, that asks you for a network name, as password, a connection to share. Connectify runs in the system tray and if you click on it, it pops up like this showed left.

You can see that my WiFi card now is used by the laptop itself to connect to the internet and as hotspot as well :-). But I could just as easily share a cabled internet connection (as I did this afternoon at my work). You can even see my hotspot’s password, so now you can steal my internet connection when you are in the neighborhood and I leave Connectify running (and then still it gives a bubble notification saying someone connected).

Your Windows Phone 7 can now already share your laptop’s WiFi connection – if you go to Settings/WiFi you can already see the network showing up. As you can see on the image my HTC 7 Pro has connected to it successfully

 

 

 

Install and configure Fiddler

Just install Fiddler the usual way, but then click Tools/Fiddler options and click tab “Connections”. Right under the box “Fiddler listens on port 8888” there’s a checkbox “Allow remote computers to connect”. Tick that one. close down Fiddler, start it again, and this will bring a Windows Firewall check box to your screen. Check all three checkboxes, and click “Allow Acces”.

Configure your Windows Phone 7

Pick up your phone, again, go to Settings/WiFi, connect to the Connectify network if you have not already done so, using the password you picked for it. As the phone is connected, tap your network, locate the “proxy” toggle, click it, use your laptops’ name as proxy and port 8888 as port, and you are done. Note – both my access point and my laptop are called “JSC7”, but they could be different. Always use your computers’ name for proxy.

 

 

 

 

 

Done

You can now spy on your Windows Phone 7’s network. I fired up Birdsong and saw it actually do something

Some final words

If you have an access point handy, you might skip the whole Connectify stuff, just define your PC as a proxy for that network in your Windows Phone 7 settings and only configure and fire up Fiddler on that PC. But I did not have a wireless AP I could connect my Windows Phone 7 to so I had to resort to Connectify.

Oh by the way, this works for a iPad as well :-)

Running and debugging a Windows Managed Service directly from Visual Studio.NET

Developing a Windows Managed Service (i.e. a service written in .NET ;-) ) is a lot easier than it used to be, still it can be a real PITA to debug, especially in the early stages, and even more so when the service is a kind of server and something goes wrong with the communication. You are continually running in circles:

1. Stop running service
2. Replace binaries
3. Start services
4. Attach Visual Studio debugger to process
5. Launch your client process
6. Find bug
7. Fix bug
8. Repeat until no more bug.

Life could be so much easier if you could launch the service from Visual Studio and see how it behaves. And the fun thing is, you can.

1. Create a new service project in your solution
If you already have a service project you can skip this step. I'll add a service project DemoService with a Service MyService in it with not too complicated functionality:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.ServiceProcess;
using System.Text;

namespace DemoService
{
  public partial class MyService : ServiceBase
  {
    public MyService()
    {
      InitializeComponent();
    }

    protected override void OnStart(string[] args)
    {
      Console.WriteLine("OnStart");
    }

    protected override void OnStop()
    {
      Console.WriteLine("OnEnd");
    }
  }
}

2. Change the application output type
Right-click the DemoService project, choose "Properties", click tab "Application". Default this says "Windows application" - change this to Console application

3. Add debug mode methods to your service class

#if DEBUG

  public void StartService()
  {
   OnStart(null);
   Console.WriteLine("MyService started, press >ENTER< to terminate");
   Console.ReadLine();
  }

  public void StopService()
  {
   OnStop();
  }
#endif

4. Add debug mode code to the Main method
Open the "Program.cs" file in the service project, and change it so it looks like this

using System;
using System.Collections.Generic;
using System.ServiceProcess;
using System.Text;

namespace DemoService
{
  static class Program
  {
    /// 

    /// The main entry point for the application.
    /// 
    static void Main()
    {
#if DEBUG
      MyService s = new MyService();
      s.StartService();
      s.StopService();

#else
      ServiceBase[] ServicesToRun;

      ServicesToRun = new ServiceBase[] { new MyService() };

      ServiceBase.Run(ServicesToRun);
#endif
    }
  }
}

And that's it. You can now run the 'service' as a program in debug mode - it will pop-up a console window in which the 'service' runs and says OnStart MyService started, press >ENTER< to terminate

If you hit enter, you will just be able to see "OnEnd" passing by before the window closes. Of course, normally you will launch a thread of some kind in the OnStart method, or you will start a WCF service, and then you can see the dynamic behaviour of the 'service' while it runs by adding more "Console.WriteLine" calls - or, since it is already a process inside VS.NET, see it hit breakpoints or the exception you have been hunting all week now. And by setting the solution to "Multiple Startup" you can start both 'service' and client in one go.

And if you make a release build, all this stuff will be left out and the service will be compiled as a proper service which can be installed and will run in the usual way.

CAVEAT: be aware that the 'service' is running with your login credentials when it runs in a console window, and not as 'System'. This method is therefore not applicable when debugging access releated problems.