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 way is 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 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...

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 that is called ExclusionFilter that solves this problem. You can tell CruiseControl not build trigger build from certain users/files.

This option is not around for us TFS Build users. But there are 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...

This might be a nobrainer for most of you but I have to put it up here since I’ll have to run back to it from time to time.

Here is how to run “any” program as another user, without any installs or modifications:

1. Type cmd in the Run-box of the Start-menu
2. Type the following command: runas /user:[domain]\[user] [program] Of course, exchange [domain], [user] and [program] to the things you’ll need. Example to start Management console as MARCUSADMIN: runas /user:MARCUSOFT\MARCUSADMIN mmc
3. Type the password of the user you want to run under
4. Viola! You are running the program as the other user.

Another great finding in MSBuild for me recently is the use of the XMLMassUpdate task of MSBuild Community Tasks.

For quite some time now I have always kept a separate .config-file for each environment. Even though I always has gone “hmm… but wait a while here… 90% of this file hasn’t changed from the last environment…”.

But you don’t get the time to investigate always. But now, again after some thoughtful input by colleagues, I noticed the XMLMassUpdate.

With it you can easily keep a file with the changes for each environment and then let your build script generate the right version for the environment the script is building. This means that you only need to keep the differences (deltas I think it’s called in formal speak) of the different files. Great!

Here is an great article describing how to use the...

I’ve been generating documentation from our XML-comments with Sandcastle for quite some time now. It has worked alright but there were some stuff that really annoyed me, I though that I had to put up with it. But this is the beauty of my line of work comes into play… all of a sudden we’ve got a new team member. Christer Cederborg from Avega (of course) - a great guy and very knowledgeable in things like build scripts and other. And you get to learn from each other. This is why I am in this business - sharing and knowing. OK - Christer told me that you can use something called a response file to send commands to Sandcastle. The response file is in fact just the parameters you would send to Sandcastle the command line, but in a file. This made us go...

My questions in an earlier post was promptly answered by Mark A Williams in a great way.

So what he say pretty much confirms what I thought. Although associative arrays are great way to “bulk in” data to the database but when it comes to returning data the array-way might not always be right.

Since you have to allocate memory for the array and size of each element in the array the associative arrays are best suited for situations when you know the size of the data that is being returned. Not that often in my experience. In other cases you’ll better off with a plain old DataReader.

So now I know - thanks goes to Mark A Williams.

The Swedish guru of Scrum Henrik Kniberg, has produced some great stuff… yet again. Here you are:

• Video and slides for “10 ways to screw up with Scrum and XP”. Got the merge-slide thrown in my face of a co-worker since I have great reluctantancy against branches… But I sure want to be able to manage them in a nice way - haven’t seen one yet though…
• Scrum checklist - here is a truly great one page document to get all your stuff in the right shape before starting doing Scrum.
• And of course Scrum from the trenches. Everybody must read this! Even, or maybe especially, if you hate Scrum.

I have written about this before but I’ll make a short recap since it has to do with some quite interesting stuff in Oracle.

With ODP.NET you can harness the full power of Oracles features such as for example using Associative Arrays to bulk stuff into the database. We are using this feature in my current application, since it will handle big loads.

OK - so far so good. I cannot understand two things and we have now involved the full brainpower of the team and still are scratching our heads. It actually boils down to two properties on the OracleParameter-class; Size and ArrayBindSize.

• The Size-property should be (in the case of using associative arrays) set to the number of elements in the array. The strange thing though is that the value of the property must be set for...

Here is a cool site with MSBuild Recipes. I might post to it from now on. Sharing is knowing.

For some time now people has been turning to me at my customer for answerers regarding TFS Build. I have learned a great deal from that but sometimes I feel like I haven’t made sure that I understood the underlying thought from Microsoft.

One of those areas is that the TFSBuild.proj-file is not your ordinary MSBuild-file. Or rather; it’s is but is run by Team Foundation Server and you get to configure it and it’s properties. This is what I though and I was actually right. Phew!

There are some properties and targets that you can override in order to customize the build process. You can think of these targets like events being fired, and you can hook into them and customize their actions. And this is quite easy once you know how.

But then I often get the question; “Ok - what can I configure”. I haven’t...