Develop Reference

How to Debug "Source Not Available" WPF error

I have a WPF application that has started failing with the following error at start:
System.InvalidOperationException: ''{DependencyProperty.UnsetValue}' is not a valid value for property 'BorderBrush'.'
This exception was originally thrown at this call stack:
[External Code]
This is not very forthcoming about what has caused the error. I have tried turning on the CLR Exceptions and restarting as per This Page, but it did not give any more information; I turned on the disassembly, but don't understand what it means. Turning on "Just My Code" debugging and all the Exception Settings as per this page got slightly more in the exception stack trace:
System.InvalidOperationException
HResult=0x80131509
Message='{DependencyProperty.UnsetValue}' is not a valid value for property 'BorderBrush'.
Source=WindowsBase
StackTrace: at System.Windows.DependencyObject.GetEffectiveValue(EntryIndex entryIndex, DependencyProperty dp,
RequestFlags requests)
This exception was originally thrown at this call stack:
System.Windows.DependencyObject.GetEffectiveValue(System.Windows.EntryIndex, System.Windows.DependencyProperty, System.Windows.RequestFlags)
but none of this gives me (that I can see) any information about what code is failing. I have got down to deleting various bits and re-starting the app, but it is extremely time-consuming and I can't help but wonder - is there something else I should be doing.
Is there any way I can find out which bit of code is failing, or any clues (e.g. search terms to look for in my code, clues as to whether it would be a .xaml or a .cs page, places to look in the Exception details, anything) that might help narrow down the location? For instance, is this something that would only be returned by a failed attempt to override the template defaults in wpf, or might it be caused by one of my windows - Is it likely to have come from a style maybe?
Basically, other than seeing that there seems to be a place where I should be setting the BorderBrush and am not, I have no idea how to find what error I need to fix - and since it is a missing thing, I don't know how to find it. Any leads, hunches or advice will be greatly received!
This is a WPF Windows Application, writing in Visual Studio 2019 using .NET 4.8

So it turns out that there really is no way to find out clearly where the error was, but through a process of deleting files, clearing out references and reinstating, I was able to find the problem.
There was a reference to a static resource in a connected .DLL that no longer existing since the .DLL was republished without checking. The change in name there meant that a resource was not found and the unset value was sent to the Dependency Property. It would be lovely if Microsoft were able to provide some sort of check on the location of problematic resources.

Accessing inner exceptions when building using csc.exe

I am compiling a project using csc.exe, with the /analyzer: flag pointing to the paths of ErrorProne.Net.CoreAnalyzers.dll and ErrorProne.Net.Core.dll, which are built from my clone of the library here.
However, I see several error messages like these:
"warning CS8032: An instance of analyzer
ErrorProne.NET.AsyncAnalyzers.ConcurrentCollectionAnalyzer cannot be
created from
C:\Repos\RoslynExample\RoslynExample\ErrorProne.Net.CoreAnalyzers.dll
: Exception has been thrown by the target of an invocation."
"warning CS8032: An instance of analyzer
ErrorProne.NET.AsyncAnalyzers.AddConfigureAwaitAnalyzer cannot be
created from
C:\Repos\RoslynExample\RoslynExample\ErrorProne.Net.CoreAnalyzers.dll
: Exception has been thrown by the target of an invocation."
etc.
I would like to get more debug information, so that I know exactly when and where these errors are thrown, as well as their inner exceptions. As of now, these error messages on their own are useless.
It is important that I am able to print the stack traces (especially the inner exceptions) to console, or write it to file.
How can I get a copy of the stack trace?
UPDATE:
I figured out the cause of these errors by 1) creating a console application which runs the analyzers built from my clone of the Error.Net source code, 2) disabling Just My Code, and 3) breaking on all exceptions. While it is great to finally figure out what the problem is, it still leaves my original question unanswered: How can I get access to the inner exceptions (so that I can display them later) just by running csc.exe?

did you try to turn on Trace output?
csc -r:System.dll -d:TRACE -d:DEBUG=FALSE MyApplication.cs
Maybe this article will be usefull for you How to: Compile Conditionally with Trace and Debug

Get Specific information from thrown exception

