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.

1) The first place the coverage results need to go is on the build summary. Using TFS 2008, .NET 3.5 and Visual Studio 2008, a summary of coverage results are published in the build summary automatically. Since I’m dealing with TFS 2008, .NET 4 and Visual Studio 2010, it doesn’t happen automatically. I’m not sure whether TFS 2008 or Visual Studio 2010 is to blame for this breakdown, but that doesn’t seem important. The solution I’m using is to write an extension to the build process to explicitly write the coverage results to TFS. Visual Studio comes with the libraries needed to communicate to TFS. Here is how to accomplish that:

//using Microsoft.TeamFoundation.Build.Client
//using Microsoft.TeamFoundation.Build.Common
//using Microsoft.TeamFoundation.Client
var tfs = TeamFoundationServerFactory.GetServer(teamFoundationServerUrl);
var buildServer = buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));
var build = buildServer.QueryBuildsByUri(new[] { buildUri }, new[] { "*" }, QueryOptions.All)[0];
var configSummary = InformationNodeConverters.GetConfigurationSummaries(build)[0];
var coverageSummary = configSummary.AddCodeCoverageSummary();
coverageSummary.BlocksCovered = blocksCovered;
coverageSummary.BlocksNotCovered = blocksNotCovered;
coverageSummary.LinesCovered = linesCovered;
coverageSummary.LinesNotCovered = linesNotCovered;
coverageSummary.LinesPartiallyCovered = linesPartiallyCovered;
coverageSummary.Name = testRunName;
coverageSummary.RunId = testRunId;
coverageSummary.RunUser = runUser;

//workaround for MS assemblies not setting BuildInformationNode.Build
//otherwise there's a NullReferenceException during Save()
var coverageInfoNode = build.Information.GetNodesByType(InformationTypes.ConfigurationSummary)[0].Children.GetNodesByType(InformationTypes.CodeCoverageSummary)[0];
var buildPropertyInfo = coverageInfoNode.GetType().GetProperty("Build", BindingFlags.Instance | BindingFlags.DeclaredOnly | BindingFlags.NonPublic);
buildPropertyInfo.SetValue(coverageInfoNode, build, null);

coverageSummary.Save();

The example code includes a workaround for a NullReferenceException I kept seeing when trying to save coverage summary to TFS. There might be a cleaner way to do it, or there might be some other way to do it; but this works.

2) The second place the coverage results need to go to make the coverage results more tightly integrated with Visual Studio is attached to the test results. When someone clicks “View Test Results” from the build summary in Visual Studio, the coverage results should open with the test results, but that didn’t happen. Instead there was an error displayed in Visual Studio that it couldn’t find one of the reference assemblies similar to how the .coverage file behaves when you open it remotely. Clicking on “View Test Results” opens a test results file (.trx) in the build drop. The first one I saw was <build_drop_folder>\TestResults\<test_run_id>.trx. In the TestResults directory, there is also a folder with the name of the test run ID. This folder contains all supporting files for the test results including the coverage results. The coverage results are typically found in the <build_drop_folder>\TestResults\<test_run_id>\In\<machine_name> directory. The original coverage file (data.coverage) is there, and I also already had the coverage xml (data.coveragexml) copied there.

I looked at the .trx file in notepad, and the first thought that came to mind was that the old coverage file is being opened because it’s referenced in the <ResultFiles> element. Yet when I changed the coverage file references multiple ways, there was no change in how the coverage was loaded. Thanks to the Process Monitor, I found out my assumptions were incorrect in two ways. One, <build_drop_folder>\TestResults\<test_run_id>.trx isn’t the file Visual Studio 2010 is opening; instead, it’s <build_drop_folder>\TestResults\<test_run_id>\<test_run_id>_vs10.trx. Two, Visual Studio pays no attention to the <ResultFiles> element in the .trx file to load the associated coverage. It just searches the sub-directories for coverage files. It finds the data.coverage file before data.coveragexml; so, it tries to load data.coverage and fails.

