I have a Dream …

So I finally got around to upgrade my hardware in my Dreambox from an old Maxtor 40GB harddisk to a nice and smooth Samsung Spinpoint HD400LD.

So on big effort is to backup all the movies from the in the meantime completely stuffed Maxtor. So the easiest way was to attach my notebook to the box (via a crosslink-cable) and copy everything to my harddisk.

Next step (after the Spinpoint was built in), was to “recover” all the data back to the new disk. Unfortunatly I had to experience a major performance-decrease. While I got about 7MB/s reading from the box, I only get about 4,3MB/s writing to the box … 🙁

Well, it turns out, that is behavior is be design 🙁 and is not subject to change. So I will have to spend a night or so copying everything to the box …

Sandcastle released

Finally! On Janury 16th Sandcastle was released!! So good bye CTP and hello Release!

Make sure to grab your copy on codeplex!

A big stop forward is also, that there are some examples to get your help-doc started from within MSBuild. Previously I used some MSBuild scripts, which are also available on codeplex, but since they were tailored for a specific CTP (the march 2007 CTP), they didn’t work with the last november CTP anymore.

OK, so I’m looking forward to get all my code documented :); a quick test on my recent project at least showed no errors on the first run … that’s quite impressive!

Mounting VMWare's shared folders in a Linux-Guest

I do like the feature of shared folders in VMWare a lot, since this takes away the hassel of setting up networking and an FTP-Server or Samba or stuff, just because you want to copy a couple of files.

Well, you could also use the Drag’n’Drop feature of VWMare, which is also very nice, but it’s quite slow on big files, and might not always work right away. Also you’ll be left with a whole bunch of temp files, which made recenlty the 2GB mark on my temp-dir 🙂

Well, so since I’ve been using shared folders for quite some time on Windows-Guests, it was just yesterday that I wanted to use them on a Linux-Guest. On Windows you’ll find in the network neighborhood a machine called .Host, which has a couple of shares (one for each shared folder). But how about Linux? After searching for a little while, I found them … in /mnt/hgfs/ you’ll find the shared folders mounted!

Implementing a Singleton in .Net

Well, the singleton-pattern has been around for quite a while, and I think it’s one the my most used (and for the longest time applied) patterns.

So far I implemented the singleton like this:

class Singleton
{
private static Singleton _instance;
public static Instance
{
get
{
if (_instance == null)
_instance = new Singleton();
return _instance;
}
}
}

This did the trick so far, but recently I stumbled across a MSDN article that cleared a better and much shorter way to create a singleton:

sealed class Singleton
{
private Instance() {}
public static readonly Instance = new Singleton();
}

Delete Subversion revision

OK, it had to happen sooner or later … some bone-head delete the trunk folder and committed this to the central repository!! Of course this happend 10 minutes before the final build of the first public test-release …

OK, so what to do now? First of all, check out a previous revision. OK, did that. So now check everything looks fine, everything builds just fine … OK!

So how to commit that to the repository? The repository know I checked out revision 125, but the latest revision is 126. So what next?

First make a backup of the repository (well, it’s kinda broken, but you never now what could happen next!!). Then dump everything up to revision 125:

svnadmin dump -r1:125 myrepo > my.dump

then create a new repository and load the dump:

svnadmin create myrepo
svnadmin load myrepo < my.dump

This way you’ll end up with a nice and clean repository, which is up-to-date with revision 125 … and the bogus revision 126 is gone!!

This really made my day!!

LC.EXE exists with an error

Today I experienced some strange error with LC.EXE of Visual Studio 2005. So far my project was always building just fine, but all over sudden I was getting an error, that LC.EXE was existing with code -1. So what the heck is that supposed to mean?

Well, after checking everything in my code, and what I did in the last couple of days.

So one or two hours later it came to me … the license.licx was referencing to an assembly that did not exist (anymore). After cleaning out the invalid assembly every worked like a charm again.

Patching virtual, cloned SQL-Servers

Well, since the existence of the cloned sheep Dolly we all knew, that cloning isn’t just a piece of cake! Well, here is another one:

