opentelemetry-dotnet-instrumentation: An assembly specified in the application dependencies manifest was not found

Bug Report

Symptom

When starting the “demo” Docker example, the Client and Server containers immediately stop with the following error:

An assembly specified in the application dependencies manifest (OpenTelemetry.AutoInstrumentation.AdditionalDeps.deps.json) was not found
  package: 'DnsClient', version: '1.4.0'
  path: 'lib/netstandard2.1/DnsClient.dll'

Expected behavior All containers should start successfully.

Screenshots Screen Shot 2023-02-04 at 14 19 48

Runtime environment:

OpenTelemetry Automatic Instrumentation version: 0.5.0
OS: Mac OS Monterey 12.6.2, M1 Pro, 32 GB RAM
Docker Desktop 4.16.2 (95914)
.NET version: defined by the Docker image

Additional context In addition to getting this error with the Docker example running on my Mac, I also got this very same error on a Windows 11 Home VM running on Parallels on the Mac. In that case I used the Powershell script as instructed, and got the error after launching the app’s exe. During this attempt in Windows, I was able to workaround the issue by manually copying each and every DLL from C:\Program Files\OpenTelemetry .NET AutoInstrumentation\store\x64\net6.0 to the directory where the .exe was. So maybe this is just some environment variable missing? Because it seems it cannot resolve the location of these assemblies in the shared store (just guessing).

Reproduce

Enter make command
Wait until docker-compose downloads all images and starts all containers
Soon after that, 3 containers stop:

sqlserver-1 ==> The requested image’s platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
service-1 & client-1 ==> showing the error above.

I understand the SQL Server image error can be fixed by using a different image maybe. It’s the .NET error that I’m concerned about. Also I didn’t found any OpenTelemetry log files in /var/log/opentelemetry/dotnet/

About this issue

Original URL
State: closed
Created a year ago
Comments: 23 (10 by maintainers)

Most upvoted comments

Awesome guys. Thank you all very much.

The lack of native ARM binaries prevents any bytecode instrumentation on any ARM architecture

Does this mean a different kind of instrumentation was used in my case? Cause I’m seeing the traces

The “source instrumentation type” is what is working in your scenario.

References:

pellared on Feb 9, 2023

these env vars are documented here.

Maybe this should be mentioned in the troubleshooting doc. Or in the main readme perhaps.

d-aguilera on Feb 8, 2023

That worked @pjanotti !

d-aguilera on Feb 8, 2023

@d-aguilera are you still getting the An assembly specified in the application dependencies manifest error as above? If that is the case could you please try the command that is failing with the following environment variables set:

COREHOST_TRACE=1
COREHOST_TRACEFILE=corehost_verbose_tracing.log
COREHOST_TRACE_VERBOSITY=4

these env vars are documented here. Running the command with these env vars should create the log file with some info to dig deeper into this.

pjanotti on Feb 7, 2023

The readme says self-contained deployments are incompatible with automatic instrumentation, but I wanted to give it a try anyway to see if at least I could solve the missing dependencies problem this way. So I tried dotnet publish -c Release -o out -r linux-arm64 and, as expected, it produced working Client and Service apps.

However, to my surprise, I’m seeing SQL traces in Grafana now, which I understand are automatically generated traces, correct? Does this mean it was able to instrument a self-contained build?

d-aguilera on Feb 5, 2023