My solution to loading the coverage with the test results is ultra simplistic. I delete the old data.coverage file from the build drop folder. After that, data.coveragexml is loaded instead. As a result, the coverage results load with the test results when someone clicks “View Test Results” from the build summary without assembly reference errors.

I haven’t found any more places yet where I can integrate the coverage results with Visual Studio 2010. If anyone knows of any more places, please let me know.

Here are some links that have helped me immensely through the whole process:
http://msdn.microsoft.com/en-us/library/aa337604%28v=VS.90%29.aspx
http://blogs.msdn.com/b/phuene/archive/2009/12/01/programmatic-coverage-analysis-in-visual-studio-2010.aspx
http://blogs.msdn.com/b/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
http://www.woodwardweb.com/dotnet/tfs_build_api_b.html

These are the steps that I went through:

1. Installed TFS 2008 Build on the build server. This included installing a limited version of Visual Studio 2008.
2. Installed Visual Studio 2008 on my local computer even though I primarily use 2010. I found out by trial that Visual Studio 2010 does not include many of the dialogs required to manage TFS 2008 builds because it’s designed for TFS 2010.
3. Added the build server to the list of build agents in TFS.
4. Created a build definition for the project. I did this through Visual Studio 2008 because, again, it has better dialogs for TFS 2008. For example, it created for me the skeleton MsBuild script required for the build.
5. For the build configuration, I decided not to use a .vsmdi to define what tests to run. Instead, I chose to run tests within testing assemblies selected by the TestContainer wildcard. The reasoning for this is that whenever someone would add a test to the test harness, he would have to both add the test and include the test in the .vsmdi file. I could foresee that .vsmdi file getting very out of date. With the TestContainer wildcard, the test would be automatically picked up.
6. Added a .testsettings file to the build definition. When you use a .vsmdi file, the .testsettings file is already registered. But since I wasn’t using that setup, I had to add the .testsettings file directly to the msbuild script (TFSBuild.proj). I did this by adding a RunConfigFile element with the name of the .testsettings file to the first PropertyGroup element.
7. When I started running the builds, I realized that VS2008 defaulted the TFSBuild.proj file to use .NET 3.5. This doesn’t work for a .NET 4 project. I promptly changed the tool version in the root element of the msbuild file from 3.5 to 4.
8. Changed one more thing to get the build server to build .NET 4. On the server, I configured the msbuild path to .NET 4 in the MsBuildPath setting in tsbuildservice.exe.config (C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies). Then after I restarted the service, it started building with .NET 4.
9. Since the solution uses mstest, I then installed Visual Studio 2010 on the build server to get the references to resolve.
10. As a result of installing VS2010 on the build server, the TFS build script (C:\Program Files (x86)\Msbuild\Microsoft\Visual Studio\Microsoft.TeamFoundation.Build.targets) was updated for TFS 2010. Of course, this caused the builds to fail. The builds started working again after the file was rolled back. At this point, the solution was building and tests were executing. It was time for requirement 3: test coverage.
11. Selected the assemblies to collect coverage statistics on. This is configured in the .testsettings file. VS2010 has a very nice dialog to configure the coverage settings, but it’s a little hidden.
    1. Select “Data and Diagnostics” on the left.
    2. Select “Code Coverage” in the list.
    3. Click on the small Configure button that appears just above the list. This will show the list of assemblies to collect coverage on.
