Flaw in SolutionContexts.GetEnumerator

I’m guessing that this post will be useful to a very small number of people if at all. However there might be a bigger lesson here for people writing their own collections and that is how not to code GetEnumerator method.

but first some background information.

when working with a visual studio add-in I needed find out weather a specific project is excluded from the build cycle.

the DTE provide interfaces and object to access this info and the code I ended up with looked like this:

   1: foreach (SolutionContext context in 

   2:    ApplicationObject.Solution.SolutionBuild.

   3:        ActiveConfiguration.SolutionContexts)

   4: {

   5:     if (context.ProjectName.Contains(project.Name))

   6:         return !context.ShouldBuild;

   7: }

However, this code resulted in an exception popping from time to time which took me a little while to understand.

the exception I got was :

System.ArgumentException
The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))
System.Collections.IEnumerator GetEnumerator()
at EnvDTE.SolutionContexts.GetEnumerator()

where the line number pointed to the foreach statement.

After some digging I found that this happens if in the solution you have an unloaded project as part of the solution. and the fix was quite simple jut replace the foreach with a simple for resulting in something like:

   1: var contexts = ApplicationObject.Solution.

   2:    SolutionBuild.ActiveConfiguration.

   3:    SolutionContexts;

   4:  

   5: for (int i = 0; i < contexts.Count; i++)

   6: {

   7:     try

   8:     {

   9:         var context = contexts.Item(i + 1);

  10:         if (context.ProjectName.Contains(project.Name))

  11:             return !context.ShouldBuild;

  12:     }

  13:     catch (ArgumentException)

  14:     {

  15:         //this is thrown when a project is unloaded

  16:     }

  17: }

  18: return false;

Now I can understand why an unloaded project will throw an exception if you try to access its configuration data. What I don’t understand is why they didn’t handle this inside the GetEnumerator and instead choose to crash it as well.

I think this is a mistake, in general if a piece of the information is missing don’t fail the entire operation just exclude that piece from the result. that way you will enable the user to decide what to do with the info he does have.

what do you think?

Read more »

Posted in: IDE

Don’t you love useful error messages?

Ok now what?

Read more »

Exporting Code Metrics from Command Line

A couple of months ago Microsoft released a tool enabling to gather code metrics on code form command line. (detailed post here).

While it took me some time I’ve updated my Msbuild custom tasks project and added an Msbuild task for better integration of the tool into a build cycle.

The task enable the exporting of metrics for a given solution and includes an xsl to transform the resulting xml into an html report.

(older tasks in the project allowed running all tests (using mstest) in a given solution and exporting VS coverage report to an xml)

To download the latest release go to here, and if you have any questions or additional requests contact me either through the CodePlex forums or directly.

Read more »

Posted in: MSTest,tools

Presenting at Sela’s Developers Days 2011

Towards the end of June I’ll be participating in Sela’s “Dev. Days” conference. Unlike other conference, “Dev Days” event is a collection of 1 full days workshops that will be given over the span of an entire week. During this week there will be 25 different workshops in various subject aiming at beginners and advanced Developers alike.

My part in this event will be 2 workshop that I’ll be having:

1. Introduction to Scrum

At this workshop ill be going over the principles of agile. I will show the basic Scrum process and technique and will demonstrate the key differences between Agile way of doing things and classical waterfall approaches.

If you are want to know what the agile buzz is all about I really recommend attending this day.

2. Introduction to Test-Driven Development

TDD has established itself as one of the leading practices in the Agile community. However there are several obstacles in actually starting to TDD. The goal of this day is to give all participant a good starting point for actually starting to code in the TDD style.

If you ever wanted to give TDD a go, but always found it hard to start. Maybe this day will get you going

2 other related workshop that might be of interest in the context of agile and testing are:

Team Foundation Server 2010 and Visual Studio 2010 and Visual Studio 2010 Testing Tools. but of course the week has many more very interesting workshops. for the full agenda go here and if you want to register follow this link.

Read more »

Posted in: Conferences

My Presentation at “QA and Development in Agile”

This is the presentation I gave last week over at the “QA and Development in Agile” conference (including some extra slides the I didn’t have the time to go over). Unlike other presentation this one was solely process related and not about any tool so I hope everyone enjoyed it.

The main pint o the talk was that its more important to optimize the team feature throughput than the team utilization and I hope I managed to get it across.

Scrum Project Management

Would you like hear me present? Contact me!

and in any case would love to get your feedback on the experience.

Read more »

Posted in: Conferences,Scrum

Moving from Fix price to Agile Contracts

One of the major roadblocks in an agile transition is the fact that when adopting an agile approach fixed price, fixed content contract does not make much sense anymore.

sure, some organizations are succeeding in doing agile under such contracts but one of the promises of Scrum is to be able to easily cope with changing requirements, and change the work plan to contain the most valuable features seen at that time.

On the other side, after so many years working under fixed price,fixed content contract its really hard to change especially since much of the time the other side (the one paying) is not really involved in the decision to adopt agile.

Its all about risk

a couple of weeks ago I had the chance to talk Giora Morein during a conference, after a while we started talking pricing schemes at which point Giora pointed out that when working under a fixed price contract, the risk involved is mostly placed on the side providing the services, while when using an hourly/daily rate most of the risk is taken by the paying side.

I believe that this fact is part of the problem we face when trying to adopt to an agile contract. The problem is how to convince a customer that is used to having the risk placed at the supplier to accept the risks involved in committing to a project under a flexible budget and content.

Moving Into an agile Contract

The first thing I found useful when I try to switch to a flexible more agile contract, is to start by acknowledging this fact. I than counter to with the benefits of such a move, focusing on the benefits the client will see.

In many cases this is not enough and the customer will still choose to use the same fixed price, fixed content agreement and in this situation I found the following steps to be very useful to establish a level of trust needed to actually change the working contract.

In order to actually change anything the first order of business is to sort all requested features by order of importance. In most cases this is grasped by the client as a reasonable request and it opens several channels of communication whiled doing so. its very important that the client will be involved in this as much as we can since this phase build the basic understanding both parties can build upon later on.

Second I try to add the following key points to the contract

(since all this points are actually controlled by the client most have no real objection to include them in the agreement):

1) Scope can be changed - The client can swap any requirement/feature by a new one of similar size, as long as it conforms to the basic priority scheme.

2) Priorities can change - by the client at any point of time. These changes will be reflected to the work plan (excluding things which are currently under way).

3) The client can take a working version of the work so far. In fact he is encouraged to do so and provide any feedback he can n it.

4) Termination - at any point of time (subject to a reasonable fee – I use 25-30% of the remaining cost) the client can terminate the project taking all the work done so far.

I have tried this scheme on a couple of occasions and found that after a few times the client actually invoke any of this clauses. He usually see the benefits involved in such an agreement and the next time he actually insist on this ability and is much more open to a working under an “agile contract”.

Read more »

Posted in: Agile practices,Scrum