The complete error message was: “The message with To ‘[my service address]’ cannot be processed at the receiver, due t 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...

This might be a no-brainer 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. For 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. Voila! 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 thought 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 around the use...