Note to Self: The Windows Store GridView Control, Deconstructed

Tuesday, July 09, 2013 / Posted by Luke Puplett / comments (0)

Here’s a diagram of the GridView control for Windows Store apps, deconstructed into its components. This is intended to show all the templates and styles in various places to help customise this complex control.

Download here.

Labels: , , , ,

Converting ASP.NET WebForms to ASP.NET MVC 4.0

Monday, April 22, 2013 / Posted by Luke Puplett / comments (2)

This is a blog-in-progress while I try to convert an ASP.NET WebForms application to MVC 4. It may completely fail or I may give up, but I thought it might help to share my experiences.

What I am Migrating

It’s a one project ASP.NET WebForms 3.5 site. It’s pretty simple, uses the old Ext JavaScript framework, which became Sencha UI, I think. There’s a fair few pages but not a lot of HTML in each, since its built in XSLT (vomit) from XML coming from an XML database. Much business logic is in the data-layer (vomit II).


My bright idea is not to convert. I don’t think that’s the easiest route, I just don’t know what’s needed for an MVC app, and I want the IDE to be in MVC mode, with the context menu support for views and stuff, which probably won’t happen if I just add some DLL references and setup some routing.

So, I will make a new, empty MVC 4 app and copy in the files from the old world. I know MVC is happy to serve-up ASPX forms pages and controls, and that’s all a WebForms site is – just some ASPX pages and some handlers, maybe some URL rewriting.


So far, I have:

  • Created an empty, new ASP.NET MVC 4.0 project.
  • Set the same project references and NuGet packages.
  • Set my solution and project configurations for staging/QA.
  • Copied over all the stuff from the old Web.config that I think are non-standard, i.e. added to support the old app. I already did this, so its hard to blog at detail but its actually pretty simple.
  • Begun to copy over the basic, high-in-the-dependency-graph controls and pages.

Copying Stuff Across

I have copied /MasterPages and its children, /Classes which are just some .cs files with helpers inside, /Controls which are Web User Controls or ASCX files as well as the default.aspx (all come with their code-behind and designer).

Problem 1 – Solved

In copying the files, drag and drop, from the WebForms project in the same solution, the IDs of the controls on the ‘pages’ (in the ASPX or ASCX files) are not being ‘seen’ in the code-behind. By that, I mean there are red squigglies in the C# wherever they are referenced – its like the controls on the pages are not being compiled.

I reconstructed a control manually, by adding a new one with a different name and copying over the important mark-up and code. This was fine, so MVC is cool with it, just doesn’t like it being copied file by file.

So I figured that it must be related to the designer file. The file doesn’t sit at the same level in the Solution Explorer as the manually created good one, so there’s something odd going on. Opening the designer.cs file is fine but the code doesn’t respond to mouse-overs – its lifeless like a text file.

Solution: The trick is to delete the file and then right-click its parent AS?X file and hit Convert to Web Application which forces regeneration of the designer.cs.

You can copy a load in and then convert at the folder or project level, too, donchaknow.

Problem 2 – Solved

The default route and getting default.aspx to be the page shown at the domain root. This one is easy, although I’m not sure its the proper way. Simple add this route.

routes.MapPageRoute("HomePage", "", "~/default.aspx");

Problem 3 – Solved

Settings in httpHandlers not working, i.e. still going via the routing system. So this site has a load of magic setup in the web.config to make friendly-URLs happen. Of course, this needs to be re-considered in an MVC world, but we’re talking about things like blah.xml which invokes a special handler – its all custom stuff for this old site.

The solution was two step:

- Add the following line to not route requests:


- Also need to update the types in the httpHandlers section in web.config

<add verb="*" path="*.xml" type="Company.XmlHandler, SiteDllFile" />

- To

<add verb="*" path="*.xml" type="Company.XmlHandler, NewMvcSiteDllFile" />

Problem 4

The form values security and validation seems to have been tightened-up in ASP.NET 4.0 or something, because I was getting an exception when reading Form values containing XML fragments. This was remedied with this config setting:

