John Socha-Leialoha's Blog

This blog has moved

noreply@blogger.com (John Socha-Leialoha) — Tue, 16 Mar 2010 13:39:00 +0000

This blog is now located at http://blogs.socha.com/. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to http://blogs.socha.com/feeds/posts/default.

Upgrading Team Foundation Server 2008 Reports to 2010, Part III

noreply@blogger.com (John Socha-Leialoha) — Tue, 02 Mar 2010 19:23:00 +0000

This is likely to be my final post on upgrading reports for Team Foundation Server 2010, and reflects one last change we made to the cube schema from the Release Candidate to the final version. This last change was to improve the performance of cube processing, and in particular, processing the Test Result dimension. We were able to significantly improve performance by removing the Area and Iteration Hierarchy attributes from the Test Result dimension.

So if you have any reports that use these hierarchies in the Test Result dimension, you’ll need to update your reports.

Sunder Raman has provided a higher-level overview of this change:
http://blogs.msdn.com/sunder/archive/2010/03/03/team-foundation-server-2010-cube-schema-changes-in-rtm.aspx

Area Hierarchy

You’ll want to use the Area Hierarchy from the Test Case dimension. The idea is that the test case defines the area that is being tested, so this is the appropriate test result to use. Your other option would be to use the Area Hierarchy from the Test Plan dimension. However, we don’t recommend this because test plans can and often do cover multiple areas.

One side effect of this change is that you’ll now see the area for some test results listed as Unknown. This means they don’t have any area, which will be the case when you publish unit test results that aren’t connected to a Test Case. Previously these test results appeared in the root area path for your Team Project, so it’s a minor change. But now you can at least tell which test results were explicitly connected to an area as a result of being run via a Test Case.

Iteration Hierarchy

You’ll want to use the Iteration Hierarchy from the Test Plan dimension. Test Plans are usually tied to a specific iteration. In Agile development, each new iteration introduces new functionality, and therefore a new test plan is required. Test Cases, on the other hand, don’t really live in any one iteration, so it wouldn’t make sense to use the iteration from the test case.

Customizing Report Parameters for Team Foundation Server 2010

noreply@blogger.com (John Socha-Leialoha) — Thu, 22 Oct 2009 21:16:00 +0000

Very often you’ll want to change the default settings for parameters in a report, but Reporting Services doesn’t have a user interface that allows you to select parameters, and then save them for use again. There is a way to customize the set of parameter values without learning how to author reports, but it’s a little involved. In this post, I’ll cover the following:

Changing the default values that are used to render a report
Creating multiple views on the same report, each with different default parameters

About Report Parameters

First a little bit of background on report parameters. Many of the TFS 2010 reports read from the Analysis Services database (or cube) that, by default, is called Tfs_Analysis (it was called TfsWarehouse in previous releases). Since this is a cube, and not a relational warehouse, default parameter values will look a little odd. As an example, this is what the default value might look like when you want to select “Iteration 1” in the iteration parameter:

[Work Item].[Iteration Hierarchy].[Iteration1].&[10]&[11]

Yikes, you say, how are you supposed to figure that out?

I’m not going to get into the details of why this is so complicated. If you’re interested, I wrote an MSDN article for TFS 2008 that will give you some idea about how this works, although the details have changed since then.

But there is a tool you can use to get this information: SQL Server Management Studio, which you can install from the SQL Server DVD. Alternatively, you can use a free program called MDX Studio, which is what I’ll use here as an example.

Finding the Default Value

The first step is to launch MDX Studio and connect to the TFS cube. You might need to find out the server and database from your TFS administrator, and also have them grant you read access (they need to add you to the TfsWarehouseDataReader role).

Finding an Iteration Value

Launch MDX Studio, type the name of the Analysis Services machine into the Connect to Analysis Services dialog box, and then click on the Connect button. You should see a display something like this:
In the Metadata section, scroll down so you can see Work Item and expand that item.
Expand the Work Item.Iteration Hierarchy node.
Expand the (All) and then All nodes, and then the collection node that contains your team project.
Expand the node that contains your team project. You should see something like this:
Finally, drag the iteration node (Iteration 1 in this example) into the Query area:

You can now copy this “ID” and use it in the following steps.

Setting Parameter Defaults

You’ll be using Report Manager to make these changes:

Right click on the Reports node of your team project inside Visual Studio and select Show Report Site…:
Click on the Properties tab at the top of the report:
Click on the Parameters link:

At this point you’ll see a list of parameters, which should look something like this:

To change the default iteration, for example, you would paste the value you got from the previous step into the text box circled in red above, and then click on the Apply button.

Multiple Parameter Settings – Linked Reports

There are times where you’ll want to have several versions of the report, each with different parameter values. Reporting Services has a feature called Linked Reports that allows you to essentially create sets of parameters that will be applied to a single copy of the report, but appear as a new report.

Here is how you create a linked report:

Click on the Properties tab for the report (just like in the previous section)
Click on the Create Linked Report button on the Properties page
Type in the name you want to use for this new linked report, and then click on the OK button
Click on the Properties tab of this new linked report
Click on the Parameters link on the left side to customize the parameter values that will be used for the linked report, and click on the Apply button to accept the new default values

Upgrading Team Foundation Server 2008 Reports to 2010, Part II

noreply@blogger.com (John Socha-Leialoha) — Thu, 15 Oct 2009 20:59:00 +0000

My previous post, Upgrading Team Foundation Server 2008 Reports to 2010, provides a lot of information on how to upgrade reports to work with the new 2010 version of Team Foundation Server, and even though I wrote it for Beta 1, much of the information still stands. There are, however, changes that have been made since then, so in this post I’ll provide updated information that applies to Beta 2 (and hopefully the final version of 2010).

Cube Changes

There were a few breaking changes to the cube that affected our reports, which are described in the sections below. You can find more details on cube changes in Sunder’s blog post: Team Foundation Server 2010 - Relational Warehouse and Cube Schema Changes.

Measure Changes

In previous versions of the cube, there were two measure groups for work items: Work Item History and Current Work Item. Here is one example of a measure pair from those two groups:

[Measures].[Cumulative Count]
[Measures].[Current Work Item Count]

Having two measures was always a little confusing. Starting in Beta 2, there is just one measure and one measure group. The measure group is now called Work Item, and there is a single measure that is used for both current and historical:

[Measures].[Work Item Count]

Now this measure will show historical information if you have the Date dimension included in your query, otherwise it will show current information. Much simpler. The other work item measures also follow this new pattern, with a single rather than a pair of measures for each of the work item measures.

In general, any measure that had Cumulative at the start before, just drop the Cumulative. Likewise, if it had Current at the start of the name, just drop Current. The Count measure above is, of course, an exception. Here is another example of before and after:

Before: [Measures].[Cumulative Completed Work]
After:  [Measures].[Completed Work]

That being said, there are some cases where measures with Cumulative at the start now have Trend at the end of the name. For example, [Measures].[Result Count Trend]. In general, your best bet is to look at the cube and see what the measures are called now.

Area/Iteration Hierarchies

As I mentioned in the previous post, 2010 introduces team project collections (TPCs), which is a grouping of a set of team projects. Although TPCs were supported in beta 1, the TPC was not included in the area and iteration hierarchies. So if you had two projects with the same name, but in different TPCs, you couldn’t tell which areas/iterations belonged to a specific project.

To fix this, we added the TPC name as part of the area/iteration hierarchy between the root and the top-level node for the team project. As a result, we had to change all the queries that we use to get the area and iteration parameters.

In this process of doing this, however, we also realized we could switch to a single query for each parameter instead of the two queries we had before. These new queries look a lot more complicated, but they’re actually not that bad. A bit of of explanation is in order because we also change the default value that we’re using so we can hard-code it rather than using a query. Doing this allowed us to provide a better experience when the cube doesn’t contain any areas or iterations for the team project, which will happen, for example, with a new team project that has no work items.

Here are the new default values:

Parameter	Default Value
AreaParam	[Work Item].[Area Hierarchy].[All]
IterationParam	[Work Item].[Iteration Hierarchy].[All]

What we’re trying to do is return query results that look something like this:

ParameterCaption	ParameterValue
All (No Filter)	[Work Item].[Area Hierarchy].[All]
(ProcessTest)	[Work Item].[Area Hierarchy].&[67]&[67]
Iteration 1	[Work Item].[Area Hierarchy].&[67]&[78]

