Following upgrade, Agent.Tracer is apparently null. Initialization issue?

Elastic Observability APM
1

Greetings All !

I have an existing Windows Desktop C# .NET application that has been using Elastic.Apm for .Net library version 1.25.3 on .NET version 4.6.1 for several years now. I am working on the small project of updating everything to .NET version 4.8.1... which now has me using the Elastic.Apm for .Net library version 1.32.2.

This upgrade has somehow broken my existing code.

The only Elastic APM related initialization code I have is:
            Environment.SetEnvironmentVariable("ELASTIC_APM_SERVER_URLS", SitMan.Config.Paths.APMServerURL);
            Environment.SetEnvironmentVariable("ELASTIC_APM_SERVICE_NAME", <my application name> );
            Environment.SetEnvironmentVariable("ELASTIC_APM_SERVICE_VERSION", Application.ProductVersion);
            Environment.SetEnvironmentVariable("ELASTIC_APM_ENVIRONMENT", SelectedLaunchEnvironment.Name);

            Agent.Setup(new AgentComponents(logger: new ApmLoggerBridge(logger)));

And then, what happens is, in the 70+ functions throughout my app where I want to apply APM tracing, I start with the lines:

            ITransaction transaction = null;
            ISpan span = null;
            Dictionary<string, string> labels = new Dictionary<string, string>()
            {
                { "request", putQuery },
            };

And then I call a function:
Common.BeginAPMTransOrSpan(ref transaction, ref span, $"{action} Alarm Suppression Rule", labels);

This function starts with:

public static void BeginAPMTransOrSpan(ref ITransaction transaction, ref ISpan span, string name, Dictionary<string, string> labels = null, string type = null, string subtype = null)
 {
     if (!Application.Config.Integration.ElasticAPM)
     {
         transaction = null;
         span = null;
         return;
     }

     transaction = Agent.Tracer.CurrentTransaction;
     span = null;

     if (transaction == null)
     {

(That first clause is just designed to return null if I have things configured so that we don't want to use Elastic APM at all throughout the application.)

My issue appears to be that when we get to that line:

transaction = Agent.Tracer.CurrentTransaction;

We throw an exception:
System.NullReferenceException: Object reference not set to an instance of an object.

Apparently, we throw it because .Tracer is null.

I put a bit of debugging code immediately after that initialization code. It shows that Agent.isConfigured is true, but Agent.Tracer is null.

What do I need to change here? Why is .Tracer not initialized properly following this upgrade?

Thanks!

2

Bah! Confirmation from my application logs. Not sure why it's talking about nuget here:

[5-29-2025 7:57:40 AM INF] (ThreadId: 9) [Elastic.Apm]: {Service} Detected agent activation method: nuget
[5-29-2025 7:57:40 AM ERR] (ThreadId: 9) [Elastic.Apm]: Failed initializing agent.

3

Wow. Disheartening. I downgraded back to version 1. 25.3. And I still have the issue.
So, that would suggest something about the .NET upgrade from 4.6.1 to 4.8.2 caused this, which kind of seems unlikely.

Maybe I need to start over.

4

Started with my previously-working code / version 1.25.3 on .NET 4.6.2. Confirmed APM works. Updated all packages that needed updates... which took Elastic.Apm to 1.32.2. APM still works.

Updated all projects to .NET 4.8.1. Captured messages saying which nuget packages were installed using a different target framework than the current one and may need to be reinstalled.

Used the Nuget Package Manager Console to reinstall every one of those packages... using

Update-Package -Reinstall -ProjectName ""

And then I cleaned the solution, rebuilt it, and ran the program. And I'm back to the same issue with APM initialization.

5

OK, my root cause actually had nothing to do with Elastic.Apm. But I had to add some special FirstChanceException capturing code in my Program.cs in order to find out why Agent.Setup was failing, since no error was being returned other than something like "Agent initialization failed".

This led to the discovery of failures to access a version of System.Net.Http. First, problems finding the right .dll, then later problems finding the right version of the .dll.

Root cause was version mismatching of that library between a NuGet version(4.3.4) vs. the GAC version (4.2.0.0), plus some references across three projects that, when combined with that issue, just made it worse/more confusing.

Basically, installing or updating System.Net.Http via Nuget in a 4.7.2 or higher app can lead to these issues. With .Net version 4.7.2+, System.Net.Http is now a part of the .NET framework. You don't need the Nuget one.

Just thought I'd post this in case somebody else runs into this. (But, I know, this is such an old platform....)

Thanks!

1 Like