<httpRuntime requestValidationMode="2.0"/>

Problem 5 – At this stage, there has been no problem 4

With everything else copied over and some shared components refactored out into a shared library, everything else is working.

Labels: , ,

Data says Git is officially the world's most woeful piece of software

Monday, April 15, 2013 / Posted by Luke Puplett / comments (1)

When computer programmers have a problem, they turn to StackOverflow. The site has a great feature to vote-up a question, so rather than ask the same question, you can say "Me too" by casting a vote.

So what then is the software with the highest voted questions?

Overwhelmingly, Git.

Problems with Git are responsible for 1 in 5 of the top-voted questions on StackOverflow, which is really saying something when it is such a small tool compared to say, an entire language.

So next time you're having problems with Git and someone tells you its not Git's fault, don't blame the tool, you can point out that it actually really is the most woeful programming software in existence today.

There's a lot of hate for Git but it also has a very active and noisy tribe of supporters, that get very defensive when people dare to criticize Git. Of course, the problem is that criticism and confronting problems is the first step towards making improvements, which banishes Git to an ugly status quo.


Ensuring that two PowerShell scripts don't run at the same time

Tuesday, January 22, 2013 / Posted by Luke Puplett / comments (6)

This quick PowerShell snippet shows how you can ensure only one instance of a script or section of a script executes at a time on a system, i.e. a server running scheduled tasks.

The script will wait while the other script or section completes. The Dispose method releases the mutex and allows any other scripts to take it and run. It should ideally be in a finally block to ensure it always gets released, although I've read that it uses a .NET critical finalizer to ensure release but I don't know if this works as well in PowerShell as it would in a proper .NET process.

        # Obtain a system mutex that prevents more than one deployment taking place at the same time.
        [bool]$wasCreated = $false;
        $mutant = New-Object System.Threading.Mutex($true, "MyMutex", [ref] $wasCreated);        
        if (!$wasCreated)

        ### Do Work ###

Remote PowerShell like SSH

Thursday, December 13, 2012 / Posted by Luke Puplett / comments (0)

Here's a super quick howto for using PowerShell like you Linux dudes use SSH to remotely console into a server.

First, make sure Windows Remote Management is setup on the target server. So RDP onto the box and open a command prompt. Run this:

winrm quickconfig

Now that's setup, close RDP and on your client admin dev type box, open PowerShell 2.0

Run the following commands.

$domainAdmin = Get-Credential
# Enter your domain admin or other privileged credentials in the box that pops up.
Enter-PSSession -ComputerName web3-pool2-ln -Credential $domainAdmin

After a few seconds the prompt should change and you're in. Use 'exit' to come out.

Labels: , ,

Facebook Login for Windows Phone Apps

Friday, May 18, 2012 / Posted by Luke Puplett / comments (3)

The brief: allow new customers to sign up and sign in with their Facebook account, because they have this option on the website, so they’re going to need it in the phone app.
This is a high-level blog post about enabling Facebook login in a Windows Phone application. Once you’ve configured your app at and got your client/consumer ID and secret from, the process to actually authenticate your users is very simple - it’s the bigger picture that’s more difficult and so this blog post aims to prepare you rather than give you a few code snippets for what is essentially just extracting some tokens from a string.
So, with that said, these are the things to consider before writing any code:

  • How does OAuth work?
  • How will a Facebook account map to my accounts?
  • How does this affect my current secure authentication?
  • How will the login screen work on the phone?
  • What happens when the app has been slept for a long time?

How does OAuth work