So how do we get this? Using a few tricks:

The All member is always returned. We use a Union function to ensure that we always return this member.
The NonEmpty/CrossJoin near the end of this query returns all the members at the Area1 level and below. Area0 is the level of the team project, and there is a level above this for the TPC. By going directly to Area1 and all children of that level, we’re getting all the children of the project. We also cross join with the team project to ensure we only get areas for the current team project.
The reason for the Except/Extract function is much less obvious, but it has to do with the outer Descendants function. Basically, we want to get all the first children of the project, and then all children of these members. In order for this to work when there are no matches (in which case the NonEmpty returns no members), we Union the results with the All member, but then we need to remove that member and also return only members in the Work Item dimension. That is what the combination of Extract and then Except accomplishes.

dsArea

WITH
    MEMBER [Measures].[Add Spaces] AS
        VBA.Space(([Work Item].[Area Hierarchy].CurrentMember.Level.Ordinal - 1) * 2)
    MEMBER [Measures].[ParameterCaption] AS
        IIF([Work Item].[Area Hierarchy].CurrentMember
               IS [Work Item].[Area Hierarchy].[All],
            @AllNoFilter,
            [Measures].[Add Spaces]
                + [Work Item].[Area Hierarchy].CurrentMember.Member_Caption
        )
    MEMBER [Measures].[ParameterValue]
        AS [Work Item].[Area Hierarchy].CurrentMember.UniqueName
    MEMBER [Measures].[ParameterLevel]
        AS [Work Item].[Area Hierarchy].CurrentMember.Level.Ordinal
SELECT
{
    [Measures].[ParameterCaption],
    [Measures].[ParameterValue],
    [Measures].[ParameterLevel]
} ON COLUMNS,
{
    Union(
        [Work Item].[Area Hierarchy].[All],
        Descendants(
            //
            // We use Except to remove the extra [All] member so we get the descendants
            // only of the team project.
            //
            Except(
                Extract(
                    Union(
                        //
                        // We add [All] so Extract always has at least one tuple to
                        // work with. Otherwise it produces an error when there are no
                        // tuples returned by the NonEmpty below.
                        //
                        CrossJoin(
                            [Team Project].[Project Node GUID].[All],
                            [Work Item].[Area Hierarchy].[All]
                        ),
                        NonEmpty(
                            CrossJoin(
                                StrToMember("[Team Project].[Project Node GUID].&[{"
                                    + @ProjectGuid + "}]"),
                                [Work Item].[Area Hierarchy].[Area1]
                            ),
                            [Measures].[Work Item Count]
                        )
                    ),
                    [Work Item].[Area Hierarchy]
                ),
                [Work Item].[Area Hierarchy].[All]
            )
        )
    )
} ON ROWS
FROM [Team System]

dsIteration

WITH
    MEMBER [Measures].[Add Spaces] AS
        VBA.Space(([Work Item].[Iteration Hierarchy].CurrentMember.Level.Ordinal - 1) * 2)
    MEMBER [Measures].[ParameterCaption] AS
        IIF([Work Item].[Iteration Hierarchy].CurrentMember
                IS [Work Item].[Iteration Hierarchy].[All],
            @AllNoFilter,
            [Measures].[Add Spaces]
                + [Work Item].[Iteration Hierarchy].CurrentMember.Member_Caption
        )
    MEMBER [Measures].[ParameterValue]
        AS [Work Item].[Iteration Hierarchy].CurrentMember.UniqueName
    MEMBER [Measures].[ParameterLevel]
        AS [Work Item].[Iteration Hierarchy].CurrentMember.Level.Ordinal
SELECT
{
    [Measures].[ParameterCaption],
    [Measures].[ParameterValue],
    [Measures].[ParameterLevel]
} ON COLUMNS,
{
    Union(
        [Work Item].[Iteration Hierarchy].[All],
        Descendants(
            //
            // We use Except to remove the extra [All] member so we get the descendants
            // only of the team project.
            //
            Except(
                Extract(
                    Union(
                        //
                        // We add [All] so Extract always has at least one tuple to
                        // work with. Otherwise it produces an error when there are no
                        // tuples returned by the NonEmpty below.
                        //
                        CrossJoin(
                            [Team Project].[Project Node GUID].[All],
                            [Work Item].[Iteration Hierarchy].[All]
                        ),
                        NonEmpty(
                            CrossJoin(
                                StrToMember("[Team Project].[Project Node GUID].&[{"
                                    + @ProjectGuid + "}]"),
                                [Work Item].[Iteration Hierarchy].[Iteration1]
                            ),
                            [Measures].[Work Item Count]
                        )
                    ),
                    [Work Item].[Iteration Hierarchy]
                ),
                [Work Item].[Iteration Hierarchy].[All]
            )
        )
    )
} ON ROWS
FROM [Team System]

Handling the Turkish “I”

It turns out that there are several different “i” letters in Turkish, and this creates problems with one of the queries that we had in Beta 1. You’ll need to change dsProjectGuid to use all caps for the GUID in column name:

SELECT ProjectNodeGUID FROM GetProjectNodeInfoFromReportFolder(@ReportPath)

This is to match the case of the actual column name as defined in the warehouse.

Upgrading Team Foundation Server 2008 Reports to 2010, Part I

noreply@blogger.com (John Socha-Leialoha) — Tue, 19 May 2009 04:05:00 +0000

There have been some major changes in the reporting infrastructure for the forthcoming 2010 release of Team Foundation Server. You can find a blog entry on these changes here, written by the Program Manager on the team that made these changes:

Aaron Bjork, a PM on the Process team, has written a high-level blog post here: Team Foundation Server 2010 - Where Are My Reports?
Sunder Raman, a PM on the reporting infrastructure team has details on the changes here: Team Foundation Server 2010 - Relational Warehouse and Cube Schema Changes

In this blog post I’m going to dive deep into the details on how to modify reports to work with the new schema. But first, some definitions and background.

Update: Although I originally wrote this post for Beta 1, most of the information still applies. Some things have changed, and you’ll find the details here: Upgrading Team Foundation Server 2008 Reports to 2010, Part II

Definitions

Term	Description
Dimension	The dimensions in a cube are at the heart of what makes a cube useful for slicing data in many ways. Data values are associated with a set of dimensions, allowing you to show aggregate results sliced using a specific set of dimension values.
Fact	Data that can be associated with multiple dimensions. This data may also be aggregated. Fact tables hold these values.
Attribute	Under each dimension you’ll find a set of attributes and possibly hierarchies (area and iteration are a hierarchies). Each attribute is connected to a column in the corresponding dimension table in the warehouse.
Measure	Measures are values that correspond to columns in the corresponding fact table.

SQL Server 2008

The new version of Team Foundation Server requires SQL Server 2008, which brings a set of changes with it. I wrote a previous blog post on changes that might affect your existing queries:

TFS Report Issues with SQL Server 2008

One significant change is the tools you’ll be using. You’ll need to use the 2008 version of Report Designer, which has a number of UI changes that take a little getting used to. In particular, the entire experience with working with queries has changed dramatically. The 2005 version of Report Designer used three tabs for Data, Layout, and Preview:

The Data tab is now gone in the 2008 Report Designer, and has been replaced with the Report Data docking window:

You use this new window to edit and create data sources and report parameters. Editing of data sets is now done in a dialog box that you get to by double-clicking on a dataset, such as dsBugCount in the image above.

Many of the reports shipped with Team Foundation Server use hand-written MDX for their queries (the other reports use hand-written SQL). As such, if you need to change a query, you’ll be editing the actual query code. Double-clicking on a data set will produce the following dialog:

This dialog box is the new location for working with query parameters, fields, etc. To edit the query, click on the Query Designer button.

There is a limitation of this query designer that you’ll likely notice right away—whereas MDX in the 2005 Report Designer was formatted with syntax coloring, the new Query Designer has no formatting for queries, making it difficult to edit the queries.

I’ve found the easiest way for me to edit queries with syntax color support is to use this approach:

Copy the query from the Query section of the Dataset Properties window (which does have correct line breaks).
Paste the query into a session of SQL Server Management Studio.
Copy and paste the modified query into the Query Designer dialog box for testing and saving back to the report.

Updating Reports

