I’ve just read this on Ayende’s blog and I’m baffled! I’ve spent quite some time with SSIS, and the most frustrating part is the complete lack of ‘support’ for storing the .dtsx files in a source control system (like subversion). At first glance, everything seems to be ok, as the dtsx files are actually just xml (and thus text) which should be diff’able. However, in practice, it’s a nightmare: every time the file is changed (however small the change you made), a large part of the contents changes and even worse: the changes are clearly not local as they occur all over the place! To make it even better, someone at MS decided it was probably a good idea to store both the ‘code’ (control/data flow logic, …) and the visual representation in the same file! Now even just moving a box 1 pixel messes up the complete file.

And no, the traditional (MS) answer that you should do a reserved checkout simply doesn’t work for 2 reasons

1/ having used the ‘edit-merge-commit’ pattern most of my professional life, I just *refuse* to go back to a checkout-edit-checkin way of working (for one project, I was forced to use VSS, and, to say it nicely, I didn’t enjoy it). This is 2008 you know?!

2/ What about branches and merging? Nope, thought so!

I just cannot imagine that they do not have ‘decent support for teamwork’ as one of their top (non-functional) requirements!! Even the best product (and SSIS clearly is not, IMHO) would be close to useless if it didn’t support this!

[Update] Someone going under the name ‘longhorn’ just posted a comment that the method described here is dangerous and has led to problems with his image. And although I have used this myself with no problems so far, I do believe that it’s better to be safe than sorry. Apparently, there is a better tool to manage vmware images, called diskTool (typically found under /Applications/VMware Fusion.app/Contents/MacOS). A quick test to grow an image failed with a malloc error, but I will look into this and update this post. And the golden rule to always make a backup before you try stuff like this, still applies of course (I *do* mention this in the post)…


I’m probably not the only VMware user who has underestimated the amount of disk space he needs, only to find out a couple of months later, that the disk is filling up faster than expected. Fortunately, this is (relatively) easy to fix. That is, if you have enough ‘real’ HD space of course!

Warning: always backup your data before doing things like changing partitions etc…!  

First, download a copy of vdiskmanager-GUI (oh, I forgot to mention: I will explain how to do this on a Mac). I could only find it here (technically speaking you don’t need this, as it is just a wrapper around the VMware provided vmware-vdiskmanager command-line tool). Open this tool, and select the ‘Expand’ tab. Choose the vmdk (virtual disk image) you want to expand, and enter its desired size (6Gb in my case):

