Very strange exception when accessing the configuration system with .NET 4.6.1
-
Hi community! I got a situation that's driving me insane: In order to work together with a third-party suite of applications, we have created a kind of addon. This addon is being loaded without any problems into several third-party applications as well as into a MS Word addon the other party wrote. Our addon creates its own AppDomain, so that there should be no interference with the host application. All of this works nicely when using .NET 4.0 up to .NET 4.5.2. Recently, a customer tried running the same setup with .NET 4.6.1 and all of a sudden, the addon crashes when it's being loaded into the Winword-Addon. The crash happens as soon as our addon tries to access ConfigurationManager.AppSettings. The call stack shows that there's a NullReferenceException at System.Xml.XmlCharType.get_Instance() that's happening while the configuration system is being initialized. It only happens there and only with .NET 4.6.1. I'm out of ideas, can anyone help?
Regards, mav -- Black holes are the places where God divided by 0...
-
Hi community! I got a situation that's driving me insane: In order to work together with a third-party suite of applications, we have created a kind of addon. This addon is being loaded without any problems into several third-party applications as well as into a MS Word addon the other party wrote. Our addon creates its own AppDomain, so that there should be no interference with the host application. All of this works nicely when using .NET 4.0 up to .NET 4.5.2. Recently, a customer tried running the same setup with .NET 4.6.1 and all of a sudden, the addon crashes when it's being loaded into the Winword-Addon. The crash happens as soon as our addon tries to access ConfigurationManager.AppSettings. The call stack shows that there's a NullReferenceException at System.Xml.XmlCharType.get_Instance() that's happening while the configuration system is being initialized. It only happens there and only with .NET 4.6.1. I'm out of ideas, can anyone help?
Regards, mav -- Black holes are the places where God divided by 0...
Looking at the source[^], the most likely culprit would seem to be the embedded resource. Is the Word addon doing anything odd with cultures, or messing with the CAS policy?
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Looking at the source[^], the most likely culprit would seem to be the embedded resource. Is the Word addon doing anything odd with cultures, or messing with the CAS policy?
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks for the reply, Richard! I also had taken a look at the code in System.Xml.dll from 4.5.2 and from 4.6.1 using ILSpy, but couldn't find any significant difference. Both versions had the "XmlCharType.bin" resource embedded inside the assembly. When our addon is being loaded, it's creating a separate AppDomain to avoid any side effects the host application might have, so I have no idea what they could actually do to make our addon fail so miserably. I even looked at the assemblies loaded into our AppDomain when initializing the configuration system fails and System.Xml.dll is already loaded at the very beginning, so I really cannot see what could keep the assembly from finding its own embedded resource... To my understanding, even fiddling with CAS cannot influence access to an assembly when it's already loaded, can it?
Regards, mav -- Black holes are the places where God divided by 0...