Updating a Team Foundation Server 2008 report to work with the 2010 version requires making a number of changes. The details of these changes are described in the following sections.

MDX Changes

Here is a brief list for MDX reports against the cube:

Use the new data source names
Filter on Project GUID. This involves adding some new parameters and a new dataset
Update/replace queries use for area/iteration parameters
Replace WHERE clauses with sub-cube expressions
Rename dimensions/attributes whose names have changed

SQL Changes

If you’re working with the SQL warehouse, the changes are also significant. Here is a brief overview of the changes you’ll need to make:

Use the new data source names
Filter on Project GUID
Use the new public views when possible
Make sure your joins use unique keys. For example, work item IDs are no longer unique within the warehouse
Rename all table references because all table names have changed

Data Source Rename

You’ll find that the names of the Reporting Services data sources used by reports have changed:

2008 Name	2010 Name
TfsReportsDS	Tfs2010ReportsDS
TfsOlapReportsDS	Tfs2010OlapReportsDS

The new names exist to accommodate upgrading a server where you have an existing set of reports designed for Team Foundation Server 2005 or 2008. Installing the new version creates a new warehouse and cube that use a different, incompatible schema. The new data sources point to the new warehouse and cube, without overwriting the previous data sources.

The old warehouse and cube are not removed or overwritten when you upgrade the server so that old reports will continue to work. However, no new data will be added to the pre-upgrade warehouse and cube. Using new data source names allows the old reports, which use the old data sources, to continue to render pre-upgrade data.

You’ll need to make sure reports that you upgrade use the new data source names so they’ll connect to the new cube.

Reports Location

The support for Team Project collections in Team Foundation Server 2010 required some changes to the default location of reports. There were two features driving this change:

There is now a hierarchy instead of a flat list. For example, you can have a Team Project collection that has some projects under it.
Team Project names are not server-unique as they were in 2008. A project name has to be unique only within a single collection. In other words, the same project name can exist in two different team project collections.

Because of these changes, reports have a different location on the Reporting Services server. The pattern looks like this:

/TfsReports/Collection0/MyProject

That also means you need to use a different mechanism to obtain the default project associated with a report. In previous version, you could get the default project name from the report’s path and just use that to filter query results.

But with team project collections and 2010, you need to use the project’s GUID instead of the name as a filter since the name by itself may not be unique.

In the warehouse you’ll find a stored procedure you can use to obtain the project’ GUID from the report path, using code like this:

Create a parameter called ReportPath and move it so it’s the second parameter, after ExplicitProject.

Add this expression as the default value for the ReportPath parameter:

=IIF(LEN(Globals!ReportFolder) > 0,
    Globals!ReportFolder,
    Parameters!ExplicitProject.Value
)

Create a SQL dataset called dsProjectGuid that has this query:

SELECT ProjectNodeGuid FROM GetProjectNodeInfoFromReportFolder(@ReportPath)

Create a parameter called ProjectGuid just after the ReportPath parameter and set the default value to results of the dsProjectGuid dataset.

You will then need to modify your other queries to use the resulting GUID, which is covered below under Cube Improvements.

Warehouse Improvements

For the first time, writing reports against the warehouse using SQL is officially supported. As a rule of thumb, you’ll generally want to use the cube for historical reports, or reports that require a lot of slicing and dicing using parameters of aggregate data. The cube is really good at this sort of work.

The warehouse, on the other hand, allows you to create reports that pull loosely related data together in ways not possible with the cube.

Views

There are now a number of public views to help you work with the warehouse. All of these public views have names that end with “View,” such as WorkItemHistoryView.

Views that begin with “v” and end with “Overlay” are used for processing the cube, and as such aren’t really meant for use in your reports.

Compensating Records

When you work with historical data in the warehouse, you’ll need to be aware of compensating records. You’ll find compensating records in tables/views that include historical information, such as WorkItemHistoryView. Whenever you modify a work item, a pair of records is added to the warehouse. One record “undoes” the most recent previous record, and the next record adds the new settings for that work item. The compensating records allow you use to aggregate functions like SUM in query results.

Also connected with compensating records are two columns: System_ChangedDate and System_RevisedDate. The first column, System_ChangedDate indicates when the change to the work item was made. The other date tells you when the work item was next changed. As an example, suppose that you created a new task at 10:53 on 5/15/2009, and then you modified that work item at 11:23 on the next day. You would then see records like this:

System_ChangedDate	System_RevisedDate	Remaining Work	RecordCount
10:53 5/15/2009	11:23 5/16/2009	20	1
10:53 5/15/2009	11:23 5/16/2009	-20	-1
11:23 5/16/2009	0:00 1/1/9999	10	1

The first record was the original record, and you can see that it was revised at 11:23. The next record “cancels out” the first record, and was added at the same time as the third record. Finally, the third record is the current record, as indicated by the System_RevisedDate set to the maximum value for a DATETIME column. As a result, you can write a query that will return the current remaining work correctly like this:

SELECT SUM(Microsoft_VSTS_Scheduling_RemainingWork)
  FROM WorkItemHistoryView WHERE System_Id = 108
   AND ProjectNodeGUID = 'A8657108-E085-4DE5-B14C-97DAA378D46E'

That being said, you’ll get better performance if you use an “As Of” query instead of using SUM.

As Of Queries

The query above returns the “current” results. But what if you want to obtain the results as of a specific day? Let’s say you want to find out the remaining work as of the end of 5/15/2009. Looking at the end of a given day will give you the same results as you’ll get from the cube. Here is what that query will return the remaining work as of the end of 5/16/2009:

SELECT System_Id, Microsoft_VSTS_Scheduling_RemainingWork
  FROM WorkItemHistoryView WHERE System_ChangedDate < '5/16/2009'
   AND System_RevisedDate >= '5/16/2009'
   AND RecordCount > 0
   AND ProjectNodeGUID = 'A8657108-E085-4DE5-B14C-97DAA378D46E'

Here’s how this works. We want to return only the last records for each work item that was modified before 5/16/2009. The System_RevisedDate clause ensures we retrieve only the last record that was modified before 5/16/2009 because it finds the one record that was both modified before and revised after this date (or not revised at all, in which case the date is in the year 9999).

Additionally, you’ll notice this query tests for a positive RecordCount. Compensating records that cancel out a previous record always have a RecordCount of -1.

Uniqueness of ID Values

One new feature of Team Foundation Server 2010 is the support for team project collections, which is a group of team projects. Entire team project collections can be moved from one server to another. As a result, the IDs of work items are unique only within a single team project collection, but they may not be unique on a server that contains records from more than one team project collection. That is why the query in the previous section includes a filter on the project GUID in addition to the work item ID.

Table Names

Most table names have been changed in Team Foundation Server 2010. In previous versions, many of the table names had space in them, which created problems with some reporting tools. In the new warehouse, names do not have spaces, and they also have a prefix to indicate their use:

Prefix	Description
Dim	The table contains dimension data, which means the data will appear in the dimensions part of the cube. There is usually one column for each attribute or hierarchy that belongs to the dimension.
Fact	The values of cells in the cube, which show up via measures. Fact tables have foreign keys to various dimension tables.

As an example, the FactWorkItemHistory table contains a column called StateChangeCount that appears in the cube under measures, in the Work Item History measure folder.

Additionally, the DimWorkItem table shows up in the dimension hierarchy under Work Item.

Renaming the tables this way makes it easier to see the connection between tables in the warehouse and their corresponding entities in the cube.

Cube Improvements

The team working on the warehouse and cube had several goals when they set out to change the cube design:

Make the cube more usable
Increase query performance
Improve translation and load performance

Previous versions of the cube had a lot of dimensions, a little over 60. The new cube has been restructured to use less than half the number of dimensions. Yet at the same time, there are more ways to slice than before. This “simplification” was achieved by changing what were dimensions in the old version to attributes on closely related dimensions in the new version. For example, the Activated Date dimension became the Activated Date attribute inside the Work Item dimension.

Additionally, because the number of attributes on a dimension can be quite high now, many of the attributes are grouped into attribute folders.

Area and Iteration

Area and iteration used to be dimensions. Now, however, you’ll find area and iteration hierarchies within other dimensions, such as Work Item and Test Result. You’ll need to use the appropriate hierarchy in your query. For example if you’re slicing on test results, you’ll need to use the area/iteration hierarchies within the Test Result dimension.

