My favourite xunitcontrib release yet

by Matt 9. July 2009 20:18

Yep. It’s xunitcontrib release time again, and this one’s a pretty major one. If you use the ReSharper runner, you really want to download this one.

(If you want to cut to the chase and just get the binaries and install instructions, then check out the release page on CodePlex.)

As usual, it’s a ReSharper focussed release, with improvements to the test runner and the addition of External Annotations and Live Templates. I’ll look at these last two in another post, because I want to focus on the big ticket item today – the runner.

So what’s the big news?

Well, if you’ll forgive a little enthusiastic hyperbole:

A self congratulatory twitter post announcing version independent test runner

Version independence.

Finally.

Up until now, the ReSharper test runner would run your tests with the 1.1 released version of xunit.dll only. If your test project is using a different version, such as the new CTP of 1.5, you’ll get a cryptic error message, and no tests would run.

One significant rewrite later, and it’s now using the same version independent runner API that the console and msbuild runners use.

In short, you can now use any version of xunit you like.

Cool, and very much a big deal.

But rather embarrassingly, the bit which pleases me most is a simple side effect.

One of the nice things that xunit does is randomise the order in which tests are run. And because I’m now letting xunit handle everything, we get that for free:

The ReSharper test runner running tests in a random order

(I really should have done that as an animated gif; it’s nice to see in action.)

So that’s the Big New Feature. What else is there? This is a small one, but I like it. Nested exceptions are now formatted nicer. Before:

nested execeptions formatted as a single exception

After:

nested execptions formatted as separate exceptions

And give or take a couple of things, that’s pretty much it for user-visible changes. But there are a couple of other things I want to point out though.

Firstly, that breathless Twitter post above came from a deep dive into the ReSharper test runner framework. Amusingly (after having worked on this project for the past 4 or 5 months) I finally understand how all of this works. And I’ve been heavily commenting the code to explain what’s going on. I hope it can be of use to someone else who wants to write a test runner.

(Yes, that’s right, I just made code comments a feature.)

I also have another post brewing about my developer conscience kicking in and pointing out that I could actually write unit tests for the newly restructured code. (Short version: TDD rocks + I finally get BDD.)

But it’s not all roses. There’s still no installer, and there’s truly terrible support for theory style tests (and I mean terrible. You’ll see output and exceptions, but not together. And you won’t know which test row caused the output, especially since they’re now run in random order too)

So what’s next?

