views:

450

answers:

1

I have a large solution which contains a mixture of C# and VB.Net projects.

If I get compilation errors because a project which several other projects depend upon fails to build, it is very hard to see the actual error(s) because of the number of VB errors in the error list window in Visual Studio. C# errors found in the projects I compiled show in the error list, but all VB errors appear (including in those projects I have not just compiled).

Is there any way of turning off this behaviour so that VB errors only appear for projects that I have explicitly compiled?

(I'm using Visual Studio 2008 if that makes a difference).

+3  A: 

Unload all the projects other than the one you're interested in. When that's building, reload the projects one by one and fix their problems. To unload a project, right-click in Solution Explorer and pick "Unload project". This won't remove it from the solution, just unload it - and only for you (not other users) IIRC.

Obviously this means the "lowest" dependency (the most common code) needs to be fixed first.

Alternatively, click on "Project" in the error list to sort by project, and then just look at the errors in the project you're interested in.

Jon Skeet
I've done that in the past, but it seems a bit overkill to do that (I have 82 projects in the solution) on so many projects. I am hoping there is a setting/config option/registry hack somewhere I haven't found that will just alter the behaviour of the error list.
adrianbanks
t looks like there is no way to do turn off the errors. There is a MS Connect issue regarding this (at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=105173), but MS seem to indicate that it won't be addressed.
adrianbanks
82 projects in a solution? It sounds like *that's* the biggest problem to start with... I don't think VS is really designed to be used in that way. I'd start worrying at more than about 20 projects in a solution...
Jon Skeet
Yeah I know. I'd like to reduce the number of projects massively, but it's all about finding the time to refactor them together and sort out the dependencies to keep the auto-build working.
adrianbanks