This question has puzzled me for quite some time. It’s so vague and fluffy at the edges. However, here is a great article that describes what it is - and I am so relieved that I wasn’t completely stupid.

The term is quite fluffy and can be described as “the things a user works with on a local computer”. Or to put it more elegantly, as Martin Woodward does, “a container that bridges the gap between your local computer (acting as a TFS client) and the server”.

This tool, MSBuild Sidekick, looks quite promising. It’s a graphical editor with which you build MSBuild project files.

I am always quite skeptical of tools that let you “draw code” that you can easily write yourself. But this tool seems to hold some very useful features. I’ll try to experiment with it when I get the chance.

This weekend I’ve been hanging around brass players, and they tipped me off about a really nerdy game - Tuba Hero - a brass version of Guitar Hero.

Great fun - although the record (108880 at the current time) is way out of my reach.

The complete error message was: “The message with To ‘[my service address]’ cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.”

We got this message when we deployed our services to the production environment. In this environment we first encounter BIG-IP and clustering. And that’s when we hit this brick wall.

The scenario was that BIG-IP had one DNS-name/Ip-address that “forwarded” request to two different servers. However when we accessed the servers with wsHttpBinding we ran into trouble and the above mentioned error message.

The strange thing was that it worked fine with basicHttpBinding, which puzzled us for a while.

Well, thanks to the excellent knowledge in the Avega Microsoft community, we got an answerer in matter of minutes.

As this post points out you can handle the problem by setting the AddressFilterMode to Any, which basic means...

We’ve just solved a tricky thing in our project. We still don’t get what is happening under the covers but now we’ve got it to work.

When we ran our unit tests (99% code coverage have I mentioned that :)) in the Visual Studio IDE everything was green and nice. However when the tests were run in our build script they failed with some strange reference problem. The same thing happened if we ran the test local via MSTest.exe.

OK - we then found the following post that showed us the same behavior. The solution is to in the .testrunconfig-file for the test configure DeploymentItems that points to any additional reference you need for your test to run.

Via the Test->Edit Test Run Configuration-menu item you can easily add files and folders.

I have a Dell Precision M70 (yes - its old now but it was great when I got it, alright). Since I reinstalled the operating system I have experienced that the operating system is shutting down my wireless network card.

I knew that there were a setting for it somewhere - but I just couldn’t find it… Very frustrating. But here is how to do it in Vista:

Go Start -> Computer and right-click and go Manage. This will open Computer Management. Select Devices and then Network Adapters and choose your network card, right-click and choose properties.

Now the following dialog appears and you can un-check the box that allows your operating system to shut-down the network-card.

Easy, wasn’t it  ;)

As I told you a while ago I am since a while back blogging for Avega Group as well as here at www.marcusoft.net. I feel really honored that Avega wanted to have my random ramblings at their site.

The new site for Avega is now live and you can find the blog here. My own personal Avega blog can be found at http://blog.avegagroup.se/MarcusHammarberg/.

There are some really cool photos also. Avega uses a great photographer that always delivers such great things.

Alright - the http://blog.avegagroup.se/MarcusHammarberg/ will of course mostly contain technical stuff. But I’ll post everything here first…

We have been chasing a nasty bug for a few days now. It actually has to do with all the technologies above.

The thing is that we have a Oracle stored procedure that returns a RefCursor. The stored procedure is actually just doing a simple SELECT from our system value tables. We are using Enterprise Library to call the stored procedure. We are using the command ExecuteReader. And here the funny business starts.

For starters, the stored procedure declares an OUT RefCursor, so we are adding a RefCursor parameter to our Oracle stored procedure command object. But when our ExecuteReader is run, the command is NULL (DBNull).

Furthermore, we ran into some connection problems since we had loads of connections hanging in the database after running our unit tests (that made many calls to said stored procedure).

After a lot...

Today I really harvested the full effect of our inclusion of Aspect Orientation, by using the Policy Injection block of Enterprise Library.

And I must say; I am in love! I hereby solemnly declare that I never will use any other way to implement non-functional requirements, as long as I have a say in the question.

Why, you ask? Because all other ways are stupid! (I’ve picked up some Linus Torvalds style) Don’t code - configure!

Here is the example that really convinced me: With a quite simple (very simple if you use the configuration tool for Enterprise Library) configuration block, I got the results from all the methods in a certain interface (system values from the database) to be cached.

Do you hear me? NO CODE did that! And it’s so beautiful that my eyes are filled with tears.

Here is my configuration:

OK - today we found out why we are building 650 builds each week…

As part of our build process, we are checking out (and in) a version-file and a SolutionInfo-file. The problem, however, lies in that we have a build trigger that starts a build on each new check-in. So each build triggers a new build that triggers a build that … you get the picture.

I have created build processes before with the great build server CruiseControl. In CruiseControl you have a configuration option called ExclusionFilter that solves this problem. You can tell CruiseControl not to trigger builds from certain users/files.

This option is not available for us TFS Build users. But there is still a way around this. It’s a bit of a hack and is described here.

The solution is to set a certain check-in comment for your check-ins that shouldn’t trigger...