Because areas and iterations were changed to become attributes and the project name is no longer unique, the queries for the area and iteration parameters are very different from before.

New Parameter Queries

If your report has parameters for area and iteration, you’ll need to modify or replace your queries to use the new structure. In this section you’ll find queries we’ve created for area and iteration lists and default values.

The old structure used a parent/child hierarchy that allowed you to use the project name as a key, making it easy to get the list of available areas and iterations for a team project, as well as the default values.

In the new structure, team project names are not guaranteed to be unique, so using the project name as a key might give you results for more than one team project. Additionally, the hierarchy is now a natural hierarchy rather than a parent-child hierarchy, which means that you don’t have data members that represent a node without children. Instead, the new hierarchies have the equivalent built into the hierarchy so the queries don’t need to check for DATAMEMBER values and format them differently (by enclosing them in parenthesis).

The queries to get the default area/iteration return a single member based on the project GUID by looking only at the direct children of the root. Limiting the scope to just the children of the root keeps the query fast.

Update: The queries for area and iteration no longer work in Beta 2 or later. For more information, see Upgrading Team Foundation Server 2008 Reports to 2010, Part II

dsAreaDefault

WITH
    MEMBER [Measures].[ParameterCaption] AS
        [Work Item].[Area Hierarchy].CurrentMember.Member_Caption
    MEMBER [Measures].[ParameterValue] AS
        [Work Item].[Area Hierarchy].CurrentMember.UniqueName
SELECT
{
     [Measures].[ParameterCaption],
     [Measures].[ParameterValue]} ON COLUMNS,
{
    NonEmpty(
        CrossJoin(
            StrToMember("[Team Project].[Project Node GUID].&[{" + @ProjectGuid + "}]"),
            Descendants([Work Item].[Area Hierarchy].[All].Children, 0)
        ),
        [Measures].[Cumulative Count]
    )
} ON ROWS
FROM [Team System]

dsArea

This data set uses as input the results from the dsAreaDefault query so it will scan only areas in the current project. Limiting the scope to just the children of the default area significantly improves performance of this query.

WITH
    MEMBER [Measures].[Add Spaces] AS
        VBA.Space([Work Item].[Area Hierarchy].CurrentMember.Level.Ordinal * 2)
    MEMBER [Measures].[ParameterCaption] AS
        [Measures].[Add Spaces] + [Work Item].[Area Hierarchy].CurrentMember.Member_Caption
    MEMBER [Measures].[ParameterValue] AS
        [Work Item].[Area Hierarchy].CurrentMember.UniqueName
SELECT
{
     [Measures].[ParameterCaption],
     [Measures].[ParameterValue]} ON COLUMNS,
{
    Descendants(StrToSet(@AreaDefault))
} ON ROWS
FROM [Team System]

dsIterationDefault

WITH
    MEMBER [Measures].[ParameterCaption] AS
        [Work Item].[Iteration Hierarchy].CurrentMember.Member_Caption
    MEMBER [Measures].[ParameterValue] AS
        [Work Item].[Iteration Hierarchy].CurrentMember.UniqueName
SELECT
{
     [Measures].[ParameterCaption],
     [Measures].[ParameterValue]} ON COLUMNS,
{
    NonEmpty(
        CrossJoin(
            StrToMember("[Team Project].[Project Node GUID].&[{" + @ProjectGuid + "}]"),
            Descendants([Work Item].[Iteration Hierarchy].[All].Children, 0)
        ),
         [Measures].[Cumulative Count]
    )
} ON ROWS
FROM [Team System]

dsIteration

This data set uses as input the results from the dsIterationDefault query.

WITH
    MEMBER [Measures].[ParameterCaption] AS
        [Work Item].[Iteration Hierarchy].CurrentMember.Member_Caption
    MEMBER [Measures].[ParameterValue] AS
        [Work Item].[Iteration Hierarchy].CurrentMember.UniqueName
SELECT
{
     [Measures].[ParameterCaption],
     [Measures].[ParameterValue]} ON COLUMNS,
{
    NonEmpty(
        CrossJoin(
            StrToMember("[Team Project].[Project Node GUID].&[{" + @ProjectGuid + "}]"),
            Descendants([Work Item].[Iteration Hierarchy].[All].Children, 0)
        ),
        [Measures].[Cumulative Count]
    )
} ON ROWS
FROM [Team System]

Other Modifications

Project Filter

You’ll need to modify all uses of the project name to use the GUID instead. The old version is on the top, and the new version is on the bottom, with the changes highlighted in yellow.

STRTOMEMBER("[Team Project].[Team Project].[" + @Project + "]"),
STRTOMEMBER("[Team Project].[Project Node GUID].[{" + @ProjectGuid + "}]"),

WHERE Clause

Many of the reports used the MDX WHERE clause to slice the data on team project, as well as other dimensions. However, this doesn’t always work with SQL Analysis Services 2008 because of changes in how queries are processed. Additionally, it’s not as fast as it could be because the slicing is done after the query body has been processed.

A much better approach is to replace the WHERE clause with a sub-cube expression because a sub-cube expression is applied before processing the rest of the query. Here is the before and after:

Before

FROM [Team System]
WHERE
(
    STRTOMEMBER("[Team Project].[Project Node GUID].[{" + @ProjectGuid + "}]"),
    STRTOSET(@IterationParam),
    STRTOSET(@AreaParam),
    StrToMember("[Work Item].[System_WorkItemType].[" + @Bug + "]")
)

Improved

FROM
(
    SELECT
    CrossJoin(
        STRTOMEMBER("[Team Project].[Project Node GUID].[{" + @ProjectGuid + "}]"),
        STRTOSET(@IterationParam),
        STRTOSET(@AreaParam),
        StrToMember("[Work Item].[System_WorkItemType].[" + @Bug + "]")
    ) ON COLUMNS
    FROM [Team System]
)

Complement Changes

Some of the reports used the complement operator (“-“), which performs much the same functionality as the EXCEPT function in MDX. However, these queries used the complement operator inside a WHERE clause in such a way that it produces an error in SQL Analysis Services 2008:

,STRTOMEMBER("[Team Project].[Team Project].[" + @Project + "]")
,-{STRTOMEMBER("[Work Item].[System_State].[System_State].[+@Proposed+]")}

The problem with this statement is that there is no mention of the Work Item dimension elsewhere inside the WHERE clause. What you need instead is exclude a value from a list of values, like this:

EXCEPT(

    Descendants([Work Item].[System_State].[System_State])
    ,STRTOMEMBER("[Work Item].[System_State].[System_State].[+@Proposed+]")
)

SharePoint Access Denied on SPWebApplication

noreply@blogger.com (John Socha-Leialoha) — Tue, 10 Mar 2009 19:36:00 +0000

I've been working on a SharePoint solution that needed to write properties to the current web application. Everything worked just fine on my development machine. But on some of our test machines, I found the following message in the SharePoint logs:

The SPPersistedObject, SPWebApplication Name=Default Web Site Parent=SPWebService, could not be updated because the current user is not a Farm Administrator.
System.Security.SecurityException: Access denied.

This turns out to be correct behavior, but it took a while to understand what was going on and how to setup my development machine to reproduce the problem.

In my code to set the web application property value, I was using RunWithElevatedPrivileges to ensure I had rights. However, what I didn't realize is that elevating privileges gives you full access to the content database, but not to the configuration database. SPWebApplication's property bag is stored in the configuration database, not the content database. That was one piece to the puzzle.

The other piece to the puzzle was how I had my development machine setup. I was using the same account on both the Central Administration application pool and the application pool used to run regular the web applications. So in essence, I was implicitly granting my code rights to write to the configuration database.

When I modified the application pools to use two different accounts, I was able to reproduce this problem on my development machine.

Here is a summary:

RunWithElevatedPrivileges only provides full access to the content database for the current web application. In other words, you can modify read-only lists, write SPWeb properties, etc. But you can't make changes to the SPWebApplication because it is persisted to the configuration database.
Always make sure your application pools for normal web applications are using a different account than the Central Administration application pool. This is recommended practice for production machines, but you should also setup your development and test machines this way to catch problems early.

TFS Report Issues with SQL Server 2008

noreply@blogger.com (John Socha-Leialoha) — Thu, 05 Mar 2009 21:40:00 +0000