12. Finally, the build started generating the coverage as a data.coverage file. But when I opened on the file on the build server, it couldn’t resolve the assembly references. I fixed this by unchecking the “Instrument Assemblies in Place” checkbox in the code coverage configuration dialog for the .testsettings file. This allowed the coverage results to be viewed on the build server.
13. The trouble I faced then is that I the coverage results couldn’t be viewed anywhere other than on the build server, which was unacceptable. The mstest coverage generates a binary report file with full path references to the dll’s (specific to the build server), and the file won’t load if the references don’t resolve. I figured out that if I loaded the coverage report into Visual Studio on the build server, I could then export the coverage report as an XML file, but that doesn’t help me in the build process. So, I looked for a command-line utility from Microsoft to do that because most things you can do in Visual Studio, you can do on the command line. No such luck!
    I finally found the API calls to export the coverage as XML, and I wrote my own command-line utility to do it. It comes down to three lines of code (shown below). It took me longer to find it than to write it. Next, I executed the utility in the TSFBuild.proj file to generate the XML.
     

    //reference Microsoft.VisualStudio.Coverage.Analysis
    // at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
    var coverageInfo = CoverageInfo.CreateFromFile(“foo.coverage”);
    var dataSet = coverageInfo.BuildDataSet(null);
    dataSet.ExportXml(“bar.coveragexml”);

14. The last step was to publish the coverage XML file with the build drop. To do this, I included a copy in the TSFBuild.proj file. Finshed!!!

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.

Therefore, I created a windows desktop application that can open the keys in their various formats. The application can also save the key into the various formats. You can download the source here. I wrote it with version 5.0 of the Microsoft Enterprise Library, .NET 4.0 and Visual Studio 2010. I made the assumption that the user know a little about how Enterprise Library stores the keys. It’s still in development and a little rough; so, use it at your own risk.

But what really gets my goat is when people compare lines of code between the two because they inflate the C# line count. One, they introduce unnecessary methods, properties, etc. Two, braces on their own line are included in the line count. Three, they suddenly forget about anonymous delegates and lamda statements. Let’s look at this F# example (I got this one from http://2009.scandevconf.se/db/FSharp-Intro-v1.ppt):

let data = (1, 2, 3)

let f(a, b, c) =
    let sum = a + b + c
    let g(x) = sum + x * x
    g(a), g(b), g(c)

Now, let’s write it in C#:

var data = new[] { 1, 2, 3 };

static void F(int a, int b, int c) {
    var sum = a + b + c;
    var g = delegate(int x) { sum + x * x; };
    g(a); g(b); g(c);
}

F# does have the ability to be more concise than C# (I do have to admit that), but don’t try to skew the numbers!

• Subaru WRX. This is the car I currently drive. You can call me biased, but I love it!
• Toyota Tacoma. Everyone needs a truck at some point. This is a versatile moving machine, but it doesn’t make you feel guilty for hauling just a lawn mower. This may be my next vehicle purchase.
• Inifiniti G37x Coupe. This is just an all-around sexy car. I don’t know how they get the exhaust note so spot-on. It’s purr-fect.
• Lexus IS 250
• Acura TSX
• Nissan Altima 2.5 Coupe. I like the lines on the back-end of the coupe better than the sedan.
• Honda Fit. Yes. I said the Fit. There is always elegance in simplicity and versatility, and it has both. Also, I really like that the front seats meet the back seat to create a set of easy chairs.
• Honda Crosstour or Acura ZDX. The curves on the hatch really catch my eye.
• Infiniti FX35
• Acura RDX. Yay turbo!
• Nissan Xterra

The last .NET user group meeting that I attended inspired me to try a new method in time management. The presentation there was about how to be a good developer. One of the stories in that presentation was about development team who had a board of priorities with the tasks listed on sheets of paper. This inspired me to create my own board of priorities that I posted on my cubicle wall. I put it on my wall to let everyone know what my queue of tasks are. I put my tasks on note cards and place them into one of three categories: Doing, Need To and Want To. I think these categories are pretty self-explanatory. I’ve tried it for couple weeks now, and it’s been working out. Nobody has tried to mess with it yet, and it’s a constant reminder of what I have on my plate. I think I’ll keep doing it.

