Enable configuration support for Google.Cloud.Diagnostics.AspNetCore
See original GitHub issueWhen using the Google.Cloud.Diagnostics.AspNetCore.GoogleDiagnosticsWebHostBuilderExtensions.UseGoogleDiagnostics
extension, there is an assumption that the Google Cloud project ID is hardcoded. This is seen in the examples:
string projectId = "[Google Cloud Platform project ID]";
var webHost = new WebHostBuilder()
.UseGoogleDiagnostics(projectId)
.UseStartup<Startup>()
.Build();
Looking at the extension, it appears this roughly boils down to a call to IWebHostBuilder.ConfigureServices(Action<IServiceCollection>)
where several things get registered with DI.
There is another overload IWebHostBuilder.ConfigureServices(Action<WebHostBuilderContext, IServiceCollection>)
where the web host can provide configuration for the app via WebHostBuilderContext.Configuration
. This allows configuration to be set up then passed in to drive later registrations.
It would be helpful if there was a way to use this overload to avoid having to set up configuration multiple times (one for use in GCP calls, one for the actual app) and avoid hard coding.
For example, something like this:
public static IWebHostBuilder UseGoogleDiagnostics(this IWebHostBuilder builder, string projectIdKey = null, string serviceNameKey = null, string serviceVersionKey = null)
{
builder.ConfigureServices((context, services) =>
{
var projectId = projectIdKey == null ? null : context.Configuration[projectIdKey];
var serviceName = serviceNameKey == null ? null : context.Configuration[serviceNameKey];
var serviceVersion = serviceVersionKey == null ? null : context.Configuration[serviceVersionKey];
// then register the stuff as usual.
}
return builder;
}
A workaround would be to allow the GoogleDiagnosticsStartupFilter
class to be public so folks could effectively write this overload as an app-specific extension. Unfortunately, with the GoogleDiagnosticsStartupFilter
being internal, one can’t actually write a custom version of the extension in a very clean fashion.
Issue Analytics
- State:
- Created 5 years ago
- Comments:23 (22 by maintainers)
I’ll be submitting option number 2 then, we can revisit number 3 in the future if we really need it.
Let me take a closer look at that. I’ll updata here.