If you click ‘Go’, the vmdk file will expand to the desired size.

 For those of you that don’t have a mac: you really should 🙂 No, you can easily accomplish the same thing: on the bottom of the screen you can see the command that will be executed if you click ‘Go’. So just locate vmware-vdiskmanager (it is probably somewhere in your c:\program files\vmware directory, and run it with -x <desired size> <path_to_vmdk>. This should do the trick.  Or even better,  just download the VMware-diskmanager GUI for PC here.

  When you reboot the VM, you might be surprised to see that you hard disk in your guest OS (say, Windows XP in this case), is still at its original size! Although it might sound confusing, it is actually perfectly logical, as we haven’t changed the partition, we only changed the ‘hard disk’ the partition is residing on. One way of ‘fixing’ this is doing a complete reinstall of the system, thereby repartitioning the disk. Although it works, it’s certainly not something most of us will look forward to (as it erases all of your current apps and data).

Luckily for us, there is a much simpler way. Just download a copy of a gparted live-cd (ie a cd that is bootable). gparted is the Gnome Partition Editor, which is a linux tool to, you probably guessed it, edit partitions. Although it is linux tool, it does support ntfs, which should be the Windows filesystem you’re using (a list of the supported filesystems). And even better: since it is a live-cd, you don’t even have to install anything. Just download the iso file, and connect the CD player of your VM to this ISO:


Now the tricky part: in order to run gparted, you have to start your VM, but force it to boot from this CD instead of your HD. The traditional way of doing this, is to press F2 to enter the BIOS setup. However, under VMware, this is a trail-and-error process, as you have to be really fast to press F2 or it will just boot from the HD.


Fortunately, there is a work-around. In your .vmx file, just add  

bios.forceSetupOnce = “TRUE”

This forces VMware to enter the BIOS setup on the next boot (this setting is automatically set to FALSE). In the BIOS, make sure that your CD drive is above your hard drive, exit the BIOS and restart the VM.  

Now you should see linux booting, and gparted will automatically start-up (I selected the default setting on the first list, then just pick your keyboard and language settings from the list). 

If the disk you want to expand, is not already selected, use the drop-down to select it. Then, click ‘Resize/Move’ and either visually resize the partition, or just enter its new size:


Close the dialog  (‘Resize/Move’) and click ‘Apply’ to actually perform the partition change. After this is done, exit gparted and disconnect the iso from the CD. If necessary, change the boot order in the BIOS setup, and restart into your guest OS. In Windows, this will typically bring up the chkdsk utility. This will check your partition (which is probably a good thing). After that is done: you can start to use that newly added disk space! 

For the last couple of months, I’ve been using VMware Fusion on my (new) iMac, and I have to admit: I love it!First, I used VMware converter to create a ‘virtual’ copy of my work laptop, which runs Vista by the way (that took a few hours, but it works brilliantly). Then, I setup a few profiles in SyncBack to synchronize my ‘working’ directories (home dir, current project, …) to my external HD. After each working day, I run these profiles, so I have an up-to-date backup of my work. Now, whenever I work from home, I just use this backup to bring my virtual machine (ie copy of my laptop) up to date, and I work from within VMware Fusion. What surprised me the most, is that working this way from within Fusion, is actually more comfortable than working on my laptop! This is of course partially due to the big screen (24″ on my iMac compared to 15″ on my laptop), but I’ve also noticed that the speed is better as well (even though I gave my virtual machine only 1.5Gb of memory, while my laptop has 2Gb). And this is under Vista, so I can only assume that it’s even better under XP (performance-wise, that is).

This weekend, I found out that my Vista PC would not sync to the share on my iMac. At first, I thought something was wrong with my samba settings (as the iMac was just set up), but after I turned to google, I found that this problem is caused by an error in the OEM version of Vista. A quick registry hack, solves this:

Create the parameters key in the following location :

Then within the parameters key, create a DWORD Value named FormatDatabase with a value of 1 (hex) then reboot the machine.

(found here)

In case you were wondering, I am still alive, although bearily 🙂 My life changed a little bit on april 22nd:
Little Wonder

She’s soooo cute! Words cannot describe the feelings that went through me the moment she was born. It’s the most intense moment of my life! And the cliches are true: my wife and I are very proud, but also very tired parents 🙂

I just found out (via NSLog) that the song ‘I don’t like mondays’ (originally from The Boomtown Rats, but with a great cover from Tori Amos) is about the real-life event of a 16-year-old girl who shot a couple of children while they were playing at the schoolyard across her house. When she was asked afterwards why she did it, here only response was “I don’t like mondays”… Small detail: this event happened in January 1979! Unfortunately, some things never change…

This table lists the macros that can be used in a VS-2005 pre/post build event. I never remember these, so I decided to put them here as a quick reference for myself.

Macro Description
$(ConfigurationName) The name of the current project configuration, for example, “Debug|Any CPU”.
$(OutDir) Path to the output file directory, relative to the project directory. This resolves to the value for the Output Directory property. It includes the trailing backslash ‘\’.
$(DevEnvDir) The installation directory of Visual Studio 2005 (defined with drive and path); includes the trailing backslash ‘\’.
$(PlatformName) The name of the currently targeted platform. For example, “AnyCPU”.
$(ProjectDir) The directory of the project (defined with drive and path); includes the trailing backslash ‘\’.
$(ProjectPath) The absolute path name of the project (defined with drive, path, base name, and file extension).
$(ProjectName) The base name of the project.
$(ProjectFileName) The file name of the project (defined with base name and file extension).
$(ProjectExt) The file extension of the project. It includes the ‘.’ before the file extension.
$(SolutionDir) The directory of the solution (defined with drive and path); includes the trailing backslash ‘\’.
$(SolutionPath) The absolute path name of the solution (defined with drive, path, base name, and file extension).
$(SolutionName) The base name of the solution.
$(SolutionFileName) The file name of the solution (defined with base name and file extension).
$(SolutionExt) The file extension of the solution. It includes the ‘.’ before the file extension.
$(TargetDir) The directory of the primary output file for the build (defined with drive and path). It includes the trailing backslash ‘\’.
$(TargetPath) The absolute path name of the primary output file for the build (defined with drive, path, base name, and file extension).
$(TargetName) The base name of the primary output file for the build.
$(TargetFileName) The file name of the primary output file for the build (defined as base name and file extension).
$(TargetExt) The file extension of the primary output file for the build. It includes the ‘.’ before the file extension.

Note: this list was taken from here