Troubleshooting NAntContrib FxCop Task Error

I’m working on setting up my continuous integration process for a new application. I’m nearing the end of that work, but one outstanding step needs to be done – getting FxCop working against the code base to ensure good code is being committed.

At first, I set up my NAnt script to simply ‘exec’ the fxcopcmd.exe application. While that worked and I did get my results output to the file system, the NAnt script continued on happily even when I had messages that needed to be addressed. I found a few blogs that suggested that I could parse the return code from fxcopcmd.exe, but it always seemed to return 0 – even when there were messages.

That’s when I decided to use the NAntContrib FxCop task in my script. It’s easy enough to integrate. Simply add a <loadtasks> element that points to the nant.contrib.tasks.dll and then add the <fxcop> task to your script. When I did this, I was stymied by a new error:

Error creating FileSet.
    Request for the permission of type 'System.Security.Permissions.EnvironmentPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Turns out that this issue is caused by a rather simple oversight. When you download the .Zip file that contains the NAntContrib DLLs, you have to be sure to unblock them, otherwise the O/S blocks loading them and hence you get the error above. To make matters worse, when I first extracted the files, I hadn’t unblocked the zip, so of course all of the contained files were blocked. When I unblocked the zip and re-extracted overtop of the existing files, it didn’t automatically unblock them – I had to go through them one-by-one and unblock. Once that nuisance was out of the way, the process began working.

Now on to other more pressing matters

 

[Edit]

After I posted this, I realized that while FxCopCmd was running, none of the results were being saved to the output file and consequently the build wasn’t failing. In order for FxCop to save the results, make sure your .fxcop project has these settings:

<SaveMessages>
   <Project Status="None" NewOnly="False" />
   <Report Status="Active" NewOnly="False" />
  </SaveMessages>

The important one is the <Report Status=”Active”… > element.

Reflecting on a Successful Software Release

What goes into a successful software release? I think to really answer that, it would boil down to a really abstract answer – “It depends.” In this blog post, I’ll give you a quick look at what went into making our most recent release a success.

First a little background …

The project that was just delivered was several years in the making. From concept to delivery took a LONG time. The reasons behind this were numerous; some were technical, but the majority were business-related.

The team members that worked on the project in the early days were not the same members that ended up delivering the solution. A couple of hangers-on were there for the whole duration, but largely it was a new team. Even the product owner from the client side was a new person. The team was also a geographically-dispersed multi-national team with language and time zone challenges.

The project’s development methodology changed over time. The process that persisted the longest and the one that was in place at the time of its delivery was a Scrum-hybrid that was chiefly centered on daily stand-ups. It lacked some of the important best practices that successful Scrum practitioners rely on. For example, it wasn’t until the last few weeks that the team had a well-defined and prioritized backlog.

Key Drivers for Success? I’ll give you the top 3 reasons – at least from my point of view, which was as a latecomer to the project.

The background of the project paints a pretty challenging picture for any team that finds itself facing the pressure to deliver a product. And this is certainly true for the team that delivered our product. So what made it possible to pull this off?

#1 Reason – Commitment

The team that delivered the project to the satisfaction of the client was determined to make it happen. Everyone involved knew the stakes and knew that success depended on each of their individual contributions to pull it off. I’ve been involved with projects in the past and almost without exception those that failed to deliver, or at least to deliver on time, were a direct result of a lack of personal commitment from the entire team.

#2 Reason – A Spirited Team Leader

I’m convinced that what brought the team’s commitment into focus and pulled things together at the end was the efforts of a new Scrum master. The team’s newest business analyst was a success catalyst. Her efforts to wrestle the last set of features and defects into a manageable backlog and focus the team’s efforts onto the right areas was a critical piece of the puzzle that helped the team cross the finish line.

#3 Reason – A Little Bit of Luck

Let’s face it, the project background that I gave at the beginning set the stage for another disastrous failure. However, as luck would have it, a number of events came about near the end that made success possible. For example, a new product owner became more engaged near the end and helped to focus the attention on must-haves. The team gained some new members that had experience with delivering results. They pulled together with the original team members and raised the bar for everyone. And lastly, the work of the team was largely usable and had relatively few “big ticket” issues. Had there been some time bombs that were unrealized by the new team, it could have been a very different result.

What was missing that would have made things better?

My top two things on this list are pretty solid in my mind: First – A well-groomed product backlog with priorities set by the product owner. Having that view gives the team a picture of what defines success. Anything short of that and it’s like shooting at a moving target. Second – Team continuity. Churn on a team can be a killer. When people leave they take with them something that can’t be underestimated – knowledge. If that person is a pivotal person on the team it can spell doom. Sometimes that knowledge can be rebuilt – other times not. Reduce your churn to improve your team’s velocity.

So what now? Well our team held a retrospective where a lot of great feedback was gathered and plans were made to put things into place to fix things. We’ll be relying on Scrum best practices to help guide our new process and hopefully will help reduce or eliminate some of the challenges earlier in the cycle.

Good luck on your next project!