Some of the reports that shipped with Team Foundation Server 2005 and 2008 run into problems when you attempt to run them on SQL Server 2008 Reporting Services. Here is an overview of of the problems and fixes for those problems. Most of these problems are a result of changes in how Analysis Services processes queries in 2008 vs 2005.

Complement and Except Errors

Several of the TFS reports show one of these errors when running under SQL 2008:

The set must have a single hierarchy to be used with the complement operator.

Two sets specified in the EXCEPT function have different dimensionality.

The reports that are affected are Scenario Details and Unplanned Work.

What does this mean? Basically, it means that the WHERE clause in the query is using the "-" operator to exclude a specific attribute from the query. For example, the Scenario Details reports includes the following inside the WHERE clause:

,STRTOSET( @AreaParam )

,STRTOSET( @IterationParam )

,STRTOMEMBER("[Team Project].[Team Project].[" + @Project + "]")

,-{STRTOMEMBER("[Work Item].[System_State].[System_State].[+@Proposed+]")}

The minus sign in front of the last line indicates that we want to filter out work items that are in the Proposed state. However, this doesn't work in SQL 2008. You'll notice that we're trying to exclude an a specific value without mentioning the other values.

The solution is to remove the exclusion from the WHERE clause and put it into the body of the query:

,STRTOSET( @AreaParam )

,STRTOSET( @IterationParam )

,EXCEPT(

Descendants([Work Item].[System_State].[System_State])

,STRTOMEMBER("[Work Item].[System_State].[System_State].[+@Proposed+]")

)

The key here is that we need to include all states except for the Proposed state, which is what the Except function above does.

WHERE vs Sub Cube

Many of the reports were written using the WHERE clause to filter the results. For example, so the results would be filtered on a single team project instead of the entire cube. However, the behavior of the WHERE clause changed somewhat in SQL Server Analysis Services 2008. The simplest solution is to rewrite the WHERE clause as a sub-cube expression instead. Not only will this fix some of the problems, but it should also make reports run faster.

Old Version:

FROM [Team System]

WHERE

(

STRTOMEMBER("[Team Project].[Team Project].[" + @Project + "]"),

STRTOMEMBER("[Work Item].[System_WorkItemType].[" + @Bug + "]")

)

New Version:

FROM

(

SELECT

CrossJoin(

STRTOMEMBER("[Team Project].[Team Project].[" + @Project + "]"),

STRTOMEMBER("[Work Item].[System_WorkItemType].[" + @Bug + "]")

) ON COLUMNS

FROM [Team System]

)

The WHERE clause above is applied after the rest of the MDX expression has been evaluated. But the second expression defines a subset of the cube that will be used to evaluate the rest of the expression. In other words, using a sub cube, you're restricting the set of cells to a smaller set before evaluating the query.

Extract Problems

Here is the error message you might see:

The Extract function was called with hierarchy 'System_Id' that does not exist in the set.

That's certainly not a very helpful error message. This message appears in the report called Bugs Found Without Corresponding Tests. The solution, as it turns out, is to use a sub-cube instead of a WHERE clause (described above).

Tuple Problem

In several of the reports, selecting all of the iterations produces the following error message:

The function expects a tuple expression for the argument. A tuple set expression was used.
More than 4,294,967,296 tuples

This error occurs with the following reports:

Bugs by Priority
Bugs Found Without Corresponding Tests
Issues and Blocked Work Items
Related Work Items
Requirement Details
Requirements Test History and Overview
Scenario Details
Triage
Unplanned Work

The solution to this problem is also to replace the WHERE clause at the end of the MDX query with a sub-cube expression, as described above.

SQL Reports and the IN Clause

The Load Test Summary report is a SQL report, and it contains an IN clause in the WHERE statement. This is used to allow multiple values to be selected and passed to the query. However, a change in behavior in SQL 2008 Reporting Services means that you'll see the following message when you have no values:

Incorrect syntax near ')'.

Here is why you see this message. The WHERE clause in the Load Test Summary report looks like this:

WHERE (Result.__ID IN (@ResultParam))
AND ([Test Result].[Result Record Count] = 1)

When there are no results passed into this query, Reporting Services 2008 simply removes @ResultParam, so you get something like "IN ()", and you get a syntax error, preventing this query from running.

The solution is to add an expression to the @ResultParam query parameter. This expression is evaluated in order to determine what is passed to the query. Here is what works:

=IIF(Parameters!ResultParam.Count > 0, Parameters!ResultParam.Value, "")

TF26062 Error for Area and Iteration paths

noreply@blogger.com (John Socha-Leialoha) — Tue, 13 Jan 2009 18:38:00 +0000

This is a post about Microsoft Team Foundation Server and setting the default iteration for new work items, and why it won't work. We recently had a request to modify a User Story work item so that the default iteration would be \Backlog instead of simply \ (the root of the project). The idea is that new stories added to an agile project should be added to the backlog, and then scheduled into a future iteration.

Work items are defined using XML, and each field on a work item form is defined with a FIELD element in this XML. For most fields you can provide a default value that will be filled in when you create a new work item of that type. This is done using code like this:

Unfortunately, this doesn't work. If you try to upload a process template that contains a work item type definition with this code, you'll get an error like this one:

Exception Message: TF26062: Rule '<DEFAULT from="value" value="$$PROJECTNAME$$\Backlog" />' is not supported for the field 'System.IterationPath'.

It turns out the current rules engine for work items doesn't allow setting a default value for either area or iteration when you create a new work item.

The Abstract Tar Pit

noreply@blogger.com (John Socha-Leialoha) — Tue, 23 Oct 2007 20:35:00 +0000

How often have you found yourself arguing with another person, and they just don't seem to understand you? Chances are they feel that you just don't understand them. You've fallen into the abstract tar pit.

Abstract discussions are like abstract art--they can be very appealing, in part because you can interpret the abstract art however you want to. People love to see what they want to see. But when it comes to technical discussions, abstract discussions are dangerous. There is a good chance someone listening to your abstract arguments will understand completely--but it won't be what you're trying to convey. To understand the abstract, they're likely creating concrete examples in their head and then arguing against your ideas based on these "private" concrete examples. The problem is, if these concrete examples aren't shared, you'll get an argument about completely different examples and understandings.

I recently worked on a 5-week project where this was really clear. There was a small group who had an idea they were trying to sell internally to get funding. Everyone else was feeling confused. Just when they thought they understood these ideas, another concept came along that contradicted what they thought they understood.

So we started a project using Expression Blend to create a "movie" of the idea. The first week we brainstormed a lot, and then drew sketches by hand of what the different screens would look like. We then presented these hand-drawn screens to a customer advisory board so we could get their feedback and help us decide what we should focus on during the next week. We intentionally used hand-drawn sketches in our discussions with customers so they wouldn't get bogged down in the small details and would just focus on the big picture.

About half way through the project we started to create actual screen mockups and animate them with Microsoft Expression Blend so it would look like a screen capture movie of an actual program--but it was all smoke and mirrors.

During the project, the team that had come up with the ideas were constantly arguing with us and saying we were asking the wrong questions. But when we had the final "movie" and showed it to them, an interesting thing happened. The conversations changed from being abstract to concrete. The idea team started to explain the details that we got wrong. And in the process, we discovered that we had gotten most of their vision correct--we just differed in some of the details.

What's more, other people who had been confused completely got the idea after seeing the movie. And again, the discussions were at a concrete level, so the discussions that came after seeing the movie were far more productive.

The Stages of Collaboration

noreply@blogger.com (John Socha-Leialoha) — Fri, 10 Aug 2007 19:10:00 +0000

Recently I've been working on an effort to create a new standard for a network protocol in the Model Railroad industry. There are several groups who began work on this effort independently without knowledge of the other groups. As it turns out, there are two groups with similar approaches and we've been trying to work together to create a unified proposal.

During this process, I realized that there are four stages that you must work through before you can come together with a unified approach that is truly a group effort:

Respect: First, you have to respect other people's knowledge and abilities. If you don't respect them, you're not going to listen to what they have to say. They also need to respect you, so there needs to be some work up front so each member learns to respect the other team members.

