Case When Open Source Development Tools Are Better
Tuesday, May 12, 2009 at 2:42 in Integration, Mono We are currently using Microsoft FxCop utility as part of the continuous integration process. It statically analyzes managed .NET code assemblies and reports any potential design flaws or issues.
This tool is not the most flexible one to extend, but it is a nice one to get better insight in the code without wasting a lot of time.
Howether, today I had to disable FxCop for one of the projects because of its issue that has shown up. FxCop fails when a highly specific situation is met: when introspection engine encounters generic extension method overload with a constraint that comes from a referenced assembly.
If FxCop was an open source product (like it's Mono equivalent called Gendarme) then I could've tried to quickly fix the issue, submit the patch and use locally built version till the next release.
That's how it was done before with some issues in CruiseControl.NET or NAnt.
However, FxCop is a closed-source product from Microsoft. So there are only two options available:
- disable FxCop analysis in the continuous integration build script and wait for undefined amount of time till FxCop team fixes and releases the next version;
- switch to Mono Gendarme.
I've picked the first option so far, but the second one keeps on getting more attractive.
Related links:
Reader Comments (2)
Unless the company is JetBrains, I reported a bug and it was fixed in 7 hours, available in their nightly build.
Still, it wasn't as fast as the fix you did for me on Autofac, one hour from my sent email to the download being available, not too shabby :P
Yes, JetBrains is one of the companies that I really admire out there for a number of reasons.
Re Autofac: The funny thing is that the most of the time was spent on just going through other container implementations and checking how they have managed to preserve the stack trace.