Facebook uses a version of OAuth. Personally, I like learning specifications and writing my own code, rather than learning a framework or SDK. Usually, the spec is more clearly documented than other people’s SDKs.
Facebook has its own documentation covering how to authenticate, which I strongly advise you to read. The OAuth specification will give you a wider understanding, it’s pretty simple, but I must point out that Facebook doesn’t stick to the spec.
I’m going to explain the process in a nutshell here, but before I do that, consider that your application must register with Facebook and obtain a Consumer ID and Secret which will identify your app to Facebook. The aim is to get hold of an Access Token, which is a short-lived ticket that represents your rights to act on behalf of a Facebook customer.
  • There are a few types of authentication, depending on whether you’re building web apps or mobile/desktop/GUI apps.
  • For a web app, your server redirects the user to the Facebook OAuth sign-in page and passes across your Consumer ID so Facebook knows it’s issuing an Access Token for your app.
  • When doing so, you pass Facebook a URL to redirect back to, after the user signs in.
  • Your server ‘waits’ for the redirect and then extracts a temporary token from the redirect which it used to fetch the proper Access Token directly from Facebook, using an HTTP get.
  • For a client app with a UI, it’s much simpler.
  • Place a Web Browser control on a page and hook-up the Navigated event.
  • You automate the Web Browser control to navigate to the Facebook OAuth sign-in page, the user then logs in.
  • Facebook then redirects to a page you specify (at a domain you preconfigure with Facebook) and in the URL’s fragment portion, is the Access Token, as this occurs, the Navigated event fires a few times.
  • Inspect the Uri at each point to see if it has the Access Token or an error code. As soon as you have the token, you can progress the UI to the next stage.
  • You’re looking for access_token=xyz and expires_in=123 (seconds) parameters in the Fragment portion of the URI, it’s simply a case of parsing the string.

Why use Facebook to authenticate your customers?

Essentially, there are only a couple of reasons. The first is integration: you’d like your app to connect to Facebook and programmatically post to your customer’s feed or see who their friends are, perhaps. The second is to reduce sign-up friction and provide a better experience to the on-boarding process. This may be simply to remove the need for a customer to remember another password (and providing a way to reset forgotten passwords) or because your sign-up process asks a bunch of questions that you could actually just pull from their Facebook profile.
In the latter case, you’ll likely have your own customer entities in a database that will need to be linked to a Facebook account.

Mapping the Facebook account to your own accounts

If you’re retrofitting Facebook login to an existing app, then you’ve probably already got your own login process, so you’re going to need to offer a login screen supporting the old username and password sign-in as well as the new OAuth method.
As mentioned above, you might need to have a process for reading some details from Facebook and creating an account entity in your own system, and you may even wish to offer a way for users of the old sign-in scheme to connect their accounts.
I won’t go into detail about how to do this linkage, but whichever way you choose to accomplish it, you’ll need to ensure that another Facebook OAuth application cannot simply log-in to your app by just sending a Facebook ID to your login system.
Your server-side system should require the Access Token and user’s Facebook ID, and then use the Access Token against the Facebook Graph API directly to obtain the default FB account and check the ID for the user it returns matches what you’ve been sent.
You’ll also need to prove that the Access Token and user ID have come from your app, so you’ll need to sign the data with a secret that’s shared between your servers and your app, which means obtaining/agreeing a key before the Facebook sign-up occurs.
If you don’t do this, then there’s nothing to stop another Facebook app from getting an Access Token and FB user ID and sending them to your login endpoint and masquerading as one of your customers!
There’s an inherent weakness here, in my opinion, that could be strengthened if, when your server fetches the user account using the supplied Access Token from Facebook, you supply your App Secret and FB could ensure that the Access Token was issued to your app.

How will the login screen work on the phone?

If you don’t have an existing login scheme then you only need to supply the Facebook login option, unless for privacy reasons, you’d like to allow your customers to sign-up without Facebook.
It’s safe to assume that login will take place from a dedicated page, as opposed to a popup control. The user should only be bothered by the login screen when they need to login, and that page needs to play host to a web browser.
We also need to consider sign-up, as well as sign-in; your application may need to collect extra information on sign-up, data that’s not available from Facebook, but also, your customers might not want to use Facebook.
In my scenario, I have a dedicated page and flow for non-Facebook sign-up, and a dedicated page and flow for Facebook sign-up and sign-in (combined).
The flow goes something like this:
OAuth Page Flow
The left-most page is the Home Panorama which detects a guest login and provides two menu options for logging-in and signing-up.
The top path consists of:
  • The Login Method Selector page, offering the Facebook login and a normal username + password UI.
  • Using the latter will call the normal login web service and follow the quick route back to the Home page, while selecting Facebook login, will navigate to a page with a Web Browser control.
  • This page will display the standard Facebook OAuth login screen and upon entering details, the browser control will vanish and, if the customer is signing-up, they’ll be presented with a page through which they can supply a screen-name, otherwise, if logging-in, they’re just navigated to the Home page.
  • If sign-up goes well, then a welcome message is displayed and the user is offered the option to post a Wall message or click to go straight to the Home page.
