views:

317

answers:

3

I have been looking at a few of our VB.NET dll's using FxCop and all of the errors relate to DLL setup (i.e. Strong Names, Culture Info) and the case of Variables methods.

Looking at a few examples of FxCop examining a C# Dll, it appears to offer a lot more potential errors.

Does this mean that FxCop is more valuable on C# developments that VB.NET or have I just chosen bad examples.

I thought it was the case that FxCop worked on IL rather than the specific languages, so am I just missing rules files for VB.NET or are there more available for C#?

+6  A: 

I would say that's not correct. FxCop is invaluable to any .NET developer.

You need to show an example of where you get more (or less) output from FxCop for a piece of VB.NET code, versus a piece of C# code, both of which compile to the same IL.

casperOne
+1  A: 

As far as I am aware, FxCop is language agnostic. It is more likely that C# has more freedom than VB.NET in various areas allowing for more mistakes to occur (as FxCop interprets it) rather than FxCop being biased somehow. If this is the case, then I can see it being more valuable to a C# developer than a VB.NET developer as the former language has more scope for creating issues that FxCop can detect.

However, FxCop is an invaluable tool for any .NET project, even if some languages make it harder to make mistakes.

Jeff Yates
A: 

FxCop is supposed to work on compiled code, so the language you write in shouldn't matter. I've used the tool on projects with either C# or VB, so it does indeed work. It has been rather helpful, actually.

Grant Palin