Get Windows Phone beta testers, world wide, using

Testing your Windows Phone apps is really time consuming if you have to do it yourself. I used to let my apps being tested by friends by unlocking their devices and installing the new app by hand on their devices.

A much better way is submitting the new app to the store as a BETA version in the Windows Phone Developers portal. When you submit an app, you can mark it at Beta:


Just provide a list of unique email addresses which are used by your testers to get to the Windows Phone Store (the account associated with their phones) and submit the app.

It will take a few hours for the app to be accepted (which is really fast, only last year it took a couple of days). Then the app will become available in the store, hidden, and it is only downloadable for these users listed as beta tester:


You will get a download address like . So share it with the testers:


You just have to send that store address to your testers, finally.

And if you want to add other testers, just update the app, just update the list, resubmit the app, wait a few hours (again, for acceptance) and provide them the link too. (On a personal note, I do not like this procedure. If I do not submit a newer version and only want to update the list of testers, then why do I have to wait for the certification process and an update in the store. Seems like a lot of overhead…)

But now is available as preview. This service (only for Windows Phone developers) makes it possible for them to ‘advertise’ their beta apps for free to registered beta testers. This makes it possible to get beta testers from all over the world with less effort and the service makes it easy to communicate to all your testers. And it’s free!

And for you and me, as beta testers, we can see which beta versions of apps are popular or new and we can ask to join the beta test.

So let’s register an app. Just take the App ID (and if this is your first app, your Publisher ID) so the site knows your beta app and can download settings of it:


After that, testers can join your beta test. Here you can see 13 testers are available already (it started with zero):


So now my beta app is published and discoverable (that’s how I got these 13 testers):


This does not mean everybody can download my app directly. No, beta testers first have to register to my app in and then I will retrieve their email address, which they use to visit the Windows Phone store, to formally accept them as testers.

This example app has already been submitted and some tester have already downloaded the app (see later). But two new testers just joined:


How can I make these two persons to download my app?

This is where the magic happens. First, provides me a list of all beta testers which have registered for my app:


Then using this list I can update my beta app in the Windows Phone Developer dashboard and update the (growing) list of testers:


And when this update is certified as a new beta version the developer will receive an email with the list of all the testers which are registered. Finally, just forward that email to and after a view hours, all new testers (just them, nobody else) will receive a nice email with the download link:


And as seen before, we can track if your testers have used this download link. So you have a simple check to see how many user could have downloaded your app 🙂

Is this all? Almost! There is also a simple way to send a message to your users (only once a week to prevent spamming).

And there is swag. By using you will be granted free coupons for eg. AdDuplex, myFreeApp and AdDeals.

So in the end, this is a useful add-on to the Windows Phone Developers portal but it would be nice if this was just an integrated feature. And this would be a nice feature for Windows (10) (Universal) Store apps too.

Note: I got a message from a tester running Windows 10 Mobile Insider preview. He was not able to open the link. The referral to the regular store ended up in a ‘beta’ store?

wp_ss_20150622_0003 wp_ss_20150623_0003

So it’s a no-go for Windows 10 Mobile Insider preview at this moment…


Azure SDK 2.6 breaks system.diagnostics configuration

In our project we have several web roles and worker roles, all of them depending on the Azure SDK (..)

Recently we migrated our solutions to Azure SDK 2.6 but we noticed a nasty little issue: When updating the web.config, not always the system.diagnostics node is updated. It was sticking to version 2.2.

Updating seems easy, just right-click the role configuration, go to the properties menu and a simple dialog is shown:


The update is very smooth, normally.


And we noticed the migration of the standard trace listener went very well:

        <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"          name="AzureDiagnostics">
          <filter type="" />


But the sharedlisteners failed.

After deployment we got some errors regarding not referencing the Microsoft.WindowsAzure.Diagnostics dll’s.

Everything was checked and then we discovered a reference to the old version in the web.config diagnostics section. We had to change by hand to

      <add name="AzureLocalStorage" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <filter type="" />
      <source name="TopecSecurityTokenService" switchValue="Verbose">
          <add name="AzureLocalStorage" />

This seems rather trivial but if tracing fails, there is nothing traced 😉 In the end we had some luck, the development environment exposed the error to the browser.



Nuget “Include Prerelease” not equals “latest version”

Today I stumbled on ‘strange’ behaviour of Nuget. Well, it’s not really strange but more like confusing.

It started when I added Application Insights to an existing website. This can be done in several ways (there is really good tooling inside Visual Studio when creating a new website or with the right-click on the project) but I was adding it by hand.

So I added Application Insights for Web Applications. And version 0.17.0 was added. This is relying on the Application Insights API package 0.17.0.

All went well.


But later on I noticed(*) that there is a even newer version of the SDK package is available: 0.17.1


Well, my assumption is then when I ask for packages, including prereleases, I automatically get all the latest versions. I was wrong.

What did I learn today? Do not take Nuget and it’s release management for granted. After installing a certain package, check for updated and decide if that one is good for you.

* I ran into a problem when I simply added the System Diagnostics listener nuget package. Suddenly my code was not working anymore (and I got this ‘Object reference not set to an instance of an object’ when simply consuming the Telemetry client). I traced it down to a line of code in the Application_Start() method in the App.config. There I add the Application Insights instrumentation key by hand because we want to separate tracing from developers and from testing and from production (we are using an OTAP environment). Just by removing that line, everything was working again. But I lost the iKey choice. In the end, just updating the SDK nuget package fixed this error.



Tracking Asp.Net session in Application Insights

Azure Application Insights is a great way to get to know your applications, both from the outside (how is the user experience) and from the inside (how is your code performing).

We use it a lot to find out the slowest code and the slowest pages. And we have added a listener to the diagnostic tracing, so now we have a good insight in tracing errors.

Another nice feature is that we can follow the user during their travels through our site. Each web page, each javascript call, each database query and each external HTTP call is linked by a number of telemetry values like Session Id, User Id and OperationId.

But we had one issue with the identification of related items, the specific identification is not clear in the browser: the Application Insights identification is not available in the client. And the AI sessionid is not an Asp.Net sessionid.

We solved it by tracing explicitly the Asp.Net session. Because we can show it in the browser using Razor:

<div>Session = @Session.SessionID</div>


And we can find the sessionid in Application Insights when traced.

It’s not dangerous to expose this id on a page, the sessionid can already be found in every website when checking the communication or the cookies, so no extra security breach here :-).

There was only one extra point of attention. As long as the session is not actively used in code, each call get’s another sessionid… it is not very unique yet.

You can solve this in two ways.

First, just write a (dummy) value into the session:

Session["dummy"] ="1234";

The second, a bit more formal way, is forcing the creation of a unique session in the global asax:

public class MvcApplication : System.Web.HttpApplication
    protected void Application_Start()    
    protected void Session_Start()
        // nothing to see here. Just to keep same session
        var tt = new TelemetryTracker();
        tt.TrackTrace("TrackTraceSession " + Session.SessionID
                      , SeverityLevel.Information);

This method is only executed once, when the user calls a page for the first time.

So now we know for sure which (Asp.Net) session the user is using.


And we can track the user as far as needed. And this is also a great help during development.