One of the main trouble spots I came across was with the XslCompiledTransform class, which replaces the new obsolete XsltTransform class.  This class, new to .net 2.0, performs way faster because it actually loads and compiles the xslt into MSIL.  We rely heavily on xslts in our applications, with almost all html being defined in xslts instead of embedded inside app code. I’ll go into detail on this in a future post.

Using the profiler, I was noticing that loading xslt into XslCompiledTransform was taking a good 30-35% of the processing time for a page, since it is actually compiling the xslt on the fly. The solution? Either use caching, or make the compiled transform static, so that it reuses the same one instead of constantly recompiling it.

You may find my notes on httpcontext.cache helpful.

Rejoice will convert your Joystick or P5 Glove into a MIDI controller. Up to 1000 Button/Axis/POV actions on your joystick can be mapped to MIDI controllers. Download the installer here.  Please note that I’m only hosting this freeware software as a mirror. Although I’ve personally used it, I don’t know much at all about its internal workings. Unfortunately I don’t have access to the documentation that was also on the now defunct original site.

if (HttpContext.Current.Cache[“myObject”] != null)
    Control ctrl = (Control) HttpContext.Current.Cache[“myObject”];

This seems foolproof: first you check if the object is in the cache, and only retrieve it if it is. The problem is that the Cache is accessed in a multi-threaded environment, and so there could be potentially thousands of separate web requests happening at once for this object, with some of them perhaps clearing the cache and re-adding a new copy. It’s entirely possible for the cache to become null in the microsecond between checking for existence and actually retrieving from it.  To make this matter worse, it’s a bug that will likely not be caught until on production with heavy traffic, and is very hard to duplicate effectively.  So the simple way to handle this (without messing with locks) would be to first retrieve into an object, check that object for null, and then cast it:

object cachedCtrl = HttpContext.Current.Cache[“myObject”];
if (cachedCtrl != null)
    Control ctrl = (Control) cachedCtrl;

Always Set an Expiration on a Cache

In order to avoid the dreaded OutofMemoryException, you should make sure you are not loading too much into the cache. One way of doing this is to place a rolling timeout on your cached object. That way if it’s not being used frequently it will automatically be discarded to free up memory for other activities:

HttpContext.Current.Cache.Insert(“MyObject”, myObject, null,
                            System.Web.Caching.Cache.NoAbsoluteExpiration,
                            TimeSpan.FromHours(1));

If you are experiencing OutOfMemoryExceptions because of this sort of situation, a quick fix would be to clear the Application Pool for that application in IIS. You can then configure the app pool to automatically recycle the working process after it has consumed too much memory.  Open up IIS Manager and right click the associated Application Pool:

Obviously this should be considered a temporary fix until you are able to test and push out a new version of code with more long term fixes.

On HttpContext and NUnit

Working directly with HttpContext makes writing Unit Tests difficult. When NUnit runs, it doesn’t have the same ASP.NET HttpContext to work with, and thus will throw an error when you try to access it in your code.  Instead of accessing HttpContext directly, lately I’ve used a facade-type object that mimics the interface of HttpContext.  If the context is available, it returns that, and if not, it returns simple collections for storing cache etc. I just found an excellent implementation by Phillip J Haack that does this better than my code, so I will direct you there instead of posting my version:  Simulating Http Context For Unit Tests Without Using Cassinni nor IIS.

I was one of the lucky ones to score a new Nintendo Wii a week after it came out, and have been currently wasting too many evenings on Need For Speed Carbon of late (wii-mote as steering wheel rocks). The wii-mote is truly a lovely piece of hardware that demands to be assimilated to other uses. Hacker-bees over at wiili.org are working away on this as we speak. Since it uses standard bluetooth to communicate, it’s entirely possible to use it on windows as an infrared mouse pointer, as a system to transfer your miis, or as a midi drum machine.