Understanding: This is a two way street. You need to make sure you understand what other people are proposing so you can see similarities and differences before you suggest changes. If you see what you believe are holes in another approach, you should ask questions about how they would handle that situation to help you understand. Either you'll help them see the hole, or you'll discover you didn't fully understand their approach. In either case, your questions must be sincere questions designed to help you understand both the advantages and disadvantages of other approaches.

Trust: You have to believe that each person is trying to work together to a common goal without hidden agendas. If you suspect they have a hidden agenda, you haven't achieved mutual trust yet.

Compromise: For any group effort to succeed, you must have compromise. But the compromises must come after the understanding and trust have developed or you're just giving in to reach an agreement.

Programming is Continuous Brainstorming

noreply@blogger.com (John Socha-Leialoha) — Thu, 19 Jul 2007 18:11:00 +0000

I was talking about pair programming recently with Mike at a company in Everett, WA, and he asked the usual question: "Doesn't having two people working on the same computer mean we lose productivity?" In response, I blurted out a reply: "Imagine that you need to do some brainstorming and you go into a room by yourself." He got the point.

Mike is a business person, not a developer, so I came up with this analogy because I was looking for something that would resonate with a business person. However, while driving home I realized it's actually much more than a simple analogy. Programming is, in fact, continuous brainstorming, which is why two heads are better (and more productive) than one. Or even the same two people working apart.

Users are Idiomatic

noreply@blogger.com (John Socha-Leialoha) — Fri, 05 Jan 2007 17:27:00 +0000

I recently had a discussion with J.D. Meier about user interfaces. During that discussion, I was talking about how users aren't consistent in a way that programs would define consistency. I've been having this discussion for years because of lessons I learned while writing the Norton Commander. Back then I discovered that in order to make an application "feel" consistent, the code need to include many special cases. But I've never had a succinct way to describe this.

But during my discussion with J.D. yesterday, he mentioned idioms and models and I realized that that's really the issues. Model-based design uses models to help create the design, and that's useful for many things. However, users, by nature, are not model driven--users are idiomatic.

One of the definitions of idiomatic, from the Merriam-Webster dictionary is this:

"peculiar to a particular group, individual, or style"

There are actually several aspects to viewing users as idiomatic.

First, different users will have different definitions of "intuitive." So when designing software, you need identify the different groups to understand what they're expected. But to make it even more interesting, individuals tend to jump from one group to another on a whim, so this process is by no means an easy process.

Second, and this isn't conveyed directly by the definition of idiomatic, users actually expect inconsistent behavior. Let me say that again. Users expect inconsistent behavior. What I mean by this is that code that "feels" correct to users typically has lots of special-case code to make the interface feel natural. As an example, going way back to the mid 1980s with the Norton Commander, I had scroll bars for a file viewer. In these days the thumb of the scroll bar moved by an entire line at a time and only had 23 possible positions. The usual approach for positioning the thumb is to calculate the percentage into the file and use this for the thumb position.

But imagine for a moment what happens when you have a long document. You page down several times and the thumb hasn't moved at all. Makes sense, right? You're probably thinking about the math when you answered that question. However users for the most part aren't familiar with the principles that lead to the code that controls the thumbs position. Instead, they're probably expecting the thumb to give them some indication of where they are in the file. One common reaction was that they must be at the top of the file because the thumb is at the very top.

So what I did was add some special case code that would move the thumb away from the top the minute you scrolled away from the top-most line of the file. Likewise, the thumb would not be at the very bottom until the last line in the file was visible. In between these two positions the thumb position was proportional.

This type of special-case code is what makes a program "feel" right to a user, but it often drives programmers nuts. My libraries were used by the people who wrote Norton Utilities 5.0. One of the first things they did when they started to change these libraries is to remove these special cases because they were "confusing" to users. The actual fact is that they were inconsistent by design. The inconsistency was in understanding that users views and "models" often do not map well into logical models because users are idiomatic.

Customizing TFS Work Item States and Reporting

noreply@blogger.com (John Socha-Leialoha) — Tue, 12 Dec 2006 18:54:00 +0000

We're using Team Foundation Server to manage our projects. The MSF Agile template, which is what we started with, has just two states for Tasks: Active and Closed. We wanted to add more states to keep track of the flow through iteration planning and test, so we ended up with the following states:

Pending
In Process
Developed
In Test
Closed

The initial state of Pending means it hasn't been planned for an iteration, whereas In Process means it's been assigned to an iteration. You could certainly envision other states, but you probably get the idea.

I added new states and transitions to the template and uploaded it to the server (you can use witexport to get a copy of the template and witimport to save it back to the server). The first think I noticed is that all the items in the "Active" state were flagged as having an invalid state because I had replaced "Active" with "Pending." There wasn't any batch method for updating these work items, so I had to change them one at a time. Fortunately, this is a young project, so there weren't many items that I had to change.

The next thing I found out is that I had broken some of the reports. It turns out that the burn-down chart on the Project Portal page is from the Remaining Work report, and this report assumes that Tasks only have the Active and Closed states. That means all the Tasks in all the new states disappeared from this graph. Woops!

Updating the Warehouse

Since I needed do some more work and testing, I switched to a test TFS server so I wouldn't be working with the production server. However, this server didn't have Tasks in the other states, so I changed the state of a number of tasks. But since the warehouse isn't updated immediately, I needed to run the warehouse task. You can do this by running a web Service on the TFS reporting box:

http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx?op=Run

You'll need to run this web service method from the TFS machine if you're using a browser to run it.

Setting up Visual Studio to Customize Reports

The reports in TFS are built on top of SQL Server Reporting Services, and Visual Studio has a way to edit the reports. However, getting it all set up wasn't exactly obvious. Here is how to set things up so you can edit and test reports.

Download a Report

The first step to customizing a report is to get a copy of the report from the server. There is an article on MSDN with the steps to get a local copy of the report: How to: Locate and Edit a Report. However, this article is missing one important piece of information.

Setting up the Data Sources

The reports on the server that I downloaded uses two shared data sources with specific names. I needed to create these data sources in the Visual Studio project created in the previous step so they would have the same names, as defined in Data Sources for Team Foundation Server Reporting.

In order to set up data sources, you'll need to have access to the SQL Server machine with the TFSWarehouse database. I didn't have access to the production server, but I did have access to a test box with TFS on it, so I set the connection strings to point to the test box. Just right click on the Shared Data Sources folder and select Add New Data Source from the context menu to create a new datasource. Read Data Soruces for Team Foundation Server Reporting to setup the two data sources correctly (both point to the TFSWarehouse database, but they use different providers).

Here is what the project looked like after I setup the data sources:

Modifying and Testing the Report

At this point I could double-click on the Remaing_Work.rdl report file and open it in the visual report designer. The report was initially setup to show only three values that correspond to the three states Active, Resolved, and Closed. Since I added new states to the Task template, I decided to add a new value for each state.

You add new state values to this report by clicking on the Layout tab and then right-clicking on the graph and selecting Properties.

In the Chart Properties dialog box click on the Data tab and then click on the Add button to the right of the Values list box. This will allow you to add a new value. For the value I used a variation of the expression that was already used for existing values:

=Sum(IIF(Fields!State.Value="In Process",Fields!Cumulative_Count.Value,0))

All I had to do was change the name of the state in the State.Value= test. The resulting dialog looked like this:

Test the Report

Finally, if you have the connections setup properly, and have sufficient rights, you should be able to test your modified report on your computer using the Preview tab of the Report Designer. The report should behave exactly as it would if you double-clicked on the report in the Team Explorer Reports folder.

Upload Modified Report

Once you have your report working the way you want, you'll need to upload it back to the server. The process for this is almost identical to downloading the report, except that you'll click on the Update link instead of the Edit link at the bottom of the page:

Here is what the chart looked like when I was all done:

This graph actually shows the before and after. Most of the graph shows Tasks that were based on the three original states, using data saved in the data warehouse. The last two days of the graph show the "Active" state split into two of the new states: "Pending" and "In Process." As we move forward, we'll see even more states appear on this chart.

Simplifying VSTS Test Projects

noreply@blogger.com (John Socha-Leialoha) — Fri, 03 Nov 2006 18:01:00 +0000

Every time I create a new test project, it always adds some files I delete without even thinking. Today a colleague, Alan Ridlehoover, told me how to turn off some options that add these files to new test project.

If you select Options... from the Tools menu, and then click on the Test Project node under the Test Tools node, as shown below, you'll get the settings that allow you to remove these files. I decided to uncheck all these boxes.

