Reviewing changesets with a large number of files that haven’t changed can be a significant waste of time. Sliming changesets down to only changed files is a great idea before checking in files.

I have previously been doing this manually which in itself is time consuming. Fortunately the TFS power toys package comes with a handy utility to automatically uncheck out any files that haven’t changed. Running TFPT.exe uu /r will do the trick. Running up an instance of the Visual Studio command prompt and entering in this command can also be a hassle. Thankfully Visual Studio makes this easy with the support for external tools.

I am putting together a sync framework provider and have come across some issues that do not appear to be documented. I’m adding custom fields to the item metadata so that I can store additional information for items that are synchronised with another provider. To do this, you define the custom fields for items as part of initializing the metadata store. The tricky thing is that it isn’t clear what data types are supported and how to correctly use the data types that are supported.

I have the following initialization code.

I have been using nDumbster on a project to unit test sending emails. It has been an interesting experience working with this little tool. It is a great product but has been out of development for a while and has some issues.

The more I started using nDumbster in test runs, the more I was finding that it wasn’t working so well. I was consistently getting the following exception:

Test method [TestName] threw exception:  System.Net.Mail.SmtpException: Failure sending mail. —>  System.IO.IOException: Unable to read data from the transport connection: net_io_connectionclosed.. System.Net.Mail.SmtpReplyReaderFactory.ProcessRead(Byte[] buffer, Int32 offset, Int32 read, Boolean readLine) System.Net.Mail.SmtpReplyReaderFactory.ReadLines(SmtpReplyReader caller, Boolean oneLine) System.Net.Mail.SmtpReplyReaderFactory.ReadLine(SmtpReplyReader caller) System.Net.Mail.CheckCommand.Send(SmtpConnection conn, String& response) System.Net.Mail.MailCommand.Send(SmtpConnection conn, Byte[] command, String from) System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, SmtpFailedRecipientException& exception) System.Net.Mail.SmtpClient.Send(MailMessage message) System.Net.Mail.SmtpClient.Send(MailMessage message)

There is an issue with mocking IUnityContainer from RhinoMocks. A BadImageFormatException is thrown when you attempt to create a mock or a stub of IUnityContainer. For example:

I need to output some debug statements from a PolicyActivity as I’m having some issues with running a workflow from a unit test. Adding some Debug.WriteLine statements to the rule set seems like a good idea given that I am not getting the WF designer step through experience from MSTest. I thought about whether CodeDom checks for the Conditional attribute before it invokes a method.

CodeDom evaluates the xml rules and executes the instructions in C#. At compile time, native C# is striped of any method call that is decorated with a ConditionalAttribute that does not match the additional compilation symbols of the build configuration. For example, the Debug.WriteLine statement is decorated with Conditional(“Debug”) attribute so any calls to this method in a typical Release build configuration will get stripped out as the Debug compilation symbol is not defined. What about CodeDom though?

As expected, CodeDom does not check the ConditionalAttribute marker on methods it invokes. As such, debugging methods are evaluated and invoked at runtime regardless of the build configuration.

I have a custom WF activity that uses a type converter to convert from a source object to a destination object. I added an ActivityValidator to the activity to check that the TypeConverterType property specified to use for the conversion derives from TypeConverter.

The code originally looked like the following.

I have just released a new version of ReSharper Plugins. This version updates the identification and conversion of value types in cref xml documentation references and now supports ReSharper 4.5

Get the goods here.

I hit an interesting situation the other day. I had a WF library that I wanted to unit test and I had to add workflows to the unit test assembly to be able to test some of the activities. The unit test project template doesn’t support WF but this is easily fixed by hacking the project file. The assemblies were strong named and there were some internal classes that I was also testing using the InternalsVisibleTo attribute.

All of a sudden the compiler complains that the unit test assembly isn’t signed and the InternalsVisibleTo attribute is not valid. The compiler message clearly indicates that the unit test assembly has not been signed and has null public token. The compiler error looks like this:

Friend access was granted to ‘MyAssembly.UnitTests, PublicKey=0024000004800000940000000945000000240000525341310004000001000100E5D06B6A34E0EBE7386CA8C177B3EEDA66802357F74D8F5D419BF3623C9CE4F7EF2D9081418529E63A6B4C287C3941E1113543C7AF93E1ABE96A1511B3ED3B93F36DB193146BDC932EDB2A03C3CF511C1A798FF3130AD9ABB5044E1F67049878D3CE4686A2E3E5EEA3A098B71778CD8B73651CD5AFC320CDC4F315F7666659B5’, but the output assembly is named ‘MyAssembly.UnitTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’. Try adding a reference to ‘MyAssembly.UnitTests, PublicKey=0024000004800000940000000945000000240000525341310004000001000100E5D06B6A34E0EBE7386CA8C177B3EEDA66802357F74D8F5D419BF3623C9CE4F7EF2D9081418529E63A6B4C287C3941E1113543C7AF93E1ABE96A1511B3ED3B93F36DB193146BDC932EDB2A03C3CF511C1A798FF3130AD9ABB5044E1F67049878D3CE4686A2E3E5EEA3A098B71778CD8B73651CD5AFC320CDC4F315F7666659B5’ or changing the output assembly name to match.

I just read on Guy Burstein’s blog that WF 4.0 introduces a WorkflowInvoker class. This class makes it much easier to execute synchronous workflows without having to write all the plumbing code required by the WorkflowInstance class. This is really great news. See this post for the details.

Automatically generating technical documentation from code comments is really easy with Sandcastle and SHFB. If you are using TeamBuild to provide continuous integration then this is a great place to ensure up to date documentation is being produced. There a two ways that Sandcastle can be used to generate documentation. The first is dynamically without a SHFB project file and the second is with a SHFB project file.

Dynamically creating documentation is an easy solution that essentially documents all dll files found in the build directory with some known exclusions. This has the advantage that you don’t need to manage the documentation configuration as assemblies are added and removed from the solution. The disadvantages is that it potentially generates documentation for more assemblies than intended, namely the dependencies for the solution. The dynamic documentation generation is really good for framework/toolkit type solutions that don’t have external dependencies. The dynamic solution tells SHFB the information that it requires that would otherwise be defined via a project file. The MSBuild script looks something like the following.