MethodAccessException thrown when AddEntityFramework is called about sentry-dotnet-ef

[kanadaj]

Here is a temporary fix til AddExceptionProcessor is public:

public static SentryOptions AddEntityFramework(this SentryOptions sentryOptions)
{
    var extensions = typeof(SentryOptionsExtensions);
    var addExceptionProcessorInfo = extensions.GetMethod("AddExceptionProcessor", BindingFlags.Static);
    addExceptionProcessorInfo.Invoke(null, new object[]{ sentryOptions, new DbEntityValidationExceptionProcessor() });
    return sentryOptions;
}

Also, make sure to change the namespace of the file to Sentry.EntityFramework to avoid namespace collisions (or change the class name from SentryOptionsExtensions to EntityFrameworkSentryOptionsExtensions)

This works fine (performance doesn't matter since it's normally only called at startup) but I don't want to commit this into the repo cause it's ugly as hell.

[bruno-garcia]

Which version of the Sentry package are you using?
That method was made internal on later versions of the Sentry package.
The Sentry.EntityFramework package was still not made compatible with that.

As we can see on NuGet.org:

The latest version of Sentry.EntityFramework still depends on Sentry version preview4.
Soon we'll be publishing a new version of this package depending on the version 1.0.0 of Sentry that was released last week

[mungk]

Yes, I'm using version 1.0.0 of the Sentry package. The dependency is marked as ">=" so I was just following that.

Looking forward to the updated package. Do you have an ETA? Perhaps the dependency should be corrected if the update isn't imminent.

[bruno-garcia]

@mungk This is not a high priority ATM but we'd be happy to merge a PR.

All it's needed is updating ,in this repository, the dependency Sentry to 1.0.0 and getting it to build, run tests and run the sample to make sure things work as you expect.

After that I can publish the package.

[mungk]

@bruno-garcia Unfortunately, upgrading the Sentry dependency to 1.0.0 breaks this Sentry.EntityFramework package because that AddExceptionProcessor method was changed to internal instead of public. I'm not sure whether it should be:

1. Changed back to public, or:
2. Sentry.EntityFramework should be added to the Sentry InternalsVisibleTo list

Choice 1 seems reasonable to me, but I don't claim to know the Sentry package well enough to know why it was made internal.

Choice 2 seems like a burden moving forward as more and more extensions are added because they'll each need to be included on the list.

Either way, it's a change to the Sentry package itself and (depending on the option chosen) it may be an additional change to this Sentry.EntityFramework package as well.

[bruno-garcia]

You are right. I'm leaning towards making them public again although that is not part of the unified API of the Sentry SDKs.
In any case, .NET is the only SDK which has a single hub since we can rely on AsyncLocal.

If you'd like to PR making those methods again public, I'd be happy to merge it in.

[bruno-garcia]

@mungk We still need to release a new version of Sentry package so this one can be updated and released. Ideally we'd combine with a couple more things before we make a release though.

Until then you could try setting [assembly: IgnoresAccessChecksTo("Sentry")] so you have access to the internal method. It's a hack but should unblock you until we release the new package. Note that IgnoresAccessChecksTo doesn't exist in .NET Standard so you need to create a class with that name. Filip W blogged here about it.

/cc @xt0rted

[xt0rted]

The only build error I'm seeing right now is due to AddExceptionProcessor(). Once the new version of Sentry goes out this should be a pretty straight forward update.

[bruno-garcia]

@xt0rted's fix is published to NuGet as a preview package along with a few more changes.

[bruno-garcia]

Version 1.0.0 was released.
Feel free to reopen if this issue persists.