Ever since Microsoft first introduced the “My” in every folder I have hated it. I know it’s my documents and my music, hell I paid for most of the music anyway and created the documents myself. So why do they continue this, even win Win7? If you look at the real name in the folder structure it is actually C:\Users\[username]\Documents not C:\Users\[username]\My Documents?

I know it can make some sense when you compare My Documents and Public Documents but I don’t like it that way, especially since the real folder name is in fact Document.

So I started to look into it and experimenting, searching through registry values and stuff with no luck. Searching the web also came up empty handed (just a lot of references to how you change the default My Documents folder, etc).

But actually it was much simpler that I expected, I just selected the damn thing and changed the name in properties. Renamed it to Documents and now it really make sense again. So I can have some peace.

// Håkan Reis

I have said it before and I will continue to push my theory that the next big problem area will be in configurations. The environment variables are an old habit, used extensively by the java framework but it also makes ripples in the Microsoft build environment.

I just spent some time introducing TeamCity continuous integration and build system to a company. It’s an excellent product from JetBrains that I can truly recommend. Comparing Cruise Control with TeamCity is like comparing notepad with Visual Studio. All can be done but not without inflicting pain.

Normally, setting up a new project build and test is a child’s play in TeamCity, but not this time. Apart from a few hurdles regarding subversion access and some cumbersome handling of references in the solutions there was a more evil and nasty problem.

At each build we were getting a MSB4126: “Release|BWS” configuration invalid. I searched sifted through tons of config files, project and solutions with no luck. Finally I fond the problem, it was in the environment variable Platform. For some reason this variable was set to BWS. I still have no explanation on to what BWS means (other than Beer Whine and Spirituous) and why it was set. I removed it and the system runs without a problem. After that little fix the builds executed like a charm.

The root of this problem is actually that MSBuild tries to be smart, looking at the Platform environment variable and adding what’s in it to the build. But why should it try this, what other configuration sources should I be aware of that can inflict strange behavior on my set-up? And in the name of flexibility and choice we add to this mess of configuration, every part of the system should be configurable, its always in one of the constricts of every project to day. Never hard code, always provide flexibility.

The problem is that leads paralysis as in Paradox of choice, and the way out of this is to step back, look around and start setting up some boundaries for choice. That we offer flexibility with a great sense of responsibility, and stick to a well established default behavior.

For quite a while I had a problem with setup builds. As soon as I was building I was getting errors like:

Could not create the file '<file>.tmp' 'Access is denied.'

It was driving me nuts and I had a hard time finding the solution. Finally I got a tip about KB Q329214 from a friend and in here I found the solution.

It was the Mergemod.dll that wasn't correctly registered that was the root cause. So the following had to be done at command prompt (with admin rights of course), the (x86) is there as I'm running Vista64:

regsvr32 "C:\Program Files (x86)\Common Files\Microsoft Shared\MSI Tools\mergemod.dll"

So now I have updated to SP1 and again I ran in to the same problem. This time I remembered that there was a solution so finding it was a bit easier, but if had written this post right away it would have been no issue to solve this. Mental note: Always blog about these fixes.

I always work close to the UI. Actually, most of the time elbow deep in the GUI. But I also love testing. One thing you don't want to do, is drive you GUI for unit testing purpose (there are other uses for that but not unit testing...trust me on that). So it would be great to fire events at will, or in the test code but that's not an option either. To much trouble.

Another way is to just open up the event handlers to the public and execute the code and that, in a testing sense feels a lot better. But again, event handlers is not a good thing to open up to the public, especially when you are building libraries.

I remember Marcus Widerbeg and I had a few discussions around this, how to maintain testability but retain protection. I think the following can develop further but It will do for most scenarios.

There are an attribute that actually seems to be made for this scenario. InternalsVisibleTo... This will present internal methods and fields to a specific strong named and signed assembly, that should be the unit test assembly. It's quite simple. Just change the protection from private to internal. Sign your test assembly and set the attribute in the AssemblyInfo.cs, together with the public key for your test assembly, like this:

[assembly: InternalsVisibleTo("Haqwin.Gui.UnitTests, PublicKey=00...cb")]

To find the public key, just build your solution and run the sn.exe tool like this:

sn -Tp Haqwin.Gui.UnitTests.dll

So now I can use this to unit test most of my UI code as well as automate the Function and Integration tests. Driving them almost as close as executing the actual interface.  Here is an example of testing the EventHandler for a button:

[Test]

internal void NavigateMetaDataEditor()

{

    Assert.AreEqual(DockStyle.Fill, _InitializeMetaData.Dock);

    Assert.AreEqual(DockStyle.None, _EditMetaDataControl.Dock);

    _InitializeMetaData.NextControl = _EditMetaDataControl;

    _InitializeMetaData.NextControlButton_Click(this, new EventArgs());

    Assert.AreEqual(DockStyle.None, _InitializeMetaData.Dock);

    Assert.AreEqual(DockStyle.Fill, _EditMetaDataControl.Dock);

}

The other solution to this problem, is to use reflection to get to the private methods but I'll save that for another post

This is good news: Silverlight 1.0 is now shipping. And on its way is the full C# CLR version dubbed 1.1. But even better news is the fact that what the Mono crowd did, reaaly paid off. According to Scott Guthries blog (where he announces version 1.0) Microsoft has sanctioned the 100% compatible version of Silverlight both version 1.0 and 1.1 for all Linux distributions and FireFox, Opera and Konqueror browsers. This will be done with Microsoft providing encoders and the Moonlight engine through Novell and Mono.ANother cool fact: Scott Guthries Keynote on Mix07 was built onLinux using moonlight... how about that one?

After more then 16 years with Microsoft Jim Allchin went out the main gates at Microsoft yesterday. I had fun reading his last post at the Vista Team Blog, answers alot of what he is planning for the coming years...