There will be a problem on .NET Framework related to Strong-named assemblies.
All the Elastic APM agent assemblies are strong-named, but the MongoDB driver assemblies are not, which is a problem on .NET Framework, where a strong-named assembly can only use types from other strong-named assemblies. The MongoDB integration is tested on .NET Core but not .NET Framework, which would have caught this.
There are a couple of options I can propose at this stage, which I appreciate may not be feasible for you, but nevertheless will put them here:
Strong-name the MongoDB assemblies. The
elasticapm.snk used to strong name the Elastic.Apm assemblies is checked into the repository, which could be used, or can generate your own with sn.
It looks like you would need to strong name MongoDB.Bson.dll, MongoDB.Driver.dll and MongoDB.Driver.Core.dll. An approach is to use ildasm to get the MSIL/CIL for the assembly, and use ilasm to rebuild using the key to strong-name.
If possible, use .NET Core, which doesn't enforce the same strong-naming constraints as .NET Framework.
Going forward, an option that we can investigate is instrumenting MongoDB through a CLR profiler approach, which would work with MongoDB assemblies that are not strong-named. We're looking at a profiler based approach for instrumenting other libraries already (I don't have timelines I can share, I'm afraid), so using to instrument MongoDB too would work around the strong-naming problem.