Today I tried to update one of my development-servers to SP2 of SQL-Server 2005. Everything went just fine … really everything? Nope, the database-engine, the olap-engine and the reporting-services-engine just would not update. All I got was a snappy error Error 29528. The setup has encountered an unexpected error while Setting Internal Properties. The error is: Fatal error during installation..

OK, some time later I figured: it had something to do with me cloning my vmware-machines to save some time. Well, now I came kicking back at me!! But surprisingly Microsoft holds the answer in Knowledge Base article 925976.

Uninstalling VMWare-Tools

After fiddling around with my latest VM running on my ESX server I experienced, that I could not remove the installed and by now outdated VMWare-Tools.

This is most likely because I just imported a VMWare from VMWare Workstation into the ESX 🙁

OK, but there is hope!

Removing the info from the registry worked the best for me. Search for vmware tools.msi in the registry. Delete the subkey similar to [HKEY_LOCAL_MACHINE\Software\Classes\Installer\Products\8E24D35BB278E034284D0860A513CF1E] that appears in the search with the vmware tools.msi info inside. If you’re paranoid export the subkey to a reg file first, just in case.

After this procedure you should be able to remove the existing installation of VMWare-Tools and install the tools supplied by the ESX.

Versioning Assemblies with MSBuild

OK, so I try doing more with MSBuild … like: bumping the version number of my assemblies 🙂

So far so good – so let’s get startet. First of all you need to grab a AssemblyInfoTask extension for MSBuild. Just install it and you’re all set.

Next you have to modify your *.csproj file. Just add:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\AssemblyInfoTask\Microsoft.VersionNumber.Targets"/>

to the end of the file. OK, this could already be all. But wait – what are all those errors in my newly build?

First I use subversion for source-control, so I have an addition AssemblyInfo.cs somewhere in my .svn folder-structure. This is not working with the AssemblyInfoTask :(. So navigate to your ‘$(MSBuildExtensionsPath)\Microsoft\AssemblyInfoTask\Microsoft.VersionNumber.Targets’-file and edit it (with notepad or whatever). Then lookout for the itemgroup defining the files to process and modify it to exclude any .svn folders. This could look like this:

<!-- The items that get processed by the task -->
<ItemGroup>
<AssemblyInfoFiles Include="**\AssemblyInfo.*" Exclude="**\.svn\**\AssemblyInfo.*"/>
</ItemGroup>

OK, for now you’re set – it compiles!! At least kinda. So next you’ll get some error about the version-number not being correct. Well no error without a fix :). There have been quite some discussions about this problem and a lot of various fixes. Well, Neil explains in his blog about why this is, and makes the point “So, I’m sad to say, we will be stuck with 16-bit build numbers forever.”. So this means no cure for this error.

OK, for me I just wanted to control the version number of my assemblies from outside visual studio. So I want to fix the version number. So I though adding the properties:

<AssemblyBuildNumberType>NoIncrement</AssemblyBuildNumberType>
<AssemblyFileBuildNumberType>NoIncrement</AssemblyFileBuildNumberType>

would do the trick. But far from right. I still would get at least incremented revisions. Looking at the code I noticed that:

<AssemblyRevisionType>NoIncrement</AssemblyRevisionType>
<AssemblyFileRevisionType>NoIncrement</AssemblyFileRevisionType>

would solve my problems. So my complete PropertyGroup looks like this (with a version number of 2.1.1.1 for my Assembly, and 1.0.0.0 for my File-Version):

<PropertyGroup>
<AssemblyMajorVersion>2</AssemblyMajorVersion>
<AssemblyMinorVersion>1</AssemblyMinorVersion>
<AssemblyBuildNumber>1</AssemblyBuildNumber>
<AssemblyRevision>1</AssemblyRevision>
<AssemblyRevisionType>NoIncrement</AssemblyRevisionType>
<AssemblyBuildNumberType>NoIncrement</AssemblyBuildNumberType>
<AssemblyFileRevisionType>NoIncrement</AssemblyFileRevisionType>
<AssemblyFileBuildNumberType>NoIncrement</AssemblyFileBuildNumberType>
</PropertyGroup>

You might notice that I don’t set the Assembly-File version in the PropertyGroup. This is still managed from visual-studio (you don’t have to understand why I would wanna do this).