I added a new console application project to my VS2012 solution.
When it encounters an exception, I get an error dialog, and VS2012 does not break and go to the source line that threw the exception.
The original project that was created together with the Solution does break on exceptions properly, so I think the issue is that the newly created executable is not marked as relevant for breaking on exceptions. (The debugger is "not attached"? I'm not sure if this is the right term)
How can I make VS2012 start breaking on exception in a project?
I am using the Debug configuration, the pdb is being generated.
There is an issue with recent x64 Windows systems when they do not propagate exception properly back to the x64 application when function calls cross kernel boundaries.
There are plenty of posts here on SO and all over the internet about it, for example the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64
You can fight it to some extent by going to Debug->Exceptions and flagging CLR exceptions Thrown column. But note that then VS would break even on the exceptions handled by you.
Related
I just updated Google.Apis.Drive.v2 to version 1.16.0.609 and right after that started getting runtime exception "missing Microsoft.Threading.Tasks.dll". I put all the logic in regards to the google drive access into a separate assembly. I have an application referencing that assembly. Microsoft.Threading.Tasks.dll is really missing from that assembly and from the application.
I managed to fix it adding nuget Microsoft.Bcl.Async to the application but all that looks way too strange. First of all the application is UWP application and technically Microsoft.Threading.Tasks.dll shouldn't be necessary to it at all. Another thing is even if it is necessary for some reasons why it is not picked up as Google.Apis.Drive.v2 nuget dependency?
I am running Visual Studio 2015 on a Windows 7 laptop, and every time I start up an application in the IDE's debugger I am presented with the following exception:
Unable to find an entry point named 'EventSetInformation' in DLL 'advapi32.dll'.
I have found reference to this in the coreclr repository on github indicating this is an API that was added in Windows 8. My case is similar to the github issue, and I can click 'Continue' to ignore the exception and my applications run just fine. However, this is really annoying because I can't just start debugging apps without waiting for this exception to get thrown so I can manually continue past it.
My question is whether anyone knows if I can prevent this exception from breaking in the IDE? This situation is just a nuisance at the moment, but one I'd love to get rid of.
For reference, in this case changing the Exception settings within Visual Studio doesn't seem to change the behavior. Here's screenshots for both enabling and disabling CLR exceptions, along with the exception:
CLR Exceptions disabled
CLR Exceptions enabled
Solution
This is caused by a general debugger option that seems to override any exception-specific setting. As indicated by #John in his answer below, there's a debugger option you disable to stop this behavior. When this option was checked I would get the break point described, but un-checking it stops that and provides what I was looking for:
By the looks of your screenshots, I would guess you have enabled the Debugger option "Break when exceptions cross AppDomains or managed/native boundaries". Go to Debugger->Options and uncheck that option (3rd from the top)
A co-worker just hit this issue and he had to check the 'Enable Just My Code' box found in Tools -> Options -> Debugging -> General along with clearing the check on 'Break when exceptions cross AppDomains or managed/native boundaries'.
See this screenshots, I have enabled the Debugger option "Break when s cross AppDomains or managed/native boundaries". Go to Debugger->Options and uncheck that option . Its work fine.enter image description here
I've found a topic describing NullReferenceException in Windows Phone designer, however I believe this is a somewhat different issue, since it happens in all platforms and not related to MvvmCross plugins.
Designer (VS2012, Store/WP8/WPF apps) works fine for earlier versions of MvvmCross. I tried to compile a version that corresponds to 3.0.6 NuGet packages, and I can see that design-time model is loaded in all platforms.
Recent MvvmCross version causes all designer to raise NULL reference exception ("Object reference not set to an instance of an object") on all platforms.
Attempt to debug a VS instance didn't help: the call stack doesn't say much, and there is no MvvmCross code there.
The error is not related to the actual view/view model: I can remove all controls from the view, and the error is stil raised. The view model constructor code is never reached.
So it looks like there's some MvvmCross code (not from MvxView) that is unsuccessfully executed in at design-time. I wonder if this is a known issue and/or if there is a workaround to get designer work.
UPDATE. I created a GitHub issue with steps to reproduce the problem: https://github.com/slodge/MvvmCross/issues/347
This question moved to GitHub where there was lots of discussion and a few samples - https://github.com/slodge/MvvmCross/issues/347
From these samples, I believe we concluded the Nuget release 3.0.8.1 :
supports time data based on Blend-generated XML data files
supports design-time data based on simple C# classes
does not support design-time data where the data uses MvvmCross MvxViewModel as a base class
It isn't entirely obvious that developers should want to do the third thing (designtime data isn't real data?), but given that the overall MvvmCross manifesto broadly speaking aims to enable developers and to give them choice, then future MvvmCross will make this easier in the future.
In the meantime, if anyone wants to initialise objects at design-time, then there are a few helper classes around to enable this.
For example, the color plugin (and a small part of MvvmCross IoC) can be made available in the design-time environment using the MvxColorDesignTimeHelper - see:
https://github.com/slodge/MvvmCross/issues/323 (linked to MvvmCross throws NullReferenceException in Windows Phone Designer)
https://github.com/slodge/MvvmCross/blob/TibetBinding/Plugins/Cirrious/Color/Cirrious.MvvmCross.Plugins.Color.WindowsPhone/MvxColorDesignTimeHelper.cs
https://github.com/slodge/MvvmCross/blob/TibetBinding/CrossCore/Cirrious.CrossCore.WindowsPhone/Platform/MvxDesignTimeHelper.cs
After installing .NET 4.5 beta, I noticed that my calls to Assembly.LoadFrom with a network path succeed without explicitly specifying "loadFromRemoteSources=true" in the application configuration file (whereas with .NET 4.0 this used to result in "System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.")
I wonder if this, if it indeed is new behaviour and not something special in my setups (I've not yet decompiled the respective reflection classes or debugged the loading process to examine the differences), is an intentional change in policy and will remain in the RTM version?
The docs don't seem to indicate this change in behaviour. http://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx. And I would have expected a notice of it.
If it does work this way, then you're granting full trust by default and invisibly to a potentially dangerous assemblies and I can't imagine that would be the order of the day.
Have you got it added to machine.config per chance?
Also I would create a small program and target it to the 4.0 platform and induce this exception. Then I would retarget it to 4.5 and see if indeed it's true. Then I'd move the binaries to another machine and test there.
I am using Visual Studio 2008 Express and am writing unit tests where there are many expected unhandled exceptions. This cause numerous exception assistant popups to display when running these tests in the debugger.
I have disabled the exception assistant in the VS options, but a different unhandled exception dialog pops up instead. I know it is possible to get rid of these with Visual Studio Professional, but how do you do this with the express edition?
By the way, I am using Assert.Throws instead of the ExpectedException attribute (NUnit), which causes this, but I want to use the Assert.Throws instead. Thanks!
In the Debug menu, go to Exceptions (Ctrl+Alt+E). From here you can tell the debugger not to break when an exception is thrown. Just uncheck all the boxes for the lazy option, or go digging for the specific exceptions you don't want it to break on.
Note however, that this may not be what you want to happen under normal debugging situations, so don't forget to turn it back on later if you're trying to debug something & want to find the exception.
Edit: My apologies, even though it's written several times in the question (including the title), I failed to notice you were talking about the express edition... teach me for skim reading the question. Not sure if the above works or not in express edition, so it might still be worth a try.
Edit 2: Ok, looks like the Exceptions dialog is still available in express edition.
I'll take a guess that you're encountering one of the following:
You're throwing a "special" exception like StackOverflowException that the runtime handles differently from other exceptions.
Your test code creates a new thread, and on that thread an exception is thrown.