"Brittle" Unit Tests

noreply@blogger.com (John Socha-Leialoha) — Thu, 05 Oct 2006 19:52:00 +0000

I have a friend who is new to unit tests and therefore has never done Test-Drive Development. His management has decided that developers should now write unit tests. But there has been some debate about what should be tested. Since his "application" is really a class library, a lot of the functionality is hidden inside the library (the public API is just a small part).

Some of the people he talked to suggested not writing unit tests for the implementation (just test the public APIs) because they were nervous about making the library "brittle". As my friend said, "they define brittle as in it's really easy for someone to make a change and break stuff."

The comment about brittle unit tests is actually very interesting. I’ve encountered that myself. It’s frustrating when I have to go back and update unit tests after doing a large refactoring. It certainly makes the unit tests “feel” brittle. But I think this feeling is a result of changing my approach to development rather than a real issue. I think it can be broken into two cases:

Unit tests fail, showing bugs in my code. This is obviously the “good” case.
Unit tests fail because assumptions have changed. This makes unit test feel brittle. But actually it’s a good thing. They fail because my assumptions or “specifications” have changed. That means I really do need to rewrite the tests to reflect the new specifications that resulted from design changes.

There is another way to look at item 2 above. Often the broken unit tests are a result of bugs in the specifications, so what you're really faced with is having to interrupt what you were working on to fix bugs. This can certainly be unsettling, because it's a brick wall you have to scale before you can continue with your thread of thought. However, since you're fixing bugs as you go, your code will be much more reliable.

Unit Tests for Learning and Experiments

noreply@blogger.com (John Socha-Leialoha) — Wed, 04 Oct 2006 16:45:00 +0000

Very often when I'm learning a new set of APIs, I like to write some test code to try things out. In the past I would create a new Windows Forms project and put some buttons into the form. Then I'd put my test code into the Click event handler for the buttons and use the debugger to step through the code and look at the results.

Not anymore! Now that I've gotten used to using Test-Driven Development to write code, I now write the small learnings as unit tests, or as a unit tests that call some test code in my application. Since unit tests are run without starting up the entire application, they run very quickly.

I put this into practice just today working on some code that uses the XmlSerializer to serialize some of my objects. In this case my unit test is very simple:

[TestMethod]
public void ShouldSerialize()
{
    MapNode first = new MapNode("first");
    MapNode second = new MapNode("second");
    MapNode child = new MapNode("child");
    first.Nodes.Add(child);
    MapNode[] nodes = new MapNode[] { first, second };
    FolderViewpointItem item = new FolderViewpointItem(10, nodes);

    XmlSerializer xml = new XmlSerializer(item.GetType());
    StringWriter writer = new StringWriter();
    xml.Serialize(writer, item);
    Assert.Fail(writer.ToString());
}

Since I simply wanted to see the XML generated, I used the Assert.Fail method to display the XML as the message shown in Visual Studio's output window. Very fast, very simple. And I can use any of the classes in my application to try things out.

How I Learned to Stop Worrying and Love TDD

noreply@blogger.com (John Socha-Leialoha) — Wed, 13 Sep 2006 16:35:00 +0000

I've been a developer for many years, and I've prided myself in writing very reliable code. For example, The Norton Commander 3.0, the last version I wrote, survived for two years without a single maintenance release. One of the key factors that kept me writing reliable code was fear. The fear that I would break the code and create a problem for users. I was always afraid that any major changes I made would break things. So whenever I made a major change, and I didn't let fear keep me from refactoring, I took my time and did lots of testing along the way. Fear was always at the back of my mind while I made these changes, so I really stressed about making sure I didn't make any mistakes.

That was before I discovered Test-Driven Development (TDD). I was introduced to TDD while contracting at Microsoft's patterns & practices group, working on the Mobile Client Software Factory. The more I've used TDD, the more I like it.

I've now spent about a month working on a new project at p&p (more on this soon) and I had an epiphany today. I just realized that even though that fear is still there, it's much less grounded. Yesterday and today I did two major refactorings that before would have required very careful work and testing. However this time it was nearly painless. The unit tests I've written now do that work for me. So when I did the refactoring yesterday, roughly 10% of the unit tests failed. It only took me about 15 minutes to fix the code so all the tests passed. Total time to make the refactoring was a lot less than it would have been using my old, fear-based approach to writing reliable code.

And this morning, to top it off, I just made another major refactoring change. Much to my amazement, I didn't break any of the unit tests. So after about 15 minutes of refactoring, I was done! Long live TDD!

Viewing Compact Framework Source

noreply@blogger.com (John Socha-Leialoha) — Tue, 29 Aug 2006 19:36:00 +0000

Many of us who develop for the Pocket PC have discovered that we can't use tools like Reflector to view to source code for the assemblies Microsoft provides, such as System.Windows.Forms. To see what I mean, try this. Open Reflector and from the File menu, select Open List... This will display the Assembly List Management dialog box, which allows you to create lists of assemblies so you can quickly load the assemblies you want into Reflector.

Next click on the Add button to create a new assembly list. I called my list "Compact Framework 2.0". Click on the Select button and you'll get a list of assemblies you can use to initially populate your new list. I selected .NET Compact Framework 2.0 from the Start 'Compact Framework 2.0' Assembly List dialog box and then clicked on the OK button to add these assemblies to the list.

Now if you open the a class, like ButtonBase in System.Windows.Forms, and display the source, you'll see something like this:

This certainly isn't very useful. Well, my colleague Daniel Cazzulino posted a question about this and got an answer. Now that I think about it, it makes perfect sense that you can't get source from the shipping assemblies. In order to keep the installed size as small as possible, the Compact Framework team removed the reflection information.

However, if you have Visual Studio, it ships with a separate set of assemblies that include all the reflection information. I created a new list in Reflector, but this time I clicked on the Cancel button when it asked me what assemblies I wanted in my list. Then I selected Open from the File and and added the assemblies that were installed here on my computer:

C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\Debugger\BCL

Now I get the source code, as shown here, for the same exact class:

Very nice! Thanks Daniel!

WYSIWYG Blog Editor

noreply@blogger.com (John Socha-Leialoha) — Wed, 16 Aug 2006 17:36:00 +0000

I've a visual guy, so I really like to see what my blog will look like while I'm writing it. I've used some blog editors in the past, but had problems with them. Today I just discovered a really, really nice blog editor, called Windows Live Writer.

What's really cool about this editor is that it works with my Blogger, which is what I use for my blogs. And even better, it pulls down the template that I have on my site and let's me see exactly what my blog entry will look like while I write it. The colors are the same. The borders are the same. Etc. Very cool!

They also have an SDK, so it looks like there is a certain amount of customizing you can perform with plug-ins. I haven't looked at it yet, so I'm not sure what you can do.

New Resource for CAB Developers

noreply@blogger.com (John Socha-Leialoha) — Wed, 16 Aug 2006 17:25:00 +0000

I recently started working on a project based on the Composite UI Application Block (CAB) from the patterns & practices group at Microsoft. I was initially lost and found it was difficult to find topics in the help. Like many developers, I don't like to read the manual before I get started, but it seems like the documentation is written more like a book than a help file. As a result, "topics" in the help file actually contain a number of topics and you have to scroll through looking for something that might be relevant. I also discovered that there weren't that many hyperlinks.

I also discovered lots of really useful information spread all over the net, mostly in blogs. But there didn't seem to a be a single, central source to find information.

Then it dawned on me. A Wiki would be a great place to have lots of useful information about CAB. So over a weekend I setup a Wiki to cover CAB and related technologies.

Please check out the site, and more importantly, please add to the site. This is a community site. Anyone can sign in and edit or add content.

www.cabpedia.com

Creating a Splash Screen in a CAB Application

noreply@blogger.com (John Socha-Leialoha) — Sat, 05 Aug 2006 00:38:00 +0000

We thought about adding support in mobile CAB (Composite UI Application Block) for showing a splash screen at the very start of the application startup, but didn't get around to adding that support. I've just started working on a desktop application based on CAB, so now I'm actually a user of CAB instead of a "developer" of mobile CAB. As it turns out, it's very easy to add a splash screen.

The information below is based on a CAB application created using the Smart Client Software Factory.

