Publishing Coverage in TFS 2008 and Visual Studio 2010

In my last post, I described the process I followed to build, run tests and produce coverage results with .NET 4 and TFS Build 2008. It fell short of showing coverage results in the build summary in Visual Studio (specifically Visual Studio 2010). I only got as far as copying the coverage report to the build drop folder.

This isn’t good enough. Practically, another developer would view the build summary in Visual Studio, see the test results but not see any coverage report. This person would most likely assume that no coverage report has been generated, get frustrated and move on. For the coverage report to provide any value to the development team, it needs to not stay isolated in the build drop folder. It needs to be seen. I saw two places for the coverage results to go to make it’s integration with Visual Studio near seamless: in the build summary and with the test results.

TFS Build 2008 with .NET 4

I had the recent experience of setting up builds with TFS 2008 that build .NET 4 projects. The requirements were that each build would 1) build the solution, 2) run the tests and 3) generate a coverage report. The process was very arduous because the TFS build process isn’t well documented and has limited customization. One thing I had going for me, though, was that the tests are written on the MsTest framework, which plays nice with TFS builds.

These are the steps that I went through:

First Entity Framework Impressions

During the past couple weeks at work, I’ve been migrating a solution from NHibernate to Entity Framework. I’ve been learning a lot, and it’s been quite enjoyable. There are some things I like about Entity Framework, but there are some things that I’ll miss from NHibernate. There are also some issues with the Entity Framework that I’ve been having.

There are several bright spots I’ve been seeing from using the Entity Framework.

1. I like how you can use a designer to create the entity classes and map them to table. It makes it so easy. It retrieves a lot of the schema from the database for you, which is nice.
2. The code generation is nice. It creates the classes for me. There’s also options to pre-compile queries to boost performance.
3. The entity framework can create self-tracking entities that keep track of changes as you make them. This is something I have wished for.

I’ve gotten used to NHibernate over the past four years of using it; so naturally, I would miss it. True, there was a steep learning curve at the beginning. I learned things such as the mapping syntax, HQL and remembering to marking the .hbm.xml files as embedded resources (that last one gets me every time). But after all that, there’s practically no schema that NHibernate can’t handle. There are a couple features from NHibernate that I miss.

1. I miss absolute control. NHibernate will let you configure it however, but it just may not work when you run it. On the other hand, the Entity Framework is very strict on what changes it will allow (especially in the designer), which is very much like Microsoft. For example, it insists that the schema is not configurable and should only come from the database.
2. I miss NHibernate’s relationship mapping. Once the relationship is set up in the mapping file correctly, it’ll work no matter what’s thrown at it (inserts, updates and cascading deletes). With entity framework, there a few extra steps involved (especially with the cascading deletes).

Because entity framework is very new, there are still some big issues in using it. Some of it may be from using an Oracle database, but that shouldn’t matter.

1. Every time you update the entity model from the database you have to close the designer and open it in XML to add the StoreGeneratedPattern=”Identity” to every primary key column reference. It’s very annoying. I’m guessing Microsoft will include a fix for this in the next Visual Studio service pack.
2. There’s a defect in the class generation template for self-tracking entities. There’s a scenario wherein the namespace (containing periods) of the child class is used as part of a method name, and it doesn’t compile. For this, I had to edit the template.
3. There’s not much configuration with how connections are used. By default, a new connection is used every time there’s a save to the database. This quickly consumes the connection pool. I’m not sure what to do for this yet. I wish there was smarter connection management out-of-the-box.