I’m still waiting for Add Reference…

Yes, I know the .NET Framework is big and I’ve lots of amazing assemblies in my GAC… but why-oh-why does it take so long to populate this?

The Add Reference dialog in Visual Studio

If it t’were up to me I’d populate this in the background a few moments after Visual Studio has loaded. As it is, there’s a jolly good chance you won’t find the assembly you’re looking for until a minute or two have gone by and the list box isproperly populated.

My dodge for detecting when it’s loaded is to click on the “Component Name” column. If the little triangle appears, you’re in business:

Then you can type incrementally to get the assembly you’re after. Another pet peeve, that: why no Search… box?

 

JQuery Mobile: a cautionary tale

I’m really a server-side fellow, at home with code that can be unit tested and where the only user is a computer. I suspect like most developers I find computers more predictable than people…

I’ve just finished a quick proof-of-concept for a nice bunch of people who wanted an API for their Web site. We needed a proof-of-concept for the proof-of-concept so we thought “well, what about a mobile Web site that calls the API?”

Well, it turned out that Microsoft’s most awesome WCF Web API made the first cut of the API a matter of a couple of day’s work. I guess I had should have rubbed my chin and had a sharp intake of breath and said to my colleagues “Oh, this’ll take ages” before ‘working at home’ on a beach somewhere pleasant. But I’m not professional enough yet too honest to do that.

So I ended up throwing together a little HTML5 Web site that used a little bit of JQuery Ajax magic to get some data from the API and sling it on to a page. I managed to get the Web API to play nicely with OAuth 2 authentication through Azure ACS from JavaScript (a blog post coming on that real-soon-now). My JavaScript application would request an access token through ACS which was then validated by my API.

Job done? Almost, just need a bit of styling and we’re there.

Or so I thought.

Naively, I was planning on pasting a bit of JQuery Mobile goodness on top of the Web site to make the buttons look pretty and the listboxes format appropriately. These things aren’t too hard with regular JQuery UI, after all; and given that the whole premise of the Semantic Web is that we shouldn’t have to worry about UI concerns in our markup, all should be well.

Whoops.

It turns out that to do the fancy page-transition malarkey, JQuery Mobile processes <a href=""> tags all by itself. You need to define a bit of your page that will transition, then the JavaScript cleverness loads the new content, slides it in place, then unloads your old content.

As far as the browser is concerned you’ve not actually changed URLs, it just looks that way. Which is fine… unless you need to handle pages which include querystrings.

Like I say, I’m really a server-side guy. I’m quite happy with RESTful addressing schemes where my WCF (or, indeed, MVC) app can interpret a nice long URI and figure out what resource needs to be processed.

The OAuth 2 libraries that Microsoft make available assume, reasonably, that these nice long URIs belong to the service, and that to pass around OAuth 2 tokens and what-have-you they can use querystrings.

So my rough plan of action was to check in JavaScript if my current access token had expired. I’d then do the usual OAuth redirect if it had, which should end me back on my page with a fresh token in the querystring.

Except JQuery Mobile always stripped off the querystring. Could I get it back? No – and this seems to be an intrinsic limitation of the library at the moment.

I worked around that in the short term by using a tiny ASP.NET site to directly squirt the access token into my pages. That wasn’t ever going to be a long-term solution, but worse was to come.

I was keen on making sure that the site would actually work on a real mobile device. Not having an iPhone to hand, and not having a laptop that supports the Windows Mobile SDK, I fired up an Android emulator.

Besides being incredibly slow, unsurprisingly the emulator didn’t really play properly on Windows. Configuring an Ubuntu virtual machine for the emulator helped a fair bit and seemed much more natural; it seems most Android developers work this way.

I managed to get my application running – but no data appeared. Something, somewhere, was causing an undefined “error” to occur deep in the bowels of JQuery during the AJAX call. Stripping out JQuery Mobile… everything worked.

So it’s just as well I didn’t go to the beach: doing this in pure JavaScript on the client was clearly going to be really hard to pull off. I gave up.

