Expose ITransport and Friends Publicly

We are trying to pump existing exceptions and error reports into Sentry from a central ingress point (the producers unfortunately cannot use the Sentry/Raven client directly as we need to control the transport and data captured). We were hoping to use Sentry as a SDK (as the REST documentation is a little hard to find).

The models exist and the serializiation logic is there, but everything e.g. EnvelopeHttpContent, HttpTransport, etc. that can use these models, are internal.

I propose decoupling SDK logic from Sentry proper or make these internal types public with no API SLA.

This would be on top of the work in https://github.com/getsentry/sentry-dotnet/pull/944

[Silvenga]

I think complete encapsulation of the SDK logic would be preferred (the models, the serialization logic, the transport abstractions, the http transport implementation) - but there currently exists some rather deep coupling e.g. exposing Exception on the sentry event, but requiring processing later on to copy the data into the final property for processing.

Exceptions in general would need to be decoupled away from the SDK - including “enhanced stacks”. In my use-case, I don’t have the original exception - I have to parse the stack trace to get it to place nice.

When just making the parts I needed public, I had a lot of difficulty resolving all the warnings and eventually just disabled errors on warnings. There were around 2k warnings on my branch (many came from the submodule for example).

My changes to encapsulate the SDK logic would be rather invasive to decouple the different components - then on top of that, there’s the XML documentation warnings that would take a lot of effort to add - and the CLS compliant warnings. So getting anywhere without some 200 file PR, warnings would have to not break the build.

So this might not be a change I can do myself - rather the core maintainers of this SDK. FWIW, my fork does effectively work for our original needs and has entered production (custom transport pipeline and queuing) but it’s likely not something that should be merged.

Are there any particular sealed classes that you want to extend?

Anything can be injected in to customize behavior, off the top of my head, app domain wrapping logic would be an example.

[mattjohnsonpint]

Completed with #1602 and #1560