How can my visual studio addin detect compiler errors before building in the same manner as "Remove and Sort Usings"?

I'm making a refactoring tool that automates a few of the more trivial code styling things dealing with StyleCop. One of the things I'd like my add-in to be able to do (as an optional feature the developer can turn on/off) is automatically call the "Organize Usings -> Remove and Sort" functionality. This is a simple macro call.

However, my problem is that as I go through and recursively call the macro on every .cs non-designer file in the solution this particular macro checks for errors before execution. If there's a synt开发者_如何学Cax error and my add-in starts calling that functionality, it throws up a dialog for each and every file.

What I'd like to do, is use the same method that function uses for checking for errors on the fly and then if there's an error that would cause the dialog to pop up, simply pop up a one-time notification and skip the calls on each file.

I know my add-in could check the error list, however I've found many times that errors that trigger problems in "Remove and Sort" don't always appear in the list. I've had the list be empty, then I try "Remove and Sort" and it tells me there's build problems. I then build the solution and sure enough it fails and the errors are populated. The only solution I'm seeing is to use the same functionality as "Remove and Sort" to check beforehand.

Does anybody know how I can detect compiler errors before building in the same manner as "Remove and Sort Usings"?

I'm not exactly sure what kind of errors you are talking about, I'll assume they are the ones that the IntelliSense parser generates. Yes, that parser isn't very reliable. It is not meant to be a full-blown C# parser, it was optimized to do a very different kind of job: providing context-sensitive help even if the code is incomplete and cannot compile. There isn't anything you can do to make it more reliable, other than waiting for the next VS release perhaps.

But it strikes me that you might be trying to fix the wrong problem. The key issue is that your add-in appears to be removing using directives that should not be removed. A real fix is to improve your code analysis engine so it reliably detects true namespace dependencies. Trying to guess which ones matter from hoping that IntelliSense is going to complain is only going to frustrate your customer.

It seems hacky, but unless somebody can come up with a better solution I'm gonna use a check on the errors list because it's better than nothing.

Additionally I think I may experiment with putting a timer around the call to "Edit.RemoveAndSort" and if it takes over a certain amount of time, pop up a one-time dialog mentioning that it looks like RemoveAndSort is having problems and asking if the user wants to cancel, or at least not call remove and sort.