Two weeks later I had a full ASP.NET MVC site running that did all the OAuth and data retrieval server-side instead of client-side — and the application ran very nicely on Android and on the iPhone. But, I can’t package that up as an app. and submit it to an app store, and there’s still some dodgy code that works around the querystring issue.

So some morals, and things to bear in mind:

  • Even today, UI frameworks can invalidate assumptions followed by other bits of the code.
  • Do a quick trial of everything before you commit to a technology. If I’d found that cross-domain data access with Ajax was never going to work easily on Android I would probably not have gone further with the 100% JavaScript solution. Better would have been to validate all of the technology end-to-end.
  • Don’t cut your fingers on the bleeding edge. While up-to-the-minute latest-and-greatest technologies like JQuery Mobile may seem awesome at first glance there’s a reason for most systems to have a version 2. And version 3.

Debugging WCF

I like Stack Overflow and the other StackExchange sites. They’re very clever: you go there in response to a Google search, and find yourself trapped into answering questions about all sorts of things.

I mean, Joel and Jeff even sent me a hat, and a couple of pens, and a T-shirt, for answering a question about… worktop surfaces. And if that doesn’t count a sign I get easily distracted from the day job, nothing will.

One thing I’ve started to notice is that plenty of people end up asking questions that can be answered by themselves by understanding a little more about the tools they already have. A good example is the WCF Service Trace Viewer.

Windows Communication Foundation is great, but it can be insanely tricky to configure, especially when it comes to the various combinations of transport security, message security and what-have-you. And while the exception messages try hard to be specific the flexibility of WCF means there are just too many places where the thing can break, leaving nothing but “The remote connection was terminated” or something similar.

Enter the Service Trace Viewer.

OK, there’s more configuration to add… but this tells WCF to spit out great hunks of detail on what it is doing. Better still, if there’s an exception, the complete stack trace appears together with detail on what WCF decided to do.

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
            <source name="System.ServiceModel"
                    switchValue="Information, ActivityTracing"
                    propagateActivity="true">
            <listeners>
               <add name="sdt"
                   type="System.Diagnostics.XmlWriterTraceListener"
                   initializeData= "c:\temp\ServerTrace.svclog" />
            </listeners>
         </source>
    </sources>
</system.diagnostics>

Put this into the configuration file on the server and the client.

Be careful that you create the service trace file where you can read it: it’ll be created and written using the account your service runs under, which generally isn’t particularly privileged.

Also be careful that the place you choose for the file is big enough. Busy services will spit out megabytes of data, especially if you (like me) forget you’ve left it configured. (You really don’t want to do this for your production instances: here, Web config transforms are your friend.)

All this is wrapped up in what personally I reckon is one of the best bits of UI visualisation I’ve seen. Yes, it’s a bit long-in-the tooth (hey, love the retro toolbar) but: can you spot where the exception is thrown here?

Yes, thought so. Double-click on the angry red link and you get all kinds of detail:

This is the Service Trace Viewer. You’ll find it in C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\ or thereabouts, or just press Start and type ‘service trace viewer’ — as you can see you’ll need the Windows SDK installed.

There’s all sorts of doo-hickeys on the tool bar and menu to help you filter down the trace information. That graphical display on the left of the information flow between client and server is awesome, but it’s the way you can see the exception trace in all its gory detail that I like.

But that’s not all. I was figuring out a really horrid issue the other day and found…serialization also works in the same way! So, if something is deserialized as null when you’re not expecting it, the Service Trace Viewer may well tell you why.

All we need next is a nice context-sensitive button that appears next to an exception in the trace labelled “Find on StackOverflow” – so we can go directly to the relevant answer…

More stuff about .NET

In my travels using .NET and other technology I find that I’m often being asked the same questions. That, and I forget stuff myself, which is probably associated with the grey bits appearing on my head.

So this blog is really my notepad for stuff I really shouldn’t forget. An electronic version of my battered old physical notepad, if you like.