views:

217

answers:

2

VB.NET has this rather annoying limitation which caps compiler warnings reported at 100.

vbc : warning BC42206: Maximum number of warnings has been exceeded.

This makes things rather frustrating when trying to size up the amount of effort that would be required to comply with VB.NET best practices, such as enabling Option Strict.

Is there any way where this limitation could either be removed, adjusted, or could warnings be gathered by some other means (such as through a 3rd party code-analysis tool)?

+1  A: 

You should read Configuring Warnings in Visual Basic and How to: Enable or Disable Compiler Warnings

For example, you can to the compiler options (under the project build properties) the following line

warnaserror:42206

this should (I haven't tried it myself...) disable your 100 errors limit.

On another note, 100 warnings is a very large number. You should probably go over your code, check and fix the reasons to those warnings.

Am
Please note that the goal of this question is to size up the number of warnings so that they can be fixed. However, I do not know if my total warning count is 101 or 101,000. While these articles talk about how to enable or disable specific warnings, they do not address the warning cap, which applies to all warnings. For the record, I do have all warnings enabled.I did try the compiler options above, but unfortunately without success.
Technobabble
Haven't found a better solution. sry.
Am
I have looked for this without success. When you make some major changes to a large project, it can be simpler to fix the errors based on error type rather than the first 104 errors VS desides to display. You can use a search instead, but it doesn't work as well as clicking the next error.
xpda
you can try using something like [ReSharper](http://www.jetbrains.com/resharper), it does code analysis and can identify most of the errors before you compile
Am
Resharper only does code analysis for C# I believe, not VB
MarkJ
its for VB as well.
Am
+1  A: 

The official answer is apparently "No." From Microsoft: "While this issue does exist, the Visual Basic Compiler Team has decided to leave the hard limit to the reported errors because it helps with performance."

xpda