Skip to content

issues/1794: fix to work with application insights sdk v3 - #1798

Open
lockerbill wants to merge 3 commits into
pnp:devfrom
lockerbill:issues/1794
Open

issues/1794: fix to work with application insights sdk v3#1798
lockerbill wants to merge 3 commits into
pnp:devfrom
lockerbill:issues/1794

Conversation

@lockerbill

Copy link
Copy Markdown

Fix issue #1794

System.MissingMethodException: Method not found: 'Void Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.set_InstrumentationKey(System.String)'.

System.MissingMethodException: Method not found: 'Void Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.set_InstrumentationKey(System.String)'.
@Adam-it

Adam-it commented Jul 13, 2026

Copy link
Copy Markdown
Member

@lockerbill thanks for opening up the PR we will try to look into it ASAP.
Please in future wait until you claim the issue (get assigned) before opening a PR not to surprise us with a code change.
Maybe a simple fix would be just to update the app insights package to v3 🤔

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses compatibility with Microsoft.ApplicationInsights SDK v3 by removing usage of the removed TelemetryConfiguration.InstrumentationKey setter and switching telemetry setup to use a connection string, plus updating tests to cover the new behavior.

Changes:

  • Update TelemetryClientFactory to configure Application Insights via TelemetryConfiguration.ConnectionString.
  • Add a unit test ensuring the factory sets the connection string as expected.
  • Update test projects to reference Microsoft.ApplicationInsights v3.1.2 and remove obsolete instrumentation-key setters in test helpers.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
src/sdk/PnP.Core/Services/Core/TelemetryClientFactory.cs Switches telemetry configuration to use connection string instead of obsolete instrumentation key setter.
src/sdk/PnP.Core.Test/PnP.Core.Test.csproj Adds an explicit App Insights v3 reference to reproduce/guard the compatibility scenario in tests.
src/sdk/PnP.Core.Test/Base/TelemetryTests.cs Adds a test validating the telemetry factory configures ConnectionString.
src/sdk/PnP.Core.Test.Common/Services/Core/TestTelemetryManager.cs Removes obsolete instrumentation-key assignment in the test telemetry manager.
src/sdk/PnP.Core.Test.Common/Services/Core/TestPnPContextFactory.cs Removes obsolete instrumentation-key assignment previously used to redirect telemetry during local test runs.
.gitignore Ignores IDE metadata under src/sdk/.idea.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 22 to 26
if (telemetryConfiguration == null)
{
telemetryConfiguration = TelemetryConfiguration.CreateDefault();
#pragma warning disable CS0618 // Type or member is obsolete
telemetryConfiguration.InstrumentationKey = instrumentationKey;
#pragma warning restore CS0618 // Type or member is obsolete
telemetryConfiguration = new TelemetryConfiguration();
telemetryConfiguration.ConnectionString = $"InstrumentationKey={instrumentationKey}";
}

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CreateDefault() changed semantics between majors. On AI 2.x it returns a new instance per call; on v3 it returns a process-wide
shared singleton (verified: ReferenceEquals(CreateDefault(), CreateDefault()) == true on 3.1.2, false on 2.23.0).

So on v3, telemetryConfiguration.ConnectionString = ... on a CreateDefault() instance would:

  1. overwrite the hosting application's shared telemetry configuration with the PnP instrumentation key, redirecting the host's
    own telemetry into the PnP App Insights resource, and
  2. throw InvalidOperationException: "Configuration cannot be modified after it has been built" as soon as anything else in the
    process has already built a TelemetryClient from it. This is not hypothetical — with CreateDefault() in place,
    SetupTests.ServicesWithOptions (which builds a factory with DisableTelemetry = false) freezes the shared config and
    TelemetryClientFactoryConfiguresConnectionString then fails.

As for the concern itself: new TelemetryConfiguration() does not leave the pipeline unusable. On 2.23.0 it gets an
InMemoryChannel + PassThroughProcessor and TrackEvent works; on 3.1.2 the channel/processor concept doesn't exist at all (v3 is a
shim over Azure.Monitor.OpenTelemetry.Exporter) and ctor vs CreateDefault() produce identical state. The only real delta is that
v2's CreateDefault() adds OperationCorrelationTelemetryInitializer — not worth hijacking the host's config for.