The bottom path consists of:
  • The Sign-up Method Selector page, offering Facebook and ‘Manual’.
  • The Facebook option takes the user to the top flow, whereas the manual route consists of a few more pages / UI that collects and checks all the extra data that’s needed to create an account, data that is normally taken from their FB account details.

What happens when the app has been slept for a long time?

Login credentials are persisted between app use sessions and the Home page is able to detect which login method the user used last time. For a Facebook login, the previous Facebook Access Token is verified and, if expired, the app navigates to the Facebook login page and brings up the Web Browser control.
If the Web Browser has cached login details then the browser will automatically be logged-in, without the user typing anything, and the app will navigate back to the Home page. This flow happens so quickly that it appears that the app opens at the Facebook page, looks busy for a couple of seconds and then goes to the Home page.
This flow might take some time on slow networks but Manual logins can simply authenticate without navigating anywhere and work much more smoothly.
So far, this is all fine and dandy, but in reality the Home page is not the first page of an app. An app may be entered via the back button or on resume, into a state where the user is no longer considered logged-in – the Access Token has expired or your server session has been pruned.
In my app, I use my own MVCVM pattern. I have a Controller in addition to the ViewModel. This is just a personal preference, I like to keep my ViewModels as just ‘binding and commanding surfaces’ with no logic.
Doing things this way keeps me from adding spiralling side-effect logic in property setters and coerces me to use dedicated helper and utility classes rather than be tempted to inherit too much application logic - I’ve worked on apps that reuse logic by VM subclassing and it gets ugly. I also like to build standard ‘dumb’ VMs which can be reused across the app and contain only what needs to be on the screen.
Saying that, I do use inheritance in this situation. My base PageController has a set of virtual methods which orchestrate all the initialization, one of which is called to check authentication.
Each time a page is navigated to, the PageController runs some code to ensure the user is logged-in which allows me to redirect the user to the Login page and return afterwards using the BackStack. I also check the BackStack and remove the sign-in pages so the user can’t back into them.
With this logic on each page, even if the user lets the phone go idle overnight while on a page deep within my app, the Login flow will run in the morning, as soon as the page resumes.
Of course, you don’t have to have funky Controllers and virtuals to do this, but it needs bearing in mind that authentication isn’t just something that happens on the Home screen.
Time will tell whether this page flow method works. It’s perfectly feasible to embed a Web Control in a popup UI control or inject it into the visual tree. As networks get faster (I’m looking at you, 4G), then Facebook login will become a less irksome UI dance.
Have fun, and here’s some useful links:
Facebook Authentication Documentation
OAuth 2.12 – although Facebook strays from the standard in some fairly major ways.
Where Facebook veres from the OAuth standard.

Labels: , , , , ,

Windows Phone Panorama background image cropped when smaller than screen size.

Wednesday, May 16, 2012 / Posted by Luke Puplett / comments (0)


Notice that the background image repeats just before the ‘r’ on the right side of the left image, but its fine on the other image.

This image on the left is 512x384 whereas the image on the right is twice the size, 1024x768. It seems that when the image must be stretched to fill the height of the screen, the width is truncated. When an image must be shrunk to fit, then the width is preserved.

The Sretch property isn’t required for the larger image, but it works when set as Fill or UniformToFill. The smaller image needs UniformToFill to look correct.

Labels: , ,