Windows Media Center remote control icon

I have just created a Windows icon (.ico) file of the Windows Media Center official remote control.

It contains resolutions from 16x16 all the way up to 256x256.

Download

Windows Media Center remote icon by Tom Fanning is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.

Hiding your Boot Camp partition icon from the desktop in OS X

I found this simple tip for hiding your Boot Camp partition's icon on your OS X Leopard desktop here, but that blog makes a meal of something very simple. So here it is in its simplest form.

Essentially you need to run SetFile from the developer tools and mark the mount as hidden:

/Developer/Tools/SetFile -a V /Volumes/Untitled (or whatever your partition is labelled)

then

killall Finder

to make the change take effect.

To reverse, simply use a lowercase V instead of the uppercase in the command above.

Obviously you need the Apple dev tools installed for this to work, but chances are if you're the kind of person who wants to do this, you'll have the dev tools installed (they're free).

Windows 7 on Apple MacBook

I've just installed Windows 7 on my MacBook, and I thought I'd do a post on my experiences so far.

The MacBook is a mid-2007 Core 2 Duo 2.0GHz with 2GB of RAM and a spare 60GB Toshiba hard drive in it. It has the Intel 945 integrated graphics card.

The Windows 7 build is the PDC2008 release, build number is 6801. I'm using the x64 build.

I am now up and running just fine after a few minor problems.

First off the 6801 build has the same issue with EFI that the Vista MSDN ISOs have, which causes Apple machines to not be able to boot from them (giving instead a "Select CD-ROM Boot Type" message on boot). This is well documented. The solution, in a nutshell, is to mount the ISO and copy the contents (and the boot information) on to a fresh DVD. UltraISO's default burn settings work just fine for this, very simple.

After that, Windows 7 installed absolutely fine, including picking up the available wireless networks during the last stage of setup. Aero was also working out of the box, already set to the correct 1280x800 screen resolution.

At this point the machine behaved exactly like Vista SP1 does without Boot Camp drivers installed. I went ahead and installed the Boot Camp 2.0.1 drivers, using the BootCamp64.msi file in the Apple folder in the archive to bootstrap all the different driver installations, rather than installing all the drivers seperately as I have done in the past on Vista x64.

They didn't all go on cleanly, but after a reboot I installed the Boot Camp 2.1 update from Apple. This resulted in a completely clean Device Manager, all hardware working, working really smoothly. I would rate the experience so far as better than Vista SP1 RTM.

I will update this post if I come up against anything in the next few days, but for now, very happy.

T-SQL EXEC and Table-valued Functions

So I've spent all day building an SQL Server table-valued function, which happens to include a bit of dynamic SQL called by 'exec sp_executesql'. 5.30pm comes around, I think great, I'll be able to test this baby before I go home.

Run the project - bam.

---------------------------

Appointment Stats

---------------------------

Only functions and extended stored procedures can be executed from within a function.

---------------------------

OK   

---------------------------

Turns out you can't use EXEC from within a table-valued function. Time for a rethink...

Building on my laptop

I normally do most of my development from my office desktop, which is (obviously) well connected to the dev server with source control etc on it. Well today I'm in Wales on my MacBook, trying to do some coding on a quiet afternoon. I was wondering why my builds were being a bit sluggish, and realised that I had references to third party assemblies stored in a SharedAssemblies share at the other end of my VPN link back to the office.

Turns out Visual Studio 2008 frequently reads these DLLs from wherever the reference points to (proved by wiresharking the traffic), which explains the crappy performance.

Solution of course is to have a folder on the local machine for third party libraries, but this could easily get out of sync across multiple developer machines with library version upgrades etc.

Anyone got a decent solution to this problem, or any ideas? I was thinking perhaps a logon script for developers to sync the shared assembly folder with robocopy, but that doesn't solve the problem when I'm away from the office - I'd still have to manually run the script once in a while, plus my laptop is (deliberately) not on the office Windows domain. Hmm.

Any insight into how you solve this challenge would be really appreciated.

Compiling C# code in a RAM disk

Today I was doing some coding where I needed to do a bit of coding, a build, more coding, another build etc very often, so I thought about ways to speed up the build.

One thing I came up with, given that the build seems to be a pretty disk-intensive operation (although one CPU is generally pegged to 100% during a build), was to try doing the build on a RAM disk, to remove any potential hard drive bottleneck.

Without going into too much detail, I found that a full build from the RAM disk took on average 22 seconds, and a build from the hard drive took around 27 seconds. This is just 5 seconds difference, or a 19% performance improvement.

In my case I didn't feel like the extra effort was worth the performance gain, however for a large project, 20% could mean a minute or more, which if you're doing any more than a few builds per hour this could soon add up.

The environment I tested on, incidently, is Windows XP Professional, Visual Studio 2008, and a 15-project Windows Forms solution, roughly 100k lines of C# .NET 2.0 code. The machine is a Dell Poweredge SC440 with 2GB RAM and an Adaptec SATA RAID card set up with two drives in a RAID 1 (mirror) configuration. The testing was pretty unscientific - but the results were consistent enough to prove my point.

Something I might consider is striping the two 250GB drives together in RAID 0 to see if that gets me a decent performance increase over the RAID 1, but somehow that seems like a lot of unproductive time where my main box is out of action, just to try and get a bit of extra performance.

In a nutshell, in my opinion, don't bother trying to compile code in a RAM disk unless you have a really big solution and do very frequent builds.

Building VS2008 project located on UNC with reference to web service from command line

Apologies for the long post title, but I guess it reflects the nature of this edge case, and there's no documentation anywhere that I can find on this.

When doing a command line build of a Visual Studio 2008 solution located on a UNC network share, with a reference to a web service, you may find you get the following message:

SGEN : error : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
If you copy the solution to a local drive and run the command line build again, you'll find it works ok.

The (failing) command line being used by our continuous integration system is:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com" \\srv-dev\integration\Utils.DefectHandling\workingdirectory\Utils.DefectHandling.sln /build Release


This only seems to affect solutions that contain web references, as we use exactly the same naming conventions on loads of other projects in CI.