ApplicationInsights-JS How to share an application insights instance across ASP.NET Core (C#) and React (typescript)?

Hi,

How do I share an application insights instance that has been created via the .NET application insights package with my typescript frontend?

I know that I could create another instance in our typescript frontend, but that would require me to encode a connection string in our app (unless the typescript application insights package can consume an environment variable, which I've not seen documentation for but I may have missed). I've wired up ApplicationInsights for the .NET part of the codebase by using an environment variable for the connection string, which allows us to use Azure to point the deployed App Service to a particular regional application insights resource, without having to encode any connection strings within the app. The .NET Application Insights package natively knows how to search for this environment variable, hence the only programmatic set-up from the .NET side needed is to add the telemetry as a service.

Now, I would like to be able to "share" this instance with the typescript frontend, such that I can use the same instance for logging in both parts of the codebase. I know that this is possible because we have a legacy web codebase that does just that - but despite my digging and researching I'm unable to determine the correct way to plumb this. There seems to be zero initialization or "wiring" from the typescript side in the legacy codebase, so I'm at a bit of a stand-still.

For context, our controllers, data handlers, etc. all live in .NET-land while our UX lives in React, so I'd like to be able to log from both places.

Any insights (no pun intended) would be much appreciated. Feel free to reach out to me on Teams as well if that's easier! Thanks so much.

AJN

Mar 15 '23 19:03 alexnesh

Ok, when you enable codeless attach this causes the SDK to be downloaded and initialized from the CDN.

As part of this initialization this creates a global appInsights on window to enable you to use it.

So for you typescript front end you could either change to use this global (assuming that you are using NPM) -- you will probably require some wrappers around the typings for the global or perhaps just declare a global as the main AISku instance and keep using the typing from the npm package.

Probably (I've not tried this), something like

declare var appInsights: IApplicationInsights; Where the IApplicationInsights comes from @microsoft/applicationinsights-web

Or. Disable codeless attach and just use npm, of course as you pointed out you would need to get your connectionString / instrumentationKey into you npm based initialization (assuming you don't already hard code it)

Mar 15 '23 19:03 MSNev

Thanks for the input @MSNev. Yes, I'm currently using npm to pull the microsoft/applicationinsights-web package.

Right, so the old codebase that does this defines an extension to the global window interface that adds appInsights a la:

declare global { interface Window { ... appInsights: any; ... } }

And just defines a telemetry client a la

private _telemetryClient: IAppInsights = window.appInsights;

Can you elaborate on codeless attach - how do I enable/disable this? When trying to mock what I had seen above, basically the window's appInsights var was undefined, so I assume I'm missing the codeless attach part which does the init that you mentioned above. Additionally, I'm pulling the .NET nuget package as well, and adding the application insights as a service in my Startup.cs via:

public void ConfigureServices(IServiceCollection services) { // add telemetry services.AddApplicationInsightsTelemetry(); ...

Mar 15 '23 19:03 alexnesh

The codeless attach is a feature of hosting your application in the Azure portal and I believe that there is a configuration in the UI the enable / disable @Karlie-777, Can you please provide a link to the documentation for this. It works as a filter on the outbound (returned) HTML page where it injects a code snippet onto the page to cause the SDK to be downloaded. It is also possible via a .Net NuGet package (I can't find the links) where in your application you add a small code reference which will cause effectively the same code snippet to be added to the response generated by your server.

If appInsights is undefined then neither of the above are in place (as this script is dropped into the head section of the HTML and adds the global and provides some proxy functions (not the entire SDK API) to capture the SDK calls that are replayed (re-executed) once the SDK is loaded -- basically this means that if your attempting to use some of the SDK functions that are not proxied they will fail (because the functions are undefined) until the SDK is loaded (which may fail if the user has an Ad Blocker installed).

These are the only functions that are proxied which means your _telemetryClient (may) fail if you are calling any other functions and either the SDK has not yet loaded or failed for some reason.

Mar 16 '23 16:03 MSNev

@alexnesh .NET Core supports client-side monitoring , this link: .NET Core Enable client-side telemetry for web applications might help. But this feature actually injects JavaScript ApplicationInsights instance (with the connection string in your .NET Core app environment variables) via CDN into every returned response instead of "sharing instance".

Mar 16 '23 16:03 Karlie-777

Great - looking at the docs @Karlie-777 linked, it looks like the snippets need to be included in _ViewImports.cshtml and _Layout.cshtml. I had done the _ViewImports.cshtml snippet, but because this is a React app with ASP just used for pinging services, data management etc., there is no _Layout.cshtml. The document @Karlie-777 linked accounts for this via:

_If your project doesn't include Layout.cshtml, you can still add client-side monitoring by adding the JavaScript snippet to an equivalent file that controls the of all pages within your app.

Looking at the document linked in this comment, it mentions manually adding the following script to your index file:

This necessitates manually encoding the connection string, which is what I'm trying to avoid. So I guess the question is: for a react app where there is no _Layout.cshtml, can the CDN injection still find a way to use the ASP.NET Core env variable for the connection string?

Thanks for the support!

-AJN

Mar 16 '23 17:03 alexnesh

@alexnesh I remember there is .env file in react apps (I might be wrong). Inside .env, if you add prefix REACT_APP_ to your env variables, for example REACT_APP_CS = connectionstring it could be used by client side. and inside html, you could use connectionString: %REACT_APP_CS%

Mar 16 '23 23:03 Karlie-777

This Issue will be closed in 30 days. Please remove the "Stale" label or comment to avoid closure with no action.

Jan 11 '24 07:01 github-actions[bot]