Lets consider that we have an Exception ex thrown in the code. Now in the catch body, I want to have access to six pieces of information:
Solution Name
Project Name
NameSpace Name
File Name
Method Name
Line Number
What I already know is that using
System.Diagnostics.StackTrace trace = new System.Diagnostics.StackTrace(e, true);
I can have access to some of these information(full path of file, line number, etc). But still this information is not all I need. For example, I do not know how to extract solution name or namespace name from trace. Apparently parsing the path for the file is also not an option because different errors can have several layers of file and folders hierarchy and one global rule does not work for all of the errors.
I wonder is there any way to have access programmatically to these info?
Many thanks.

In all likelihood you're not going to get something totally ideal for what you're asking for, but I'll share some tools and thoughts you might not have known about or considered:
There are some attributes (CallerFilePathAttribute, CallerLineNumberAttribute, and CallerMemberNameAttribute which, when added to an optional method parameter, will cause the compiler to automatically insert a default value based on the context of the code being compiled. You could create a helper method with attributes like this to capture the information you want.
There are tools like Fody, known as "IL Weavers", which can run after the main compile process and change the compiled code in a particular way. For example, your code could be written to make a simple call to one method, but when it's compiled the weaver could change the code to create a bunch of contextual information and pass it to a logging method.
If you're organizing your code well, you can often ensure that the namespace, class, and method (which are all captured as part of the stack trace) are enough information that you can guess the solution, project, and File Name.
When you're catching an exception, you typically want to either log what happened and handle the exception in a particular way, or simply wrap the exception in another exception with more contextual information. If you choose the latter, then the namespace, class, and method name will get included in the stack trace of the thrown exception. So when it's logged further up the stack you'll have access to that data.

Suppress RuntimeBinderException messages from dynamic types

I've recently started using a private NuGet server to manage my organization's internal libraries. This means in order to step into our own code that is in a library, I need to disable "Enable Just My Code" in debugging options since we aren't referring to the projects directly any more. This is a pretty hefty MVC project that uses dynamic types and ExpandoObjects in addition to ViewBag. I get two RuntimeBinderExceptions for every single use of a dynamic type... which is a lot. This appears to be normal behavior from what I've read. Normal it may be, but useful it is not.
My first thought was to disable this particular exeption in the Debug-> Exceptions dialog. The exception is not to be found there. I can't figure out any way to be able to step outside the projects referenced directly, without also opening myself up to these exceptions. (And all manner of other low-level framework exceptions that I don't want to hear about, but this is the biggest offender by far).
What's the best way to deal with this?
Edit: This is the problem. How do I stop this with "Enable Just My Code" disabled?

You can add additional "exception" names (existing in your own code or other libraries)...so long as you know the exception's fully qualified type name.
Managing Exception with the Debugger
https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx
In Visual Studio 2010
Via the Debug | Exceptions... dialog.
Use the Add button to add a new exception under the Common Language Runtime Exceptions group and call it Microsoft.CSharp.RuntimeBinder.RuntimeBinderException
then just make sure Thrown and User-Handled are NOT ticked - thus causing the first chance exception to be ignored, rather than being caught by the debugger.
In Visual Studio 2017
Via the Debug | Windows | Exception Settings... panel
Use + to add the new exception name
make sure it's unticked

Visual Studio Debugger: Skip over FaultExceptions being thrown

I have my client calling a WCF Server I'm hosting locally, right now I'm debugging the client so on the server I'm purposely throwing a FaultException to see how the client would handle it.
The part that is annoying is that the debugger pauses on the line that throws the FaultException. How do I get it to NOT do that? I looked in Visual Studio's Options (Debugging) and don't see anything that resembles an option for this.

Use the DebuggerStepThrough attribute on the method you wish the debugger to skip over.

You can configure the debugger to ignore certain exceptions by going to "Debug -> Exceptions" (shortcut: Ctrl+Alt+E) and unchecking "user-unhandled" for the exceptions or their namespace.
Disable either System.ServiceModel.FaultException`1 For Typed FaultExceptions (FaultException< TDetail >) or System.ServiceModel.FaultException for both typed and untyped FaultExceptions.
Find both by searching for the words "Fault" with "Find ..." or by expending "Common Language Runtime Exceptions-> System -> System.ServiceModel"