PrimordialCode

Some days ago my good friend Gian Maria Ricci showed on his blog Alkampfer’s Place a nice way to integrate twitter and TFS showing how you can have tweets related to TFS actions.

The idea was pretty cool, I actually do not a have a TFS up and running in my tests or development environments, but I wanted to have the same notifications when an automatic test on a build machine fails.

So I just ‘stole’ some of his code and realized a quick add-in for NUnit: it’s basically a simple test decorator, which get installed with the highest priority, so it is executed as the last one in the decorator’s chain. The test is just a wrapper around the original code and it checks the result of the original test method, if there’s a failure or an exception it uses a twitter account to send a notification to all the subscribers.

The Addin can be configured using an xml file called Twitter.config that must be deployed along with the addin. You can deploy the addin globally (placing it in the NUnit addins folder) or use my previous extension and deploy it directly along with your tests so it can be launched and used on a ‘per-project’ basis.

Here’s the code for the addin:

namespace Structura.NUnitExtensions.Twitter

One of the major problems when it comes to NUnit extensibility is the limitation that you must deploy your Addins in a subfolder (named ‘addins’) under the installation (or run) path of NUnit, so if you build some customization and extension and you want to deploy them on a build machine (or a Continous Integration machine) you need to build ad-hoc scripts and build actions.

To overcome this problem I’ve written a very simple and small addin that allows you to specify, in the configuration file of the test assembly, a set of DLLs that contains the addins to be loaded when the test start.

So once you have deployed this addin to your testing environment you can forget about any other script or action needed to load all the other extensions you develop to extend your test architecture.

The project is divided in 2 assemblies:

• Structura.NUnitExtensions: actually contains the ConfigrationSection customization to load the info from the config file.
• Structura.NUnitExtensions.Addins: contains the implementation of the addin, this is the only project that depends on NUnit.core.dll, and it will need to be compiled against the NUnit version you are using.

here’s the core class:

   1: [NUnitAddin(Name = "AddinsLoaderAddin", Description = "An addin to dinamically load other addins")]

These days I’m heavily working on NUnit to build some extensions to the testing framework we need on our projects. We need a simple way to launch our tests inside visual studio while developing. Our first solution was to use TestDriven.NET or the Reshaper implementation of NUnit.

However both these approaches have some limitation I actually don’t like, especially when it comes to the use of NUnit addins. Resharper do not have full support installing and using NUnit addins, and TestDriven.net will force you to use it’s embedded version of NUnit to let the addin launch the environment and the tests.

I started to look around and found NUnitit on CodePlex, Nunitit is an addin that allows you to run and debug NUnit projects within Visual Studio.

In its actual implementation it has however some limitations: you have to set the project you want to run as the startup project and you cannot run single tests (like TestDriven.net for example).

So I took the code and added some of the missing functionalities, now you can:

• Run the currently selected project in the solution explorer in the NUnit GUI.
• Run the currently selected project in the solution explorer in the NUnit console.
• Run a single test (open a file and place the caret on the test you want to run) using the NUnit console.

I posted my code to the original author of the addin, I hope they will be integrated in the official version too.

Here are the code and the installation files:

Related Content

• NUnit extensibility: an Addin to dynamically load other Addins (07/06/2009)
• NUnit: Twitter notification Addin (07/10/2009)
• Resharper and the OutOfMemoryException problem (26/08/2015)
• Spot Hidden Exceptions using IntelliTrace (26/08/2015)
• Visual Studio 2010 designer error: Value cannot be null. Parameter name: objectType (26/08/2015)
• More related document (10)

Sooner or later everyone face the problem of having to deal with paginated data in WPF, paginating a collection is quite easy and you can refer to one of my previous posts too (http://www.primordialcode.com/index.php/2008/09/08/silverlight-a-generic-pagination-control/ and http://www.primordialcode.com/index.php/2008/09/19/silverlight-pagination-control-bug-fixed/).

This time I needed a way to interact with some WCF services that I have to use in order to get the paged data from the server. What I wanted to create was a component that encapsulates the logic of handling the requests for the data in order to minimize the amount of code I have to write for similar operations in different forms of the application, some key features:

• It has to handle a reference to the current page index
• You have to specify the page size
• You have to specify the types of object that will be hold inside the returned collection
• You can specify an object that represent a set of filter you can do on the data (you can change them and ask for a refresh)
• You have to specify the function that will be used to retrieve the paged data, it has however to conform to a specific signature.
• You can use the data structures returned by this object (CurrentPage, TotalPages and Data, which contains the actual array of data objects) with the binding infrastructure of WPF.
• This control does not have a graphical representation for the command buttons (First, Last, Next, etc.), it is only a support class.

Here’s the actual implementation:

/// <summary>

I spent a couple of hours trying to figure out why the Tomcat service of a fresh installation of TeamCity Professional was continuously crashing each time I tried to open the administration console in the browser.

I couldn’t find any useful log of information for that (I’m not really a Tomcat/Apache fan nor expert) so what I did was to open the services configuration from the control panel and to allow the ‘TeamCity Web Server’ service to interact with the desktop.

In this way I was able to see the command prompt window with all the action that the service was going to take. So I realized that the service (on my machine) takes really a long time to startup (like 2-3 minutes) and that at the first request I made, he crashed out with an error regarding the binding of the address and the port.

So I had an illumination...I was smart enough to enter an unused port for the TeamCity server during the installation...BUT...an error on port and address binding may only mean that something else is using the same configuration.

I started checking all the installed programs with a web administration console and I found that VMware on the same machine used a Tomcat/Apache server too, so I opened up both of the ‘server.xml’ tomcat configuration files (you can find them in the ‘conf’ folder of your installations) and I found that internally they both used the same port 8443 to which all the other were redirected.

VMware code snippet:

<Connector port="8308" protocol="HTTP/1.1"                 

In one of my previous posts I demonstrated how you can build a Castle Windsor facility to create WCF Proxy classes given the interface of the service (Castle Windsor WCF Services Resolution Facility). For my WPF/Silverlight application framework I needed the same feature for the IoC container I’m using there, so here it is how you can implement the same functionality in Unity.

The extension points in Unity are very different from Castle Winsor, what we have to do to implement our WCF proxy class generator through resolution is to create the following classes:

• WcfProxyBuildPlanPolicy: a BuildPlan policy that will be used by the engine to create the instances of the proxy classes.
• IWcfProxyConfiguration: an interface used to register the new types in the IoC container and associated them with the buildplan policy used to construct the instances of the objects.
• WcfProxyUnityContainerExtension: a container Extension that will expose the concrete implementation of the methods of the IWcfProxyConfiguration interface.

Here’s the first implementation of those classes:

/// <summary>