Mongo Instrumentation on .NET Framework

Elastic Observability APM
1

I'm using the latest Elastic agent (1.11) on .NET Framework, but having issues trying to instrument Mongo. Despite having MongoDb.Driver(+.Core) installed in the libraries that I have the Elastic agent installed in, when I try to add the subscriber I get this issue. The Mongo version is >2.4.4.

Could not load file or assembly 'MongoDB.Driver.Core, Version=2.4.4.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

Has anyone successfully gotten the Mongo instrumentation to work in .NET Framework?

Thanks!

2

Any advice, still stuck on this same issue. Thanks!

3

Hi @ntp,

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:

  1. 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.

  2. 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.

4

Thanks so much for the answer @forloop. We're working on migrating to .NET Core, but it's been a slow process. Sounds like our best option is to just wait until that migration is complete. Thanks again for all the information.

1 Like
5

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.