Once you get beyond the most basic of CAB applications, it can take a while to load the application. Most applications have splash screens that appear as early in the process as possible and go away once the main UI appears. Here is a simple way you can do this in your own applications.

Create A new Application Class

First create a new Application generic you'll use to start your application. For example:

public abstract class SmartClientSplashApplication<TWorkItem, TShell, TSplash>
       : SmartClientApplication<TWorkItem, TShell>
   where TWorkItem : WorkItem, new()
   where TShell : Form
   where TSplash : Form, new()
{
   private TSplash _splash;

   public SmartClientSplashApplication()
   {
       _splash = new TSplash();
       _splash.Show();
   }

   protected override void AfterShellCreated()
   {
       base.AfterShellCreated();
       Shell.Activated += new EventHandler(Shell_Activated);
   }

   void Shell_Activated(object sender, EventArgs e)
   {
       Shell.Activated -= new EventHandler(Shell_Activated);
       _splash.Hide();
       _splash.Dispose();
       _splash = null;
   }
}

Create a Splash Screen

The splash screen is a form that has something on it, like a bitmap and perhaps some text, like the version number and a copyright. You can also set the border to None so you don't see the usual window. After all, it's shown while the application is loading, so you can't close it yourself.

Change Program.cs

Finally, modify the startup code in Program.cs, or ShellApplication.cs if it was generated by the Smart Client Software Factory, to use this new generic class:

class ShellApplication : SmartClientSplashApplication<WorkItem, ShellForm, SplashForm>
...

Microsoft patterns & practices Mobile Client Software Factory

noreply@blogger.com (John Socha-Leialoha) — Fri, 04 Aug 2006 16:53:00 +0000

I just spent the last 7 months working as a contractor at Microsoft, in their patterns & practices group. They hired me to help create their Moblile Client Software Factory; this project was very rewarding and a lot of fun. They needed an expert on mobile development, which is where I came into the picture. I always wanted to see what it was like to work at Microsoft, and the fact that I live about 1-1/2 miles (as the crow flies) from Microsoft made the transition easy.

This group uses a number of practices that were new to me. All their projects are developed using Agile practices, which includes some of the following areas that were new to me:

Test-Driven Development
Pair Programming
The entire team is in a team room
Rapid iterations

There are more points, but that should give you a starting point. As a programmer, I've always worked in a private office so I could focus and not be distracted. The idea of working in a team environment, without a quiet place to work, was different than what I was used to, but hey, it was a contract. If I'd come into a full-time job where I wouldn't have my own office, I think I would have been very reluctant to accept the offer. After all, I really need my quiet to focus and get my job done. Or so I thought...

Fast forward 7 months. I proposed a new project in the patterns & practices group and got it funded, so I'm now working on a new project under contract. I was offered the use of someone else's office, but I chose instead to find space in another team room. What's that you're saying? Why would I chose a noisy team room over a quiet office?

The answer is a little complicated, but it's also something everyone else here has discovered. None of the people here wanted to give up private offices. However, now that they've experienced the agile environment, they don't want to go back to private offices. There are several reasons for this.

First, the dynamic of a team environment really does provide better shared knoweledge of the project. You feal more involved because you are more involved. And you have a better sense of how all the pieces fit together and what other people are working on.

However, more importantly is the dynamic of pair programming. Here you have two people on one computer. We've done it where we have two keyboards and mice on a single computer. One person writes a unit test describing what the code should do, and then the other person writes the minimal amount of code to make that unit test pass. Next you switch roles. This process produces simpler, more reliable code than you get from a single programmer, and it also makes keeping your energy level high during the project easier.

NUnit and Compact Framework Applications

noreply@blogger.com (John Socha-Leialoha) — Fri, 30 Dec 2005 01:15:00 +0000

I recently learned about Test Driven Development and got really excited. Until, that is, I discovered that my version of Visual Studio doesn't have the great new tools for team development. For that you need one of the Team editions, but at more than $5,000, I wasn't quire ready to take the plunge.

So I decided to try NUnit, which is an open source application for testing .NET applications.And it works, within some well-defined cases.

There are limits to what you can and cannot test using NUnit to test your Windows Mobile applications. Since NUnit is running on the desktop, your unit tests also run on the desktop rather than a Windows Mobile platform (device or emulator). If your testing code that isn't dependent on the Windows Mobile platform, you should be able to write and run unit tests on the desktop because your CF applications classes will load and run on the desktop as long as they don't require PocketPC/Smartphone-specific code (such as PInvoke calls to coredll).

Of course, it would be far better to test your code on the target platform, or at least for some test cases. Right now there is only one test harness I'm aware of that runs on Windows Mobile itself: CFNUnitBridge. I haven't tried this yet, but I'm just getting started with test-driven development.

A resource nightmare on .NET street

noreply@blogger.com (John Socha-Leialoha) — Sat, 03 Dec 2005 02:46:00 +0000

Well, I had a fun afternoon. I have a program for the Pocket PC that I just put into alpha. I've written this program using the .NET Compact Framework 1.1. I of course upgraded my development environment to Visual Studio 2005 when it was released about a month ago, however I continued to use version 1.1 of the .NET CF. No problem.

That is, until today when I decided to change one string in my resource file. Once I did that, I kept getting runtime errors when I attempted to read a value from the embedded string resource. First I got an ArgumentError exception, then I got a TypeLoadException. How could that be? My resource code has been working for a long time and I didn't change a single line of code--I just edited the value of a resource string.

After a number of hours trying different things I finally figured it out. I hadn't edited the resource file in quite some time and, as it turned out, I had upgraded the program I was using to edit my resource files, which were in the ".resource" format. I started using a program called Resourcer back when I was using Visual Studio 2002. Recently I decided to get the latest and greatest version, which was labeled ".NET Framework 2.0.50727." What I didn't know, and which now makes sense, is that the author, Lutz Roeder, delivers three different versions of the same program that bind to different versions of the .NET framework. And each of these versions writes a .resource file tied to the same version of the .NET framework.

So when I modified a string and saved the file, Resourcer overwrote the old .NET 1.1 file with a .NET 2.0 file. When I looked more closely at the strings in this file, I noticed that the type for each string is "System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKey Token=b77a5c561934e089." Notice the version number? When I called the resource manager's GetObject method, it attempted to create a 2.0 instance of the type, but this application is running on a device with 1.1 on it, so the create failed.

But the story doesn't end there. I wasn't able to open this file with a "previous" version of Resourcer because the versions for older .NET frameworks weren't able to load the newer types. Fortunately, I was able to use Resourcer to save the file as a .resX file, which I could then include in my project. In the process, I also discovered that Visual Studio 2005 contains a fabulous built-in resource editor that makes Resourcer obsolete.

ListChanged in PocketOutlook on Windows Mobile 5.0

noreply@blogger.com (John Socha-Leialoha) — Thu, 27 Oct 2005 22:53:00 +0000

I've been working on a calendar application for the Pocket PC. Now that Windows Mobile 5.0 devices are shipping, I figured I should ensure my application works on Windows Mobile 5.0. There is one feature I added that doesn't work anymore--my application doesn't receive notification when the calendar changes. For previous versions of the Pocket PC, I was able to trap changes to the appropriate CEDB property database via some C++ code. However, Windows Mobile 5.0 uses a new, and incompatible, database to store PIM information, so my change hook from before doesn't work.

I was thus very excited to discover Microsoft had shipped a managed assembly for use on Windows Mobile 5.0 that supports receiving change notification. Their assembly, Microsoft.WindowsMobile.PocketOutlook has a number of classes that correspond with POOM (Pocket Outlook Object Model) objects. In particular, the PimItemCollection class contains an event called ListChanged. Perfect! Or so I thought.

Testing this code when changing or adding an appointment using the Calendar application didn't work. What gives? It turns out the ListChanged event doesn't receive change notifications from the operating system. Instead, it only tells you of changes made "to the collection." In other words, if your application uses the managed classes to modify, add, or remove an appointment, your application will be notified. If any other application changes the calendar (or any of the other supported databases), you do not receive notification. In other words, you can use the managed event to keep your application current with the data in the database. This is documented in the Wiki article Windows Mobile 5.0 Managed on Channel 9.

So, I'm back to adding C++ code that will support Windows Mobile 5.0.

Related Articles

What's New for Developers in Windows Mobile 5.0