A library needs its own isolated configuration, so I've kept new TelemetryConfiguration() and added a comment explaining why, to
stop this being "fixed" back.

Comment on lines 59 to 61
EventHub eventHub) : base(logger, sharePointRestClient, microsoftGraphClient, contextOptions, globalOptions, eventHub)
{
if (TelemetryManager != null && !TestCommonBase.RunningInGitHubWorkflow())
{
// Send telemetry to the test Azure AppInsights instance
#pragma warning disable CS0618 // Type or member is obsolete
TelemetryManager.TelemetryClient.InstrumentationKey = "6073339d-9e70-4004-9ff7-1345316ade97";
#pragma warning restore CS0618 // Type or member is obsolete
}
}

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right intent, but it can't be done at that location — I've restored it elsewhere.

Two blockers on v3: TelemetryClient.InstrumentationKey (and TelemetryContext.InstrumentationKey) are removed, so there's no
per-client override any more; and TelemetryConfiguration is frozen once a TelemetryClient is built from it. By the time the
TestPnPContextFactory ctor body runs, the base PnPContextFactory ctor has already called ConnectTelemetry(), which built both the
config and the client — so assigning ConnectionString there would throw.

The key therefore has to be set before the first TelemetryManager is constructed. TelemetryManager.InstrumentationKey is already
an internal static that the ctor feeds to TelemetryClientFactory, so I've added TestCommonBase.UseTestTelemetryInstance()
(guarded by RunningInGitHubWorkflow(), same as before) and call it from an [AssemblyInitialize] in each test assembly, which
MSTest guarantees runs before any test. Local runs go to 6073339d-… again; CI is unaffected (and has DisableTelemetry: true
anyway). Covered by a new TestRunsUseTheTestAppInsightsInstance test.

I did not restore the TestTelemetryManager line: that class overrides both LogInitRequest and LogServiceRequest and never calls
TrackEvent, so it never sent anything to App Insights regardless of key — it was dead code.

Comment on lines +45 to +48
FieldInfo configurationField = typeof(TelemetryClientFactory).GetField("telemetryConfiguration", BindingFlags.Static | BindingFlags.NonPublic);
FieldInfo clientField = typeof(TelemetryClientFactory).GetField("telemetryClient", BindingFlags.Static | BindingFlags.NonPublic);
TelemetryConfiguration originalConfiguration = (TelemetryConfiguration)configurationField.GetValue(null);
TelemetryClient originalClient = (TelemetryClient)clientField.GetValue(null);
@Adam-it Adam-it added the .NET Pull requests that update .net code label Jul 13, 2026
@gszdev

gszdev commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

@lockerbill thanks for opening up the PR we will try to look into it ASAP. Please in future wait until you claim the issue (get assigned) before opening a PR not to surprise us with a code change. Maybe a simple fix would be just to update the app insights package to v3 🤔

@Adam-it
Please consider that an update from Microsoft.ApplicationInsights from v2.x to v3.x will bring the some breaking changes, especially when using it inside Azure Functions with dependencies to Microsoft.ApplicationInsights.WorkerService.
Please have a look into the issue 3322 of Azure Functions .NET Worker. So no version of Microsoft.Azure.Functions.Worker.ApplicationInsights is planned that is compatible with the 3.0 release of Microsoft.ApplicationInsights.WorkerService.
The recommendation is to move to OpenTelemetry-based monitoring. For details see Comment to 3322.

@lockerbill

Copy link
Copy Markdown
Author

@lockerbill thanks for opening up the PR we will try to look into it ASAP. Please in future wait until you claim the issue (get assigned) before opening a PR not to surprise us with a code change. Maybe a simple fix would be just to update the app insights package to v3 🤔

Hi @Adam-it ,
Thanks for the feedback, I should have followed the PR process next time to claim the issue first.
I've tried to address your earlier comments and also tried to do a minimum fix to get the SDK to work with my app has direct reference to application insights v3

@Adam-it Adam-it assigned ejazhussain and unassigned Adam-it Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

.NET Pull requests that update .net code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants