AFAIK add-ins can’t do binding redirects because redirects are application level, whereas add-ins are just DLLs, redirects belong to the application domain
So if the host application doesn’t do the correct redirects, the add-ins can’t force it
They could try editing the App.config of the host application
Which is messy but might work
i.e. edit the app.config with the correct redirect, and copy the correct Unsafe DLL into the app folder(edited)
I just want to reiterate that this limitation affecting “add-in’s” and part of .NET Framework’s binding redirect and not really the Sentry SDK.
Just FYI - we are using other 3rd party frameworks (eg. Segment) in our products and they all work absolutely fine. I have offered (through your support channel) to make available a virtual dev machine so that you can log on and take a look (as you need the 3rd party application to debug etc).
The issue is that some libraries, like Segment, might not need conflicting libraries, whereas Sentry was compiled against a newer version of certain libraries shared with the host application.
If Segment uses the same or older libraries, binding redirects will work normally since they usually look something like
0.0.0.0 - CurrentVersion -> CurrentVersion
But if you try to use a library that uses something newer than CurrentVersion, Binding Redirects may stop working properly.
There are also some issues specific to .NET Framework due to mistaken versioning. A few standard libraries were impacted by this including System.Net.Http but others are possible. The issue was caused by the NuGet packages having higher version numbers than the inbuilt version, but their assembly version number was lower than the version that comes with the framework.
i.e. the framework library might have a 4.2.1.0 version of the library, with a NuGet package versioned 4.5.0.0, but the actual DLL inside the NuGet package had 4.0.0.0 as the version. Something like this can also cause a binding redirect issue on .NET Framework, because NuGet won’t install the package since the assembly version of the NuGet package is lower, but then the application looking for it anyway because the NuGet version number is higher.
That being said. Look for the app.config inside the application, not in your 3rd party package. The host application also has to have an app.config, and that is the one that your plugin will actually use, not whatever you use in your project.
As it turns out, a relatively simple solution for our Win Forms application, but took a while to uncover.
I had two problems in the end, the first being that the application I was testing in was using a wrapped implementation of Sentry, so I stupidly didn’t check that the binding redirect was applied to the actual executable.
Once I woke up to the first problem, the second was that I tried so many variations of a handful of different properties in the project file for the executable, but what was the killer was that even if I made a change to the project files, I actually had to do a clean on the entire solution between builds in order for it to work. Particularly relevant if you’re working with an old school application that doesn’t have:
I am also facing the same issue. System.Runtime.CompilerServices.Unsafe version used in my application is 5.0 but SentrySdk is looking for 4.0.4.1 version. But I don’t think that downgrading the assembly would be good idea
Thank you kanadaj for the details. Updating my web.config and adding binding-redirect for System.Runtime.CompilerServices.Unsafe solved my issue. I added this in my web.config: