As of #1630, we once again have the following in .NET (isolated worker model) templates:
builder.Services
.AddApplicationInsightsTelemetryWorkerService()
.ConfigureFunctionsApplicationInsights();This is a no-op in Aspire and may lead to some confusion from customers attempting to work with this registration. Aspire uses OTel instead, and this is brought in through ServiceDefaults. In Aspire contexts, builder.AddServiceDefaults(); as added into the Program.cs to bring this in. If you trace through that method, there's a block of code that can be uncommented to add the OTel exporter to use Application Insights / Azure Monitor:
// Uncomment the following lines to enable the Azure Monitor exporter (requires the Azure.Monitor.OpenTelemetry.AspNetCore package)
//if (!string.IsNullOrEmpty(builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"]))
//{
// builder.Services.AddOpenTelemetry()
// .UseAzureMonitor();
//}If we're in an Aspire context, we should therefore remove our own Application Insights wire-up from the Program.cs we scaffold. However, there is not presently a way for us to generally know if we're being scaffolded into an Aspire context. There may be an option for Visual Studio, which is to be evaluated by #1612. I'm opening this issue as blocked for now, and depending on the findings there, we may choose to separate this into another work item, unblocking the VS version at least.
The consequences of not removing this are not severe. The lines will not cause a problem themselves. It's just that it may be confusing to users.
As of #1630, we once again have the following in .NET (isolated worker model) templates:
This is a no-op in Aspire and may lead to some confusion from customers attempting to work with this registration. Aspire uses OTel instead, and this is brought in through ServiceDefaults. In Aspire contexts,
builder.AddServiceDefaults();as added into the Program.cs to bring this in. If you trace through that method, there's a block of code that can be uncommented to add the OTel exporter to use Application Insights / Azure Monitor:If we're in an Aspire context, we should therefore remove our own Application Insights wire-up from the
Program.cswe scaffold. However, there is not presently a way for us to generally know if we're being scaffolded into an Aspire context. There may be an option for Visual Studio, which is to be evaluated by #1612. I'm opening this issue as blocked for now, and depending on the findings there, we may choose to separate this into another work item, unblocking the VS version at least.The consequences of not removing this are not severe. The lines will not cause a problem themselves. It's just that it may be confusing to users.