Mock object framework makes refactoring difficult

Probably unintended consequence of using a mock object framework is that it makes refactoring somewhat difficult if the method signature changes, or if methods are split/combined or rearranged to different interfaces. Sometimes I am having really hard time in getting the test back to the working condition, and often don't know why I need to do what I have to do to get it fixed.

FxCop rigidness

What drives me really crazy in FxCop is that I cannot easily change the MessageLevel of the built-in rules. The XML file describing rules is compiled into the rule assemblies as an embedded resource, so the only option for me is to create a new rule assembly, copy the XML file, exclude the old rule and include the new rule. I'd rather change the MessageLevel using FxCop project files.

Misfeature of FxCop 1.36

When upgraded to version 1.36 I started getting the messages "Strong name doesn't match the reference", or "Could not resolve member reference".

The solution can be found here. What worked for me is setting AssemblyReferenceResolveMode to None.

Problem with CollabNet SVN 1.5

When I upgraded I started getting messages like this:

Failed to load module for FS type 'bdb'

Apparently bdb module is not working (or maybe they forgot to include it?) in the CollabNet distribution. I had to use the old binaries to migrate the repositories from bdb to fsfs like this:

svnadmin create NEW_REPOSITORY
svnadmin dump OLD_REPOSITORY | svnadmin load NEW_REPOSITORY

where NEW_REPOSITORY is the file path to the new fsfs repository and OLD_REPOSITORY is the file path to the old bdb repository.

BizTalk services let you expose stuff on internal network?

See http://msdn.microsoft.com/en-us/magazine/cc546613.aspx. Using RelayedHttp you can expose the web service on your internal network to the internet. But I wonder how this thing work? Is the service polling the BizTalk services all the time to check if there is any request?