Another point about time management that I wanted to mention is something one of my co-workers mentioned to me. He boiled time management down to a “Punnett Square”. Do you remember doing that in Jr. High science class when you were learning about genetics? Though, this doesn’t have do with genetics. My co-worker said that the one axis is importance (important and not important) and the other is urgency (urgent and not urgent). You would then classify your task in one of four squares. My own personal twist on this idea is as follows. First of all, the tasks in the not important and not urgent square practically don’t exist. They shouldn’t receive any of my attention. Secondly, the tasks in the important and urgent square are what I should be doing presently. Thirdly, my effort for the tasks in the important and not urgent square should be spent trying to make them more urgent. This means that I’m trying to see whether they would eventually be important and urgent enough to be what I’m working on. Then for the tasks in the final square (not important and urgent), my effort should be spent trying to make them less urgent meaning they would eventually go away.

Here are the extensions that I have currently installed in Firefox. Most of them tend to be very techie. I have them somewhat ordered from most frequently used to least frequently used.

1. Firebug
   This is a web developer’s dream come true. It tells you anything you would want to know about how a web page works in a way that’s most convenient. I don’t know of anyone in my line of work who hasn’t used it.
2. Web Developer
   This is a toolbar that simply makes my job easier. Together with Firebug, they form a dynamic duo that really kick some butt! Sure, Batman (Firebug) can do the job on his own, but Robin makes things easier.
3. CacheViewer
   Firefox doesn’t have the windows explorer integration for the browser cache like Internet Explorer has. Although you can enter “about:cache” in the address bar in Firefox to view the cache, this can get cumbersome when looking for certain items. This add-on makes things more intuitive.
4. MeasureIt
   Although Firebug gives you the dimensions of any one element in the page, sometimes you want to know the approximate measurement across multiple elements. I often use this in conjunction with the built-in Windows magnifier.
5. ColorZilla
   ColorZilla makes it easy to find the color of an element, just point and click. It saves you from having to dig through the style sheets to find the associated color. I actually use this add-on most to find a color within an image created by one of our designers. If you open the image with Firefox, you can use ColorZilla with it.
6. FiddlerHook
   This add-on comes with Fiddler2 (a robust web traffic interception utility). By default, Fiddler2 intercepts Internet Explorer traffic, but you have to have this extension to intercept Firefox requests. Yet, not intercepting Firefox traffic help if you’re debugging web services.
7. Tamper Data
   This is another extension that intercepts Firefox web requests. It’s not as full-featured as Fiddler2. I use this one when I don’t feel like starting up Fiddler2.
8. FireShot
   This add-on is the most recent addition to my collection. If you use the [Alt]+[PrtScn] key combination in Windows, it’ll put the screen shot of the current window in the clipboard. This works for most cases, but there are some cases when you want to grab a screen shot of an entire scrolling page. The built-in windows screen shot functionality makes things hard in this case because you have to past the individual screen shot images together. FireShot makes this a one-click operation, and it has a bunch more features I still have to explore.
9. FireFTP
   Firefox doesn’t come with an FTP client out-of-the-box which makes ftp links unnavigable. FireFTP fixes that.
10. YSlow
    This is an add-on to Firebug that diagnoses client-side performance problems. It tells you “whY your page is SLOW”. It’s another tool in Batman’s utility belt.
11. Resizeable Textarea
    A feature available in Safari that I’ve always envied is the ability to resize text areas. This add-on promises to give me that. I’m still trying it out.
12. Greasemonkey
    This allows users to install customizing scripts to change around pages. The first time I saw this I said, “Oh cool!” I installed the extension, tried it out, and ever since I’ve been trying to figure out how to make use of it. I might have been able to use it once. It stays turned off most of the time.
13. IE Tab Plus
    This allows loading pages with the IE rending engine within Firefox. This is handy when I find some legacy pages that only load right in Internet Explorer, and I don’t feel like opening IE. Most web pages anymore are built to be cross-browser compatible.
14. Chickenfoot
    This is like Greasemonkey on steroids. Once again, I downloaded it because of the wow-factor, and I don’t know what to do with it.

If anyone knows of a useful Firefox add-on, please let me know.