Well, in part, that’s up to you. Check out the Issues on CodePlex and vote for what you want. Leave a comment here or on Twitter (via @citizenmatt or #xunitcontrib). But I really want to do something about those theory tests. I’m not sure what yet, though.

Right, that’s enough. Go and download it already.

Tags: ,

The case of the missing AutoPlay handler

by Matt 20. May 2009 18:42

Two things. I’ve recently got back from holiday, and I’ve recently installed Windows 7 RC on a 64 bit machine. My wife will attest that these are two completely unrelated things.

Until it’s time to load up the holiday snaps.

After plugging in my nice shiny new Canon EOS 1000D (a camera for grown ups!) I was slightly disappointed that I didn’t get a nice shiny new Device Stage UI. Ho hum. What I did get was the usual AutoPlay dialog allowing me to (amongst other things) import into Windows Live Photo Gallery. Tip top.

The Windows AutoPlay dialog

And then, later, I tried to do the same, but this time, by just inserting the SD card. And the AutoPlay dialog didn’t have the Import using Windows Live Photo Gallery option. I could view, or import using Windows (don’t do it, it’s rubbish) but I couldn’t import via Windows Live Photo Gallery. And I really wanted to.

This meant only one thing. Time to go spelunking in the registry.

Now, the AutoPlay registration scheme is crazy complicated. It’s all under HKLM\Software\Microsoft\Windows\CurrentVersion\explorer\AutoplayHandlers. There you’ll find a key called EventHandlers, and under here are a bunch of keys that represent the events that can cause AutoPlay to kick in.

The one I’m interested in is ShowPicturesOnArrival. Looking at the values there, we can see that I’ve got 4 values:

The list of AutoPlay handlers for ShowPicturesOnArrival

These values refer to keys defined under AutoplayHandlers\Handlers. When the ShowPicturesOnArrival event occurs, these handlers are added to the AutoPlay dialog. And under these handler keys is a bunch of registration.

Now, I get the option to view with Windows Live Photo Gallery, but not to import. So, I’d lay odds that MSLiveShowPicturesOnArrival is fine, but there’s something fishy with MSLivePhotoAcquireDropHandler.

But let’s back up a step, first.

Remember I said it was a 64 bit machine? Well, that’s important. For two reasons.

Because AutoPlay has two sets of registration. One under that HKLM\Software\Microsoft\… and a duplicate set under HKLM\Software\Wow6432Node. This key is what 32 bit applications see as HKLM\Software. And for whatever reason, AutoPlay is a 32 bit process, and so uses the 32 bit registration data.

Similarly, Windows Live Photo Gallery is a 32 bit process, and so gets installed to C:\Program Files (x86)\Windows Live\… And the registration for MSLivePhotoAcquireDropHandler for 32 bit applications points to C:\Program Files\Windows Live.

AutoPlay registration pointing at C:\Program Files\Windows Live\...

A simple change to Action to point it at %ProgramFiles(x86)% and my AutoPlay option returned.

So, to rephrase for brevity (and Google’s) sake: Import with Windows Live Photo Gallery AutoPlay option was missing on 64 bit Windows 7, because the AutoPlay handler was incorrectly registered. Go to HKLM\Software\Wow6432Node\ Microsoft\Windows\CurrentVersion\explorer\AutoplayHandlers\ Handlers\MSLivePhotoAcquireDropHandler\Action and change “%ProgramFiles%” to “%ProgramFiles(x86)%”.

A quick search later, and there were a couple of other poorly registered Windows Live items – I think they’re just localised names. I’ve attached a .reg file that will sort these out.

And it worked for the camera, because that uses the MSLivePhotoAcqHWEventHandler, which is registered correctly.

Tags: , , ,

Bart is a LINQ to Objects genius

by Matt 24. April 2009 15:57

This is why LINQ is so cool.

Bart De Smet has written an epic post with a fascinating example of LINQ queries, extension methods, polymorphism and the power of having functions as a first class citizen.

I can’t summarise the post and do it justice. Go read it. It’s lovely.

Tags: , , , ,

How to use BlogEngine.net as an OpenID provider

by Matt 16. April 2009 17:39

openid-icon-100x100

One of the nice things about OpenID is that just about anyone can be an identity provider. Indeed, that’s pretty much the point.

OpenID is just a URL. Specifically, a URL that uniquely identifies you and that you and only you have control over.

You know, like your blog address.

So let’s make BlogEngine.net be an OpenID. Turns out, it’s dead easy.

1. Go and get an OpenID

What? Did you think we’d do the heavy lifting ourselves? No, no, no. Friends don’t let friends try and implement security protocols. Leave it to the professionals.

Put it this way – I don’t even want to have to get https working as a part of my blog, let alone implement OpenID security exchanges.

I used the guide available at Will Norris’ site to help make a choice of which 3rd party to help decide which to go for. As far as I can see, the two best choices are MyOpenID and MyVidoop. Both look like very good providers, offering just about everything – attribute exchange, personas - but I went with MyOpenID because they support logging in using CardSpace (we have history).

So, my OpenID is http://mtellis.myopenid.com.

2. But I thought you said you could use your blog address?!

Of course. OpenID supports delegation. This allows me to have an OpenID URL that delegates to another OpenID provider. In other words, when I try to log in to a site using this blog as an OpenID, this blog will actually delegate responsibility to the “real” OpenID provider, MyOpenID.

This is very easy to set up. You just need to add a few lines of HTML to your blog.

First, find the help pages for delegation for your OpenID provider. Here they are for MyOpenID, and here they are for MyVidoop.

Now log onto your instance of BlogEngine and go to the settings page. Towards the bottom of the page, there is a text box labelled “HTML Head Section”. Paste the HTML from the help pages into this box, and save.

This is what mine looks like:


<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://mtellis.myopenid.com/" />
<link rel="openid2.local_id" href="http://mtellis.myopenid.com" />
<link rel="openid2.provider" href="http://www.myopenid.com/server" />
<meta http-equiv="X-XRDS-Location"
content="http://www.myopenid.com/xrds?username=mtellis.myopenid.com" />

Of course, these are my details – make sure to put yours in.

And don’t worry, I’m not showing you anything sensitive here. This information is plainly visible to everyone with a simple view source – there are no secrets here.

What this is doing is telling the web site you’re trying to log into that you have delegated your OpenID. You tell it the server it needs to speak to (http://www.myopenid.com/server) and who that server knows you as (http://mtellis.myopenid.com in my case).

3. Let’s log in to something!

The simplest was to test is to go to this checkup page, which will try and log in for you. Enter your blog address, (http://sticklebackplastic.com) in the text field and hit check. If all is well, you should see something like:

 CheckingOpenId

This shows that the checkup site, my blog and MyOpenID can all talk together properly.

Now click the “Try logging in” link.

This time, you should get redirected to your OpenID provider. Here, MyOpenID is telling me who is trying to authenticate (openidenabled.com) and prompts me for my password (or Information Card – yay for phishing resistant logins!).

MyOpenIDSignIn

Once I’ve successfully authenticated with MyOpenID, I’m redirected back to the test page, where it confirms that everything is working as it should.

SuccessfullyLoggedIn

And there you have it.

Three simple steps, and now your blog is your OpenID. Go use it to log in to all those sites with the cute little openid-16x16 icons. Go on, shoo.

Tags: , ,

Announcing xunitcontrib 0.2 – Resharper 4.5 support

by Matt 14. April 2009 17:24

I’ve just released 0.2 of the xunitcontrib project (actually thought I’d released it over the weekend. Hadn’t pressed the right button. Oops – it’s there now.)

This release is primarily to support the RTM release of Resharper 4.5 (with a couple of smaller bug fixes too). It runs just like the old one, but with one added feature specifically for 4.5 – support for Resharper’s Solution Wide Code Inspections. When this is turned on, Resharper will highlight any public methods that are not used as part of a project. And of course, test methods are public methods that are not used by any other part of a project. One implementation of the wonderfully named IsTestStuff, and we’re all sorted.

Check out the downloads page for more details, and instructions on how to install.

And if you’ve got any comments, issues or ideas, please post them to the CodePlex site or leave a comment here, or via twitter, either directly to me (@citizenmatt) or via the #xunitcontrib hashtag.

Tags: ,

Making IE8’s InPrivate Filtering sticky

by Matt 14. April 2009 15:11

Last time, we saw that you can use IE8’s interesting InPrivate Filtering feature as a slightly heavy handed ad blocker.

It’s off by default, which is fair enough, but it’s rather surprising that once you do turn it on, it’s only on for the duration of that session, and resets itself to off for the next time you launch IE.

Fortunately, there’s a registry setting. Add a new DWORD value called “StartMode” to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Safety\PrivacIE. Setting to 0 means off at startup, 1 means set to “automatically block” and 2 is set to “choose content”.

If you’ve imported an xml file that claims to be a port of one of the adblock plus lists, you’ll want to set it to 2. If you set it to automatically block, it’ll block based on the number of times a script or image has been shared – which is probably not enough control.

Tags: , ,

IE8’s poor man’s adblock

by Matt 6. April 2009 18:56

One of the more interesting-but-you’ll-never-use-it features of IE8 was the InPrivate Filtering mode – not to be confused with the tracks covering features of InPrivate Browsing.

It’s billed as a privacy guard – it can automatically block content that is being used from multiple sites. So if a script or image is included on more than 10 sites it’ll get blocked. At least, theoretically. It’s off by default (I guess not downloading shared scripts could have too much of an adverse affect on the web)

 image

This is one of those forehead slapping moments. What services dish out images or scripts that people are worried include behaviour tracking cookies that a privacy guard such as this might want to block?

Yep. Adverts.

IE is smart enough to keep a track and automatically track items that are used by more than 10 sites, but the advanced settings let you import a whole bunch from an xml file. You know, like a black list of advertising content.

neowin has an article explaining how to do this, with a link to a forum post with such a black list. And it works reasonably well. It’s not as good as AdBlock for Firefox, but it’s better than nothing.

It’s not that different to the other solutions employed to get ad blocking into IE. It’s perhaps a little less heavy handed than a hosts file, blocking actual content rather than whole sites. It will have pretty much the same impact as a proxy pac file, but without the hassle of also running a black hole proxy. And I suspect it’s not going to be as good as something like Ad Muncher or Privoxy, that (as far as I can tell) are rewriting proxies that will strip offending images out of the pages before they get to the browser. (And I don’t know what IE7Pro does. I’m too scared of it to install it. No add on should implement that many features)

No matter what, it’s nice that it’s in the box.

But it could have been nicer.

Looking at the rules xml file, you’ll notice that it’s actually an RSS feed, with a single element that contains all the rules. RSS = subscriptions. So one quick Google later, and I find window.external.AddInPrivateSubscription(URL, filterName).

Perfect! Gears start turning – a web page that calls this script API to set up a subscription to a web service which gets the latest AdBlock Plus filter, converts the black and white list sections to xml and serve the latest files – an always up to date simple ad blocking filter for IE.

The only downside is that this is beta documentation and the method is missing in action in the RTM. How disappointing.

(Of course, the real power that AdBlock Plus has is in the CSS matching and element hiding. That really makes the ads invisible. I don’t know how to port these. Perhaps they could get edited into a user style sheet? Hardly the one-click solution any more, though)

So, there we have it. With the initial design for supporting subscriptions, the IE devs must have had ad-blocking as an unspoken design goal for this feature. But they’ve pulled a Microsoft and implemented something that has some really interesting potential, but just falls short, isn’t very easy to find, and is turned off anyway.

Tags: ,

Living with BlogEngine.net – addendum

by Matt 24. March 2009 18:56

I meant this to a part of the last post, but I forgot. One of the really big things that BlogEngine.net gets wrong (really wrong) is the lack of any kind of logging, tracing or health monitoring.

This comes as rather a surprise, seeing as there is so much going on in this project – custom HttpHandlers and HttpModules, different data backends (xml or sql), asynchronous processes, etc. The potential for things going wrong is rather large, and there’s no built in way to diagnose the error – or even to know that there was an error.

And no, there isn’t a patch for this one.

Tags:

Living with BlogEngine.net

by Matt 23. March 2009 16:46

Last week, I migrated this blog to run on BlogEngine.net. While I haven't posted anything, I have (of course) been tinkering, and here are a couple of things I've noticed:

1. Speed. It's fast. I mean, really fast.

Except when it isn't.

First day after the migration, it was very, very slow. It would take upwards of 30 seconds to display a page. Firebug easily showed the problem, which was a call to retrieve a script from WebResource.axd.

All scripts in BlogEngine.net are served via an HttpHandler, js.axd. This handler minifies and compresses the files, and sets cache expiry dates. Very useful, at least for any scripts that you add to the page yourself.

Scripts that come from the asp.net controls, however, are another kettle of fish. They get served via a different handler, WebResource.axd, which pulls the data from assembly resources. The scripts aren't minified, and they aren't compressed.

So, when the BlogEngine guys wrote the module that compresses responses from the system, they also do a small sleight of hand to redirect any requests for WebResource.axd to go through js.axd. Due to the rather, um, obstinate nature of the WebResource handler, the only way to get this data is by passing the complete url (including domain name) to js.axd, which can then make a web request to go get it.

Unfortunately, and somewhat bizarrely, any request from my server (sticklebackplastic.com) to what should be itself (sticklebackplastic.com) hang until they timeout. Hence the big pauses.

On the bright side, this interception is configurable (and actually off by default), so it was easy as turning it off in the settings, and we were super-fast again.

2. I made a tweak to only output one feed auto-discovery link. Currently, BlogEngine advertises both the rss and atom version of the feed. From the Windows RSS Platform Publisher's Guide best practices section:

DON'T list the same feed in different formats

Unless you have a really good reason, it's not a good idea to have two links (or three!) that provide the same feed in different formats. It just makes the user have to pick between two things that they are not capable of distinguishing between. Pick your favorite format, and just support that.

So I just advertise a single link using the preferred format (as defined in settings). There's a patch on codeplex (#2635 - direct download) that fixes this for page and comment feeds.

3. There is a small security hole in the implementation of the metaweblog api. Uploading a file does not ensure that the file stays within the App_Data/files folder. This is mitigated by the fact that you can't upload without a username and password, but it could be used to overwrite the users.xml or roles.xml files and allow an editor to become an administrator. OK, not a huge security hole by any means, but it's nice to be fixed. Patch #2636 on codeplex (and direct download)

That patch also urlencodes the identifier used in the url that gets returned, due to point 4...

4. Windows Live Writer uploads files using just an ascii filename. BlogEngine does get enough extra information that it could create a new folder per post (based on post id), but it actually just saves the file using the given filename. Which could cause problems if two posts both use picture.jpg...

Normally, WLW gives a filename that includes a path, guaranteeing unique names for your file uploads. So what's going on?

This happens because WLW recognises BlogEngine.net out of the box. Check out the BlogProvidersB5.xml file in WindowsLive.Writer.BlogClient.dll resources. It includes this snippet:


<provider>
<id>99F71FCF-CE2D-4a6d-AB9B-FBDD453B4D97</id>
<name>BlogEngine\.NET</name>
<description>A weblog engine on the .Net platform.</description>
<clientType>Metaweblog</clientType>
<rsdEngineNamePattern>BlogEngine.NET</rsdEngineNamePattern>
<postApiUrl>
<![CDATA[
http://<hostname>/metaweblog.axd
]]>
</postApiUrl>
<options>
<defaultView>WebLayout</defaultView>
<adminUrl>
<![CDATA[
{blog-homepage-url}login.aspx
]]>
</adminUrl>
<fileUploadNameFormat xpp:if="version gte 12.0.1489.0207">{AsciiFileName}</fileUploadNameFormat>
<fileUploadNameFormat xpp:if="version lt 12.0.1489.0207">{FileName}</fileUploadNameFormat>
</options>
</provider>

Which means that when it downloads the rsd file it matches the “BlogEngine.NET” pattern in the engineName element and applies these settings to the account (which explains the weird backslash you see in the Edit Blog Settings dialog). The pertinent one is fileUploadNameFormat, which gets set to {AsciiFileName}. This is one of a bunch of substitution variables that WLW recognises to build up the filename to send when uploading a file.

Fortunately, this can be overridden in the wlwmanifest.xml file by setting the fileUploadNameFormat element to be empty. This causes WLW to use the default pattern of "{WindowsLiveWriter}/{PostTitle}_{PostRandomizer}/{FileNameWithoutExtension}{FileNameConflictToken:_?}{FileExtension}" which should be fairly deducible. And since we're now saving into folders, and the image and file serving handlers just get passed the path to the file, we really should url encode the path in the returned url.

And yes, there's a patch for the wlwmanifest.xml on codeplex too (#2637 - download link).

It also, in a quick throw away kind of way, specifies the edit url for a post, enabling the "save as draft and edit online" command in WLW. Although, thinking about it, this only supports posts, not pages...

But all in, I'm very pleased. Although I've still got to decide on a theme...

PS. The code formatting extension leaves a bit to be desired, too.

Tags: ,

Shiny new blog

by Matt 10. March 2009 19:46

Ever wiped all the data off a web server and started again? It’s kinda fun, in that cross-your-fingers-and-close-your-eyes kind of way.

I’ve just moved this blog on to BlogEngine.net, which means I’ve now got to apologise for all those duplicate entries in your feed reader (although if you’ve been reading along in Google Reader, this will be nothing new to you).

Everything seems to have gone smoothly. All the content’s still here, and all existing links, including feed subscriptions should automatically Just Work through the magic of URL rewriting. But if for some reason your feed reader doesn’t update itself, point it to the new feed endpoint – http://sticklebackplastic.com/syndication.axd.

This has been something that I’ve been meaning to do for ages, but it’s only in the last couple of weeks that I’ve finally pulled all the pieces together to get it working. Turned out to be quite an interesting piece of work, and I think I’ll write a couple of posts about what it takes – migrating content and maintaining links.

Tags:

Rel=Me

Month List

RecentComments

Comment RSS