Dependencies in Elastic.Apm

Since the Elastic.Apm project is the core of the agent it can end up basically in any types of application on any types of framework that we support. Therefore we should be super careful about what other packages/assemblies this package depends on.

We already had suggestions from the community to add fancy logging libraries and I expect some other ideas in the future. All those are valid ideas, but one of the main design goals regarding this package should be portability (also beyond just .NET Standard 2.0). If we lock ourself into a specific framework or into a relatively high framework version then it can block our productivity and limit the supported frameworks/platforms heavily.

Therefore:

• There should be a documentation describing this and each time someone suggests to add a new dependency to Elastic.Apm then we should just check if against or design goals and make the decision based on that. (hint: probably most of the suggestions to add a dependency will be declined…)

• We should revisit the existing dependencies and think about solutions.

• Json.NET (the elasticsearch client already solves this, we should reuse this solution)

• System.Threading.Tasks.Dataflow (caused problems with our full framework sample on @SergeyKleyman`s setup, we should check if this is ok)

• System.Diagnostics.DiagnosticSource

[tomap]

Any news on this move? removal of newtonsoft & switch to System.Text.Json ?

[Mpdreamz]

Most likely we will move to System.Text.Json @tomasfreund because its maintained.

In the .NET Elaticsearch client we depend on a fork of Utf8Json we maintain that tackles many of the outstanding issues including https://github.com/neuecc/Utf8Json/issues/154 see https://github.com/nullean/Utf8Json/commit/429e0611cb0fd30245c042ea6d13566c68b75b95

But the decision to do so there predates System.Text.Json 😄