I’m particularly interested in the idea of the wiimote as a controller for audio software, much like the link for the midi drum machine above. In my ’spare’ time (hah), I’ve been playing around with Ableton Live, audio software that allows you to do live sampling and looping. My end goal here is to supplement my band’s live performances with some tasteful instrument looping and ambient samples. I run my bass and a microphone through this software and can build up whole compositions in real time using loops (or at least that’s what I’m working towards mastering).

At some point I’d like to be able to use my wiimotes in this sort of live music performance venue. One problem with looping percussion instruments on stage is that the mic picks up background noise and degrades the quality. Using the wiimote as a shaker or virtual drumstick would allow you to avoid that ambient noise buildup, and still have the performance quality that crouching over your laptop on stage doesn’t convey.

The link for the wii drum machine above isn’t quite there: he’s just mapping buttons to certain drum samples, but he isn’t taking into account the velocity of the movement of the wiimote. Midi is not only an on/off signal, but also allows for ‘velocity’. That’s how an expensive electric piano will respond with different volume depending on how hard you strike the keys. Without taking into account the velocity of movement, you aren’t going to be able to duplicate realistic percussion.

Check out this video of someone actually using his wiimote as a controller for Ableton live.  This is really close to what I’m talking about, although he doesn’t provide any information on his approach. Note how by twisting and tilting the wiimote, he is shifting around the settings on an audio effect filter to make that modulation sound.

I actually have a usb gamepad hooked up to my laptop and have been using it as a controller for Ableton Live already. It works great, and running at $35 it is both way cheaper than dedicated midi controllers and has bonus novelty effect. I’m using a combination of Rejoice and MIDI Yoke for this (let me know if you would like more information on how that is done). 

Unfortunately, it’s going to take some more time for me to get my Wiimote working: first I need to get a bluetooth adapter for my laptop! I’m sure by the time I do that, those wiili hacker-bees will have figured it all out.

On a related topic, someone has also done a great job making the Nintendo DS into a wireless midi controller, although it requires some hard-to-find hardware to hack homebrew on to it. Check out the video on that page where he uses it as a virtual keyboard, and how he can ‘bend’ notes like a guitar.

    <MSBuild Projects=“MySolution.sln”
           Properties=“Configuration=Debug“ ContinueOnError=“false“ />

I did a lot of research on MSBuild in the last month, and it was amazing just how long it took me to realise that MSBuild will parse .sln files for you.  I guess it was just too obvious (in other words, it says it right there if you go msbuild /? ).

You could do this from the command line as well instead of using devenv.exe: 
msbuild mysolution.sln /p:Configuration=Release

Solution files are not proper MSBuild scripts (unlike vbproj and csproj files), but MSBuild can still work with them. I recommend this excellent article by Sayed Ibrahim Hashimi if you want to go a bit deeper into using the solution file in MSBuild.  He talks about generating a proper .proj file from a solution file with a custom task, and then working with that for any other customization you require in your build process.

1. It emphasizes just how little you should be trusting any client-side validation for ensuring the security of your web application. In other words, don’t be trusting anything that is submitted to your server-side just because you are doing it in a hidden ajax method or something.
2. It highlights what I consider to be pretty much the most important tool in my web application toolbox: the Firebug Extension for Firefox.

This tool is not only a debugger for javascript; it also allows you to completely dissect a page’s html structure, css and javascript in seconds.  No more combing through View Source in order to figure out how a page is laid out, or trying to find what css is acting on what. Just hit F12 in firefox to open the Firebug panel and click the Inspect button. 

There’s a tonne of things you can do with this extension, but go install it and come back here and I’ll show you a fun little trick.

Are you back?  Ok, try this: click F12 to open the firebug panel and hit the inspect button.  With this you can see the shape of all the DOM elements on this page. Actually click on an element and you can do things like browse through the html tree, view any css styles acting on it etc etc.

Now you know what the html structure of the page looks like. Note the id for the top header of this page is called ‘header’.  Now we’ll take advantage of the fact that this blog uses the scriptaculous library in order to make the header on this page disappear right in front of you.  Click the Console tab in Firebug.  At the bottom, you can enter in arbitrary javascript and it will run in the c