In previous versions of Visual Studio, there was a single entry point to an extension (more specifically, an addin), the OnConnect method. From there it was possible to perform all the Visual Studio operations, such as adding menu items, and setting up a global exception handler, to gracefully handle unhandled exceptions.
In Visual Studio 2010's VsPackage, things work differently - many parts of the application (such as IWpfTextView) are composed by MEF and loaded without the explicit control of the package, making handling any exceptions coming from those very difficult.
Without explicitly wrapping all such components in a try..catch of their own, how can I efficiently implement a global handler for (non-critical) exceptions in my VsPackage?
Again, the goal is having something like ReSharper's exception dialog, where it can handle global exceptions without crashing the Visual Studio.
I have investigated this topic by reading official VsExtensibility forum and according to this and this threads there is no such one place to hook for catching all exceptions. So typical solution will be to use try... catches everywhere.
I suggest to use one of the AOP frameworks like PostSharp to accomplish this with attributes in order to eliminate tons of crappy duplicated code that's only purpose is to handle unhandled exceptions.
Related
I have a solution with about 10 separate projects or libraries. One of the libraries is maintained by someone else.
I've set my preferences (under Debug > Exceptions) to break on selected types of exceptions when thrown (rather than user-unhandled), but I'd like to not break when it occurs within this particular library.
I've looked at the Debug tab on the project properties, but there does not seem to be a way to exempt it from breaking on exceptions. Most of the exceptions that occur within this library are handled by try/catch.
I'd like to debug only the project that relies on this library, but not constantly break on exceptions that occur within it. Is there any way I can exclude it from exception breaks?
I am trying to use set up a CI server that doesn't depend on a Visual Studio installation but uses msbuild instead. Our solution includes an interop project. Visual Studio handles this project just fine, but msbuild seems to have a problem with events like this one, taken from an interop user control which inherits from System.Windows.Forms.UserControl:
Public Shadows Event Click() 'Event must be marked as Shadows since .NET UserControls have the same name.
The error I get from MSBuild is this:
error BC30029: Derived classes cannot raise base class events.
I read this, but my Event statement and RaiseEvent statements are already in the same class (the one from which the above error is being thrown). I don't think this solution applies to my situation.
What's the best way to get around this? Let me know if you need more information.
Thanks.
I experience a strange behaviour in Visual Studio 2010 when creating Windows Phone 7 apps. After some time VS starts to complain about Invalid XAML although there is no problem and the app compiles and runs just fine.
It bugges me because I cannot use the visual desingner saying "Exception was thrown on "DataTemplate": Invalid XML" and there is a DataTemplate higlighted in the code. The data template is always ok, VS does not complain about it when copy-pasted to another project.
I found out that problematic are usually the DataTemplates with custom converters or when usin g classes like PhonePerformance.
Sometimes the error is "Exception thrown was due to document error: Invalid XML" and nothing is even highlighted in the XAML file.
I tried reinstalling .NET. Visual Studio etc. and the problem occurs on two separated machines so I do not think it is specific to my configuration. It may be specific to my code.
Anyone experienced similar behaviour?
When using XAML, if you reference a library that needs to be evaluated but can't be at design time you get this kind of error. You can turn off the visual editor and just work in XAML - that will stop the error (and save you time).
You reinstalled .NET and VisualStudio??? You should have just spun up a second instance, opened the solution in both, then attached the debugger from one to the second and opened up the visual editor. It would have told you exactly what in your code was causing the problem. Also DesignerProperties.IsInDesignMode in your converters. Jeez. You wasted so much time :(
As for design time data, that's tricky. Either you have DesignTimeDataWithDesignTimeCreatableTypes that aren't or DesignData that can't create proxies for your real types (for whatever reason, had this issue many times deep in the past).
The only way to figure this out is to debug one instance from another. Its actually not that hard. I do it alot (debugging WF4 ActivityDesigners).
A friend has found a solution and you would not believe where the problem is. This happens if you have a space in the name of your assembly. I found out that I really have a space in assembly name in all the problematic projects, renamed the assemblies and the designer works again.
The solution is also mentioned here http://forums.silverlight.net/t/115011.aspx/1
Custom Compiler Warnings and
C#: Create custom warning in Visual Studio if certain method is used in source code
haven't helped as they deal with code that is under the author's control.
We are using a 3rd party suite of UI controls (DevExpress) in our software and I want to generate a warning when someone uses MessageBox.Show("blah"); instead of XtraMessageBox.Show("blah");
Is there a way to do that?
This sort of thing can be addressed relatively easily via a custom rule for FxCop/Visual Studio Code Analysis. If you are using Visual Studio Developer Edition, you will even see the rule failures displayed along-side your compilation warnings and errors in the IDE.
While there's no way you can do real custom compile-time error in .NET, there's a number of third-party tools (both free and commercial) that can inject their validation logic into the build process, usually after the compilation.
Here are three ways I know of to solve you problem:
Resharper 5.0($) will support custom rules / warnings.
In PostSharp(free) you can define OnMethodBoundary aspect, overwrite its CompileTimeValidate method and emit a [post]compile-time error from it.
NDepend can be integrated with your build process ($) to enforce coding policies like that
No there is no direct way. If you think about it you are looking for a compiler warning for some code that you don't even compile.
If you really want this you could use Reflection methods on YOUR compiled assembly to check if any methods/assemblies you don't want have been called. Cecil has a lot of the functionality you need. You could then make this part of your build process.
I have some code which generates a large quantity of ArgumentExceptions on one particular line (which is in a different developer's code, so I can't just change it), which are then caught and handled appropriately.
I'm trying to debug ArgumentExceptions which are happening in a different section of code (and are then caught and handled, so I can't just look at unhandled exceptions).
Is there some way to ignore the ArgumentExceptions originating from that particular other line of code, while still breaking on ArgumentExceptions which are thrown elsewhere?
You might be able to do this, but it depends on how the code you want to debug is located relative to the other developer's code, and whether or not you can modify (but not commit your changes) to his code.
The first thing you'll want to do is, at least temporarily, go to menu Tools -> Options -> Debugging in Visual Studio, and tick the "Just My Code" box. I assume this is available even in Express editions, but it may not be, and if it's not available for you I'm afraid the rest of what I have to say probably won't help.
Anyway, once you have that ticked, you will no longer see break-on-throw notifications for code that isn't "yours." This means code that is from an assembly not in your .sln, or code marked with the [DebuggerNonUserCode] attribute from System.Diagnostics. What I usually do then is temporarily decorate the offending methods with [DebuggerNonUserCode] until I'm done debugging what I need to debug, and then revert those changes before checking in to souce control.
It's not as elegant as I'd like (I'd love a "never break on throws from this site again" checkbox in the exception assistant), but it's better than nothing.
I believe there may be other debugger settings that could interact with how "Just My Code" works, so if this doesn't work for you let me know and I'll try to get a more accurate picture of what my settings look like when I do this.
If you are talking about the "Break On Throw" exception feature then no there is not. It is strictly a type based feature only and does not have any way to control for what section of the code throws the exception.
Your best bet is to just place breakpoints on all of the lines which throw or temporarily suspend throwing an exception from the one place that you care about.
If you know how you are calling it, I would set the break point in your code and then step into (F11) from there. You could also smack the programmer until they fix their code, which would have the effect of making you feel better (unless you are a pacifist) and maybe they won't have so many ArgumentExceptions in their code (which would probably make you feel better even if you are a pacifist).
Sounds like using exceptions as flow control. If the one you're trying to debug occurs later in the program, you can try to attach the debugger later, or you can wait until after the program is running to turn on breaking when an ArgumentException is thrown.
Try to limit the scope as well - if the exception you're interested in derives from but is not exactly ArgumentException, break on that one instead.
Tell the other developer to fix his code.
Edit: In .NET 4, you can attach a handler to the AppDomain.FirstChanceException event, filter out non-ArgumentException excepitons and filter out the bad one based on the call stack.
The links in the comments are great.
i think Conditional Breakpoints are what you're looking for here. You can do this by right clicking your breakpoint and clicking the Condition... menu item.