Well, all those
A first chance exception of type 'System.ArgumentException' occurred in MyAssembly.dll
messages in my Immediate window during the debugging annoyed me for a long time. Today, I said: enough! There must be a way how to tell VS not to show them.
Recently, I was asked an interesting question. How to get search results of Find In Files operation in VS? You can get these results quite easily from your macro or add-in. The trick is to read the contents of Find Results 1 or Find Results 2 window, whichever was used to show the results. So, the first thing is to determine which of them was used. We do it right after manually performed search from menu or our call of
DTE.Find.ResultsLocation property will tell us this. Then we find the window and get its content.
The whole code which gets results of the last Find In Files operation is:
If you want to get rid of that annoying macro tooltip in system tray, just follow this Visual Studio Macro Balloon article.
You surely know what I'm talking about. We often need to run and test simple code chunks or only one statement while we are coding. It may be very annoying to run main project every time we want to test our new five lines long function. Fortunately, there are better ways to do it.
Here are all options that I have found:
- As already mentioned, place the code snippet to your main project. For example, you can insert it in some button event handler and then test it by pressing the button. This is cumbersome and time consuming.
Don't place it in your main code. Just run the main code in debug mode and pause it, e.g. with breakpoint. Then open immediate window and test your expression. This has one big disadvantage, you cannot declare new variables or functions in immediate window.
The two previously mentioned methods have one disadvantage. You cannot do it at design time, you need to run your project. (UPDATE: You can use Immediate window in design time in VS 2005 and higher. In VS .NET 2002/2003 you get "The expression cannot be evaluated while in design mode." error.) Or you need to have opened dummy project in separate VS instance. The following two solve this problem.
- Use Macro IDE. This is my favourite approach but it only works for VB .NET. As you already know, VS macros are nothing else than VB. NET functions So, just create macro with name "Test" and insert your code there. Then you can run it or debug it.
- Use Snippet Compiler. It compiles code snippets and works with VB .NET and C#. While it's not VS add-in but standalone application, you can still call it from VS. Just define it as external tool in Tools - External Tools. You can also place it on the toolbar or menu or even right-click context menu the same way you do it with built-in commands and macros.
I must say that I ignored Trace object and TRACE compilation constant for long time. I've been only using Debug object and DEBUG constant for debugging purposes.
Recently, one user of our VSdocman encountered strange problem which I couldn't reproduce. We all know it. So I created special tracing build for him which logged all important activity, variable values and obviously exceptions. The problem was isolated and fixed in one day.