Rockford Lhotka

Set rich text into RichTextBlock control

Rockford Lhotka — Fri, 11 May 2012 17:33:13 GMT

Unless I’m missing something, there’s no direct way to bind XAML-ish text to a WinRT RichTextBlock control.

For example, if I have some text like:

<Paragraph>
This is some text. And some <Bold>bolded text</Bold>.
</Paragraph>

I would like to just bind this text to a RichTextBlock control for display. Sadly there’s no way to put content into a RichTextBlock control at runtime short of adding Block objects to the control’s Blocks collection.

As a workaround, I’ve been playing with the idea of a custom control like this:

using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Markup;

namespace Application11
{
public class RichTextDisplay : ContentControl
{
    public static readonly DependencyProperty XamlProperty =
        DependencyProperty.Register("Xaml", typeof(string), typeof(RichTextDisplay), new PropertyMetadata(null, XamlChanged));

    public string Xaml
    {
      get { return (string)GetValue(XamlProperty); }
      set { SetValue(XamlProperty, value); }
    }

    private static void XamlChanged(object sender, DependencyPropertyChangedEventArgs e)
    {
      var ctl = (RichTextDisplay)sender;
      var xaml = new System.Text.StringBuilder();
      xaml.Append(@"
<UserControl
xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
xmlns:x=""http://schemas.microsoft.com/winfx/2006/xaml""
xmlns:mc=""http://schemas.openxmlformats.org/markup-compatibility/2006"">
<Grid>
    <RichTextBlock>");
      xaml.Append(ctl.Xaml);
      xaml.Append(@"
    </RichTextBlock>
</Grid>
</UserControl>
");
      var text = xaml.ToString();
      var xr = (Control)XamlReader.Load(text);

      ctl.Content = xr;
    }
}
}

This isn’t ideal, but it does work. The RichTextDisplay control dynamically creates a RichTextBlock control, inserting the XAML document text into the body of the newly created control.

I suppose the other alternative would be to write code that parses the text to find the XAML elements and produces a series of Block objects that can be added to the control’s Blocks collection…

Using the MVVM pattern requires a framework

Rockford Lhotka — Mon, 07 May 2012 20:01:55 GMT

There are three fairly popular presentation layer design patterns that I collectively call the “M” patterns: MVC, MVP, and MVVM. This is because they all have an “M” standing for “Model”, plus some other constructs.

The thing with all of these “M” patterns is that for typical developers the patterns are useless without a framework. Using the patterns without a framework almost always leads to confusion, complication, high costs, frustration, and ultimately despair.

These are just patterns after all, not implementations. And they are big, complex patterns that include quite a few concepts that must work together correctly to enable success.

You can’t sew a fancy dress just because you have a pattern. You need appropriate tools, knowledge, and experience. The same is true with these complex “M” patterns.

And if you want to repeat the process of sewing a fancy dress over and over again (efficiently), you need specialized tooling for this purpose. In software terms this is a framework.

Trying to do something like MVVM without a framework is a huge amount of work. Tons of duplicate code, reinventing the wheel, and retraining people to think differently.

At least with a framework you avoid the duplicate code and hopefully don’t have to reinvent the wheel – allowing you to focus on retraining people. The retraining part is generally unavoidable, but a framework provides plumbing code and structure, making the process easier.

You might ask yourself why the MVC pattern only became popular in ASP.NET a few short years ago. The pattern has existed since (at least) the mid-1990’s, and yet few people used it, and even fewer used it successfully. This includes people on other platforms too, at least up to the point that those platforms included well-implemented MVC frameworks.

Strangely, MVC only started to become mainstream in the Microsoft world when ASP.NET MVC showed up. This is a comprehensive framework with tooling integrated into Visual Studio. As a result. typical developers can just build models, views, and controllers. Prior to that point they also had to build everything the MVC framework does – which is a lot of code. And not just a lot of code, but code that has absolutely nothing to do with business value, and only relates to implementation of the pattern itself.

We’re in the same situation today with MVVM in WPF, Silverlight, Windows Phone, and Windows Runtime (WinRT in Windows 8). If you want to do MVVM without a framework, you will have to build everything a framework would do – which is a lot of code that provides absolutely no direct business value.

Typical developers really do want to focus on building models, views, and viewmodels. They don’t want to have to build weak reference based event routers, navigation models, view abstractions, and all the other things a framework must do. In fact, most developers probably can’t build those things, because they aren’t platform/framework wonks. It takes a special kind of passion (or craziness) to learn the deep, highly specialized techniques and tricks necessary to build a framework like this.

What I really wish would happen, is for Microsoft to build an MVVM framework comparable to ASP.NET MVC. Embed it into the .NET/XAML support for WinRT/Metro, and include tooling in VS so we can right-click and add views and viewmodels. Ideally this would be an open, iterative process like ASP.NET MVC has been – so after a few years the framework reflects the smartest thoughts from Microsoft and from the community at large.

In the meantime, Caliburn Micro appears to be the best MVVM framework out there – certainly the most widely used. Probably followed by various implementations using PRISM, and then MVVM Light, and some others.

Should I learn Silverlight? Objective C? HTML 5?

Rockford Lhotka — Thu, 26 Apr 2012 15:32:58 GMT

I am sometimes asked for technical career advice. A common question these days is whether it is worth learning WPF, or Silverlight – .NET and XAML in general I suppose, or would it be better to learn HTML 5 and JavaScript, or perhaps even Objective C?

This is a challenging question to be sure. How good is your crystal ball?

XAML appears to be alive and well – WPF, Silverlight, and now WinRT (Windows 8 – and probably Windows Phone 8 and “Xbox 720” and more) all use XAML.

I look at the WinRT usage of XAML as being essentially “Silverlight 6” – it is far closer to Silverlight than WPF, but isn’t exactly like Silverlight either. Assuming success with Windows 8, WinRT will become the new primary client dev target for most smart client development (over the next few years).

The primary competitors are Objective C (if you believe iPads will take over the client space), and HTML 5/JavaScript (if you believe in ~~fairy tales~~ the concept of ‘one technology to rule them all’).

This is where the crystal ball comes into play.

Do you think Apple will displace Microsoft – iPads will replace the use of Windows – as the monopoly client OS?

Do you think the concept of ‘natural monopoly’ that has caused the Windows hegemony over the past 20 years is at an end – that some fundamental economic shift has occurred so companies are now willing to increase their IT budgets as a % of revenue to accommodate multiple client platforms (unlike the past 20 years)? In which case business app developers should expect to support at least iPad and Windows, if not Android, into the future?

Do you think that Windows 8 and WinRT will be strong enough to withstand the iPad onslaught, and that the natural monopoly economic effect remains in place, so Windows will remain the dominant client platform for business apps into the foreseeable future?

These are really the three options, resulting in:

Objective C slowly overtakes .NET and we ultimately are Apple devs instead of Microsoft devs
H5/js rules the world as the ‘one technology to rule them all’ and vendors like Microsoft and Apple become entirely irrelevant because we live in a purely open-source world where nobody makes money off any platform technologies, so probably the only hardware/OS left is something like Android running Chrome, because it is a 100% commodity play at that level
.NET and XAML remain entirely valid, and life generally continues like it is today, with a mix of .NET smart client work and primarily server-based web work with h5/js primarily used to boost the user experience, but not often used to write standalone smart client apps

My crystal ball leans toward option 3 – I don’t think economic realities change much or often, and I struggle to see where IT departments will come up with the increased budget (% of revenue) necessary to build apps for both iPads and Windows over the long term. It will be measurably cheaper (by many, many, many thousands of dollars) for companies to buy employees Win8 tablets rather than building and maintaining both iOS and Windows versions of every business app.

And I don’t believe in the ‘one technology to rule them all’ idea. That hasn’t happened in the entire history of computing, and it is hard to imagine everyone on the planet embracing one monoculture for software development. Especially when it would be counter to the interests of every platform vendor out there (Microsoft, Apple, Google, Oracle, and even IBM).

Still with me?

To summarize, I think learning XAML is time well spent. Today that’s WPF or Silverlight. There is absolutely no doubt that Silverlight is closer to WinRT than WPF, and people building SL apps today will have an easier time migrating them to WinRT later, whereas most WPF apps will be a pretty big rewrite.

But there’s nothing wrong with focusing yourself on h5/js. If you do so, I suggest doing it in a way that ignores or minimizes all server-side coding. If h5/js does take over the world, it will be used to create pure smart client apps, and if there’s a “web server” involved at all, it will exist purely as a deployment server for the client app. The ‘pure’ h5/js/jquery/etc. world isn’t linked to any vendor – not Microsoft, Apple, or anyone. To me this represents a pretty major career shift, because to truly embrace h5/js as a complete software development platform is so demanding (imo) it won’t leave time to retain .NET or other vendor-specific technology expertise.

For my part, I’m not yet ready to abandon Microsoft for h5/js, because I think Windows 8, WinRT, .NET, and XAML have a rather bright future. A year from now I think a lot of people will be happily using Windows 8 desktops, laptops, and tablets – and hopefully a lot of Windows Phones, and with luck we’ll be looking forward to some cool new Xbox. I live in (I think realistic) hope that my .NET/XAML skills will apply to all these platforms.

What does your crystal ball say?

DRM-free books

Rockford Lhotka — Wed, 25 Apr 2012 22:27:19 GMT

I think this is interesting:

http://boingboing.net/2012/04/24/tor-books-goes-completely-drm.html

It is particularly interesting to me, because I’ve been publishing my ebooks and videos DRM-free for several years now, and have recently been thinking about rethinking my stance on DRM.

Specifically because there really is a lot of piracy. This does include being able to find my content on criminal warez sites, but that’s actually not my concern. My primary issue with piracy is that it is too easy for companies that use CSLA .NET to buy one copy (technically a content license for one person) of my books/videos and to then share that content with their entire development team.

Although that is technically a criminal act, I don’t think most development team managers intend to be criminals. I think they intend to be frugal. I can hear the discussions in my head: “If he really meant for us to buy a copy for each developer he’d have made it harder to copy.” Or variations on that theme.

(yes, I’ve worked in business too – for around 25 years – and I know exactly how these conversations unfold)

The reality is this: I believe most people are basically decent. I also know for a fact that DRM punishes honest consumers, and does little or nothing to stop true criminals.

So I’ve chosen for years to be DRM-free. This way an honest consumer who buys my content is able to get a PDF or WMV file that they can easily read/watch on nearly any device, as they choose. No worries about licenses expiring or losing keys or passwords.

And the fact is, that if I did use DRM, the really bad guys would crack the DRM in a matter of hours or days, and the content would still be on criminal warez sites.

I’ve been rethinking my stance on DRM, because it would encourage otherwise basically decent people to actually buy the required number of copies of the content.

And yet I really don’t want to cause pain to honest consumers by using DRM. So I’m torn.

I tweeted the other day that I am considering releasing some future “ebook” content as a Windows 8 Metro style app. Not as a PDF, but literally as an app. It is an interesting idea, because it would basically force each developer to purchase their own copy of the content (or share their Microsoft Live ID passwords with each other), and yet wouldn’t technically be DRM. The app would just work – no keys or passwords to lose or expire – because once you buy a Windows 8 app from the Microsoft Store, you own the app and there’s no muss or fuss.

There are drawbacks to this. As someone pointed out, not all CSLA users are on Windows (especially now that we support mono for Android, Linux, and OS X). And I’d have to write an app in addition to creating the content – not as simple as writing the content as a Word document obviously.

So I’ll be very interested to see what Tor Books finds out as they release all their books DRM-free. Will they dodge the DOJ/Apple/Amazon legal/distribution traps as they are trying to do? Will their content be pirated more than it already is? In short, it will be interesting to see if this turns out to be a win, loss, or draw for them over time.

In the meantime, I’ll keep working on CSLA version 4.5 and thinking about whether to remain DRM-free, go with DRM, or perhaps build a “book as an app”.

No BindingExpression in WinRT?

Rockford Lhotka — Mon, 23 Apr 2012 22:10:32 GMT

The lack of the BindingExpression type and related functionality in WinRT is a serious issue to anyone trying to create custom controls. Hopefully this issue will be resolved post-beta.

Sadly, the only information I’ve been able to find on this topic from Microsoft is the suggestion to use LostFocus event handlers instead of binding. Obviously that’s a pretty useless workaround when trying to create a custom control

I started writing a data binding engine for Android (because they don’t have one at all). It would be a serious shame if we’re forced to write a data binding engine for XAML in WinRT just to be able to implement basic custom control concepts…

Windows 8, BYOD, and AD membership

Rockford Lhotka — Mon, 23 Apr 2012 16:10:41 GMT

Microsoft recently posted some details regarding the way Windows 8 (specifically ARM-based tablets running Windows RT) will work in a domain.

http://blogs.msdn.com/b/b8/archive/2012/04/19/managing-quot-byo-quot-pcs-in-the-enterprise-including-woa.aspx

This related article from Steven Vaughan-Nichols suggests that Microsoft’s strategy is flawed:

http://www.zdnet.com/blog/networking/windows-8-tablets-not-open-for-business/2261?tag=nl.e539

And he could be right, but I think there’s substantial room for hope.

I speculate that Microsoft is thinking along the following lines:

If a company buys a Win8 tablet for an employee, they’ll probably buy an Intel-based tablet so it can be a tablet and also a laptop (with a keyboard/mouse), and most importantly so it can run existing line of business applications required for the employee to do their actual work.

I have such a tablet today, and I truly love the fact that it is a tablet and a laptop so I get the best of both worlds. It is wonderful!

And it can join an AD domain, and probably should join the domain, because it is corporate property.
If a person buys a Win8 tablet for themselves, they may well buy a cheaper and lower-powered ARM-based tablet. Such a device is a tablet, I suspect most will also double as a laptop with Office 15 (with a keyboard/mouse) – but they won’t be able to run existing line of business applications because those applications are Windows Forms or WPF or Silverlight.

A person, spending their own money to buy a device, is probably going to be unwilling to allow their corporate IT folks to set policies and perform administration tasks on their personal device. If my company wants to muck around with my devices, they can buy me the device! The last thing most people would ever want is for corporate IT to muck around with their own personal property.

So the fact that a Windows RT tablet can’t join a domain might be a true blessing. Microsoft is doing us a favor by eliminating the possibility that your corporate IT might insist on managing your personal property – because it just doesn’t work that way.

I’ve talked to people quite a lot over the past few months, about a possible dystopic future where employees are required to buy and support their own devices. All you have to do is take BYOD to its logical conclusion, and things look (to me) quite bleak. Surprisingly I’m finding that quite a few people in our industry thing this could be a good thing.

So here’s my train of thought.

One reason companies like BYOD is that the cost of computing shifts from the company to the employee. The company no longer has to buy the employee a laptop, because the employee chose to shell out $800 to get an iPad, and then insists that they be able to use it at work. As a result, IT can just say “OK, use it, but we don’t really support it”, and away you go. The company saves hardware and software purchase, licensing, and support costs. The burden of having a machine on which to do work falls on the employee – including the costs of acquisition, licensing, software, and support.

Now we’re not quite to that point yet. But I have heard CIO or IT director level people say, in so many words, that they see this BYOD thing as a way of cutting costs. So they are thinking exactly along this line, and it is a small step from employees insisting that they get to use their own devices, to employers requiring that employees supply and use their own devices.

And this is important, because true BYOD is incredibly expensive! In the long run, it means that all line of business apps must either be written in the highly volatile HTML 5 world, and tested on every conceivable device. Or they must be written and tested numerous times – in .NET, Objective C, Java, etc.

Magenic does quite a lot of mobile development these days, targeting iOS and Android mostly. And every time we get an Android project we have to go buy a whole new set of tablets for testing – because that platform is changing so fast, and is so inconsistent across devices and OS versions. This is true for native and HTML 5 apps – in all cases we have to test across a wide array of devices due to differences in the hardware, OS, and/or browsers.

So I feel confident saying BYOD is extremely expensive. And that might be fine if IT can figure out how to offset that expense. One way to help do that is to entirely eliminate the costs associated with hardware, OS, and support by shifting that responsibility to employees.

“You want to work in our shipping department for $17/hr? Great! Just make sure to bring your $800 iPad to work on Monday when you start. Oh, you don’t have an iPad? You don’t have $800 laying around? Well sorry, then you can’t work here.”

You think this won’t happen? Maybe not. I hope not.

But at some point IT is going to have to justify and/or offset the costs of BYOD. At some point in the next couple years the CEO/CFO or board of directors is going to ask why IT costs have spiraled out of control, and the answer will be “because you said we had to support the iPads used by our executives”. At that point the proverbial sh*t will hit the fan, and some IT directors will lose their jobs, and BYOD will come to a sudden and inglorious end.

In the meantime, we can all be happy that there’s no way IT can join our Windows RT tablets (or iPads or Kindle Fires) to the AD domain. Because those are our personal property and shouldn’t be subject to corporate administrative policies and more than our cars, our televisions, or our other personal property.

Code Mastery Boston

Rockford Lhotka — Thu, 12 Apr 2012 13:43:05 GMT

Last year Magenic held a series of free one-day technical training events in cities around the US. These events were popular and successful, so we’re doing it again this year.

I am pleased to announce that our first event is Code Mastery Boston on May 2 – so coming up soon!

These are FREE events, open to anyone wanting to get in-depth technical information. In Boston we have two tracks: .NET software development, and SQL Server/Business Intelligence.

I am delivering the keynote speech at the event, where I’ll be talking about the state of the Microsoft development platform and overall ecosystem. We are at an exciting point in the history of Microsoft, where yet again they are an underdog forced to innovate to overcome tough competition in the form of the iPhone/iPad devices, while also dealing with the commoditization of client computing, the emergence of HTML 5 as a real development platform, and the potential of cloud computing.

Our breakout sessions cover web, cloud, service, and Windows 8 software development, and SQL Server 2012, data warehousing, and business intelligence.

This is not an event to be missed, so if you are anywhere in the northeast it will be worth your time to spend the day with us at Code Mastery!

Windows 8, Start Screen, Multi-Monitor Usability

Rockford Lhotka — Fri, 06 Apr 2012 15:50:13 GMT

I've been watching a number of discussion threads regarding the usability of Windows 8, especially regarding the start screen, Desktop application usage, and multi-monitor scenarios.

All I can say is don’t knock it until you try it.

I’ve been running Win8 on my tablet and laptop for a few weeks now. The work I do on my laptop is often multi-monitor, and is real work.

There are three themes I’d like to address, based on my full-time usage experience thus far.

First, some people feel that Microsoft is making a mistake by having WinRT (Metro style) and Desktop apps run on the same machine at the same time. I vehemently disagree. I absolutely want one machine that I can use as a tablet on the plane, and as a real computer when I get to my destination. My tablet does this (Samsung from //build/) for almost everything, except when I’m doing distributed computing demos and need my full laptop to run virtual machines (because my laptop has tons of memory and an i7, vs the tablet with less memory and an i5).

I love the fact that I have WinRT apps, which are far superior to most web sites, for consuming news, weather, etc. And I love the fact that the same machine, plugged into a small portable dock, has a keyboard, mouse, second monitor, and can run Visual Studio just fine!

Second, there’s this idea floating around that the Win7 start menu is superior to the new Win8 start screen. That doesn’t hold true for me. Let me explain why.

When I read the Microsoft blog post about the Win7 telemetry data they used to design the start screen, they were describing me. When I use Win7 I pin my common apps and web sites to the start bar, and to run any other apps I press the Windows key and type part of the application name, then press enter. Almost never do I actually use the start menu to browse for apps.

In Win8 (keyboard/mouse – desktop/laptop computer) I pin my common desktop apps to the start bar, and my WinRT apps to the first page or two of the start screen. And I still press the Windows key and type the first part of the application name to run other applications. In other words, THERE IS NO DIFFERENCE between Win7 and Win8 from my perspective – other than that the live tiles from news/weather/stocks/etc. make the start screen a useful dashboard – so it is BETTER than Win7.

(as an aside, I do have some Desktop apps on my start page tiles too – but I find that I rarely use those tiles, preferring instead to tap the Desktop tile and then launch from the start bar – a personal quirk I suppose)

Third, the multi-monitor problems aren’t as bad as they are being portrayed. But the story isn’t good either, and I truly hope it improves over the next few months.

If you are doing “real work” today, you are probably spending 90% of your time (or more) in desktop mode. And if you’ve pinned your common apps to the start bar (like Win7, and I have done this) then you’ll probably never leave desktop mode. And in this case, multi-monitor works just like Win7, but slightly better because the start bar works better in Win8 (or at least it has new options I find useful).

Where the multi-monitor falls down is if you are using a mix of WinRT apps and Desktop applications at the same time.

WinRT only runs on the primary monitor, and that’s just lame. It completely prevents the use of WinRT for many business scenarios where multi-monitor is critical. I honestly don’t expect this to get fixed in WinRT v1, but I hope we don’t have to wait for Windows 9 (2014?) for this to be solved, because it is a major blocker for WinRT development in the real world.

Between the Dev and Consumer previews, they did change the way WinRT apps use the primary monitor. At least now in the Consumer preview it is possible to keep a WinRT app running on the primary monitor while using a Desktop app on other monitors. I do find though, that it is too easy for some errant Desktop app to use the primary monitor, thus making the WinRT app disappear – and this is frustrating.

Sadly it is not possible to keep the start page visible while using a Desktop app on a secondary monitor – reducing its otherwise high value as a dashboard L

To summarize the multi-monitor scenario: if you are a Desktop app user, Win8 is as good or better than Win7, because you’ll only see the start screen when you press the Windows key to launch some non-pinned app. If you are a WinRT user multi-monitor is useless. If you are a hybrid user (like me) the experience is workable, but unpredictable and frustrating.

Clearly Microsoft needs to do more work in this area.

In final summary, don’t knock it until you try it full-time on real machines. The experience overall is quite good, and I VERY much like having WinRT apps that I can use on my main computer instead of using web pages with their inferior usability and aesthetics. Given that most of my main laptop usage is in Visual Studio, Word, and PowerPoint, I find the experience with multi-monitor to be adequate, and Win8 is just as productive for those scenarios as Win7.

Windows Forms to Windows Runtime

Rockford Lhotka — Thu, 29 Mar 2012 16:39:13 GMT

Here are the slides for my Windows Forms to Windows Runtime talk today at Dev Connections.

Early findings going from Silverlight to WinRT

Rockford Lhotka — Wed, 21 Mar 2012 14:49:28 GMT

I’ve been spending quite a bit of time working with WinRT over the past couple weeks. Specifically prepping for next week’s Visual Studio Live! and VS Connections conferences.

As part of this process, I have a super early version of CSLA 4 version 4.5 that builds and (mostly) runs on WinRT. I’d done a lot of the work months ago when the Windows 8 developer preview came out, so getting it to work on the consumer preview took only a couple hours.

The only new feature I’ve added so far is support for the new async and await keywords for WinRT data portal code. I still need to add async/await support for the .NET data portal. I might refine some of my implementation, but right now I can use async/await to call the data portal in WinRT, and that’s cool!

The primary observation I want to make right now though, is that business classes created using CSLA 4 that target Silverlight will now recompile for WinRT with no code changes required. I took the entire ProjectTracker business library project and just recompiled it for WinRT and it works – unchanged.

If you want direct reuse of your business logic from .NET/Silverlight to WinRT, you should consider using CSLA 4.

Because I did add the async/await data portal support, I chose to add async factory methods to my business classes, alongside the existing .NET and Silverlight factory methods. From a porting/reuse perspective this is not necessary, but in terms of writing new code for .NET 4.5 and/or WinRT I think we’ll all tend to write these async factory methods.

In short, I added code like this:

#if WINRT
    public async static System.Threading.Tasks.Task<ProjectList> GetProjectListAsync()
    {
      return await Csla.DataPortal.FetchAsync<ProjectTracker.Library.ProjectList>();
    }
#endif

This allows the viewmodel or other presentation layer code to retrieve business objects like this:

var obj = await ProjectList.GetProjectListAsync();

No need for async callback handlers or the other messy goo from a typical WPF/Silverlight application. Of course WPF 4.5 will be able to use the await keyword too, so only SL/WP7 will still require the callback handler model when all is said and done.

Although these are early days, and I am still working through all the features of CSLA .NET to make sure they work on WinRT, it is nice to know that data binding, business/validation rules, and the data portal are all functional already. I expect to still do some work around authorization rules, and the local data portal implementation – but the vast majority of CSLA 4 functionality is already working just fine on WinRT and that makes me very happy!

Allowing a WinRT app to do loopback network calls

Rockford Lhotka — Thu, 15 Mar 2012 01:57:34 GMT

One issue I’ve encountered while building Metro-style WinRT apps on Windows 8 is the need to have my app interact with a WCF service running on the same machine.

This is obviously a common scenario for any n-tier or SOA app development. The challenge we face is that WinRT apps are blocked from calling back to localhost (127.0.0.1). The challenge and solution are described here:

http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

To find the real application name (moniker) necessary, I wrote a simple command line utility to read the registry:

using System;
using Microsoft.Win32;

namespace WinRtAppList
{
class Program
{
    static void Main(string[] args)
    {
      var reg = Registry.
        CurrentUser.OpenSubKey("Software").
        OpenSubKey("Classes").
        OpenSubKey("Local Settings").
        OpenSubKey("Software").
        OpenSubKey("Microsoft").
        OpenSubKey("Windows").
        OpenSubKey("CurrentVersion").
        OpenSubKey("AppContainer").
        OpenSubKey("Mappings");

      var items = reg.GetSubKeyNames();
      string query = null;
      if (args.Length > 0)
        query = args[0].ToLower();

      foreach (var item in items)
      {
        var app = reg.OpenSubKey(item);
        var displayName = app.GetValue("DisplayName").ToString();
        if (string.IsNullOrEmpty(query) || displayName.ToLower().Contains(query))
        {
          Console.WriteLine(app.GetValue("DisplayName"));
          Console.WriteLine(" SID:     " + item);
          Console.WriteLine(" Moniker: " + app.GetValue("Moniker"));
          Console.WriteLine();
        }
      }

      Console.ReadLine();
    }
}
}

Nothing fancy, but it helps avoid the need to dig around in the registry with regedit just to find the application moniker.