Tech in the 603, The Granite State Hacker

Aggregating Windows Phone Store Apps into RSS

Naturally, there’s an app for the Granite State NH Windows Phone Users Group.   🙂

I recently added the ability to aggregate listings from the Windows Phone app store to create a list of apps published by our members.  RSS seemed the natural way to present the info, since it was consumed easily by an App Studio app.

I showed it off a bit at the users group, and got a few requests for some of the code.

Once published, you should be able to go to http://{yourserver}/{optional}/GSWPUGServices.svc/GetData to load the RSS feed.

It’s currently published at

Here’s the project.

Tech in the 603, The Granite State Hacker

Windows Authentication fails due to machine name alias issue

Another tidbit I ran into recently that I hit once long ago, and don’t want to forget it again:

I have a VM who’s name I changed.  Trying to develop a WCF webservice for an SOA initiative, I ran into a completely inexplicable authentication failure when I tried to authenticate with my own local user on the machine.

Turns out the quick & easy fix (identified in this post from MS ) ended up pointing me to the solution of:


REG_MULTI_SZ key “BackConnectionHostNames” to my registry at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 . 

One alias per line…

I added a couple lines for various aliases that I use for the machine, enabling me to authenticate as {alias}\{userName}, locally, on the machine.

Tech in the 603, The Granite State Hacker

Url for WSDL coming back with wrong Host name in WCF service

Here’s something I don’t want to forget…  working on a WCF Service…

Using TLS, the address of the wsdl didn’t match what was in the SSL certificate.  (the server certificate had the FQDN “friendly name” (, and I was just getting back the “host” name. 

Naturally, this was causing problems. 

There was lots of guidance about setting the host name using some old vbs script that turned out to be a red-herring for IIS 7, anyway.

The quick & simple solution was to add in the behavior for the service:


          <useRequestHeadersForMetadataAddress />
          <!– To avoid disclosing metadata information,

          set the value below to false and remove the metadata

               endpoint above before deployment –>
          <serviceMetadata httpGetEnabled=false httpsGetEnabled=true  />
          <!– To receive exception details in faults for debugging purposes,

          set the value below to true.  Set to false before deployment

          to avoid disclosing exception information –>
          <serviceDebug includeExceptionDetailInFaults=True />