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.
Related
Since I pull my project from GitHub and attempt to run my app the problem keep happening when it refers to Json.net when trying to serialize anything. Originally it was at version 11 when the error showed up, then I tried to downgrade to version 8 and it still persists. So, I upgrade to latest on 12.0.1 but the problem still not going away
The code is nothing but Newtonsoft.Json.JsonConvert.SerializeObject(data)
And no matter what type of data it is it always thrown
FieldAccessException: Attempt by method
'Newtonsoft.Json.JsonSerializerSettings..cctor()' to access field
'Newtonsoft.Json.JsonSerializerSettings.DefaultContext' failed.
I even tried to construct the JsonSerializerSettings on my own and that still happens.
Will this answer help you?
Basically, in order to workaround this problem you need to make sure "Enable the Visual Studio hosting process" is unchecked in your project's settings under Debug.
This error may occur if the code is running under partial trust. Following link can help more in providing error description:
https://learn.microsoft.com/en-us/dotnet/api/system.methodaccessexception?redirectedfrom=MSDN&view=netframework-4.7.2
Previously, I have encountered this error if the code has restricted access like private, protected or internal methods. As per MSDN:
This exception is thrown in situations such as the following:
A private, protected, or internal method that would not be accessible from normal compiled code is accessed from partially
trusted code by using reflection.
A security-critical method is accessed from transparent code.
The access level of a method in a class library has changed, and one or more assemblies that reference the library have not been
recompiled.
I have a WebAPI application where we often drop various custom dlls into the bin folder for additional functionality. Sometimes the custom dlls reference other custom dlls, which reference other custom dlls... it can be a bit of a nightmare.
Occasionally I will either miss something, or something goes screwy, and I get the infamous YSOD (Yellow Screen Of Death) upon starting the API.
The YSOD will often display the name of the troublemaker assembly, which helps a little, but what I really want to know is the dll(s) that I'm missing. And I know that I can get this information from the LoaderExceptions property if only I could catch and handle the exception!!
I've got a lot of exception handling at a few different levels, including a global exception handler, but after trying quite a few different things, and finding this (so far) unanswered question, I'm getting a nasty suspicion that this exception is occurring in IIS outside of my app, and I have no control over it.
If that IS the case, is there a way I can examine the exception in IIS? Otherwise why would it suggest retrieving the LoaderExceptions?
If NOT the case, how/where/when can I catch and handle this type of exception?
EDIT:
From David's comment below, I have also tried hooking to AppDomain.AssemblyResolve, AppDomain.UnhandledException, and AppDomain.FirstChanceException events, and none of these are catching the yellow screen exception either...
I have a custom control library in my solution, where my main WPF project references it. If there is an error in the custom control library, then the error list goes mental and displayed hundreds of errors. Here is an example of one such incident.
Now this is just an error that I forced in order to demonstrate the problem.
In this case, the problem isn't so severe, as there are only 21 errors. However, there have been occasions where I have had to filter though hundreds of errors to find the actual error that's causing everything else to fail.
I believe I understand what the problem actually is. I think the problem is due to the custom control library not being built, therefore my main project can't find the dll for it, and therefore the custom controls cannot be found, which causes the errors.
Now, in truth, the error list isn't lying, I mean, these are real errors. However, that being said, is there a way to prevent this from occurring?
If I understand what you are asking, I think that this extension will help you as it stops the build as soon as an error occurs.
StopOnFirstBuildError
I have this project, which consists of a WCF Library acting as a Server for a Trouble Ticket system.
Link for solution skeleton: http://imgur.com/eZqe5Q8
I have an interface that allows me to access the server methods.
I have a DB as you can see in the picture, called "MainDB".
I have a website with a service reference to the server which works perfectly fine.
Then I needed to create a GUI application client that accesses the same server interface. I did this by creating a WPF application. I reference the server, just the same as I did in the website and use the same interface, and I call the exact same method, in this case the Login method, which you can check in this image: http://imgur.com/3PajH3U
But when I call this method from the WPF I get an exception on the red squared line which says this:
"An unhandled exception of type 'System.NullReferenceException' occurred in TTService.dll
Additional information: Object reference not set to an instance of an object."
I thought it might be because of the DB not being "published", but it was. I run the website and the WPF at the same time and one runs perfectly smooth while the other causes that exception. I can't get what's causing this, probably because I'm still not experienced in this technology.
The fact that the origin of the method call is different doesn't seem to me like a plausible cause because I can't understand how the method would know where the call originated.
I'm sorry I can't put the images in the post but not enough reputation yet.
Thank you for any help.
I fixed this. It actually was the Interface implementation that was wrong. Sorry for the misinformation.
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