-
Notifications
You must be signed in to change notification settings - Fork 786
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Derived method 'TryCreateLogger' in type 'OpenTelemetry.Logs.LoggerProviderSdk' from assembly 'OpenTelemetry, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7bd6737fe5b67e3c' cannot reduce access. #5741
Comments
@ChuanGoing, could you please provide us Minimal, Reproducible Example? It can be separate repository with the problematic code. It should not include any internal business logic, just scaffolding of code to reproduce issue. |
We have the same problem, using the following packages. (Downgrade to 1.8.X fixes the problem.) My guess is that this change is the reason: EDIT:
|
I also met this issue after we added this package : Below are all packages we are using :
|
We are having the same problem with the following packages installed:
Downgrading them ALL to 1.8.1 fixes the problem. Likewise, upgrading any one of them to 1.9.0 reintroduces the problem. If this method is not called, then the problem does not occur: public static WebApplicationBuilder WithOpenTelemetry(this WebApplicationBuilder builder)
{
const string serviceName = "my-web-app";
builder.Logging.AddApplicationInsights();
builder.Logging.AddOpenTelemetry(options =>
{
options.IncludeScopes = true;
options.IncludeFormattedMessage = true;
options.SetResourceBuilder(ResourceBuilder.CreateDefault()
.AddService(serviceName));
});
builder.Services.AddOpenTelemetry()
.ConfigureResource(resource =>
{
resource.AddService(serviceName);
})
.WithTracing(tracing =>
{
tracing.AddAspNetCoreInstrumentation();
})
.WithMetrics(metrics =>
{
metrics.AddMeter("My.WebApp");
metrics.AddAspNetCoreInstrumentation()
.AddRuntimeInstrumentation();
})
.UseAzureMonitor(options =>
{
options.ConnectionString = builder.Configuration["ApplicationInsights:ConnectionString"];
});
return builder;
} |
I've narrowed this to an incompatibility between Here's a minimal repro:WebApplication1.csproj<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="OpenTelemetry" Version="1.8.1" />
<PackageReference Include="OpenTelemetry.Api.ProviderBuilderExtensions" Version="1.9.0" />
</ItemGroup>
</Project> Program.csnamespace WebApplication1
{
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
public class Program
{
public static void Main(string[] args)
{
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddLogging(logging => logging.AddOpenTelemetry());
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
}
}
} Additional ReproThis combination may be more common for users: csprojIn this example, these are the latest versions of these two packages. <ItemGroup>
<PackageReference Include="Azure.Monitor.OpenTelemetry.AspNetCore" Version="1.2.0" />
<PackageReference Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.9.0" />
</ItemGroup> Program.csIn this example, builder.Services.AddOpenTelemetry().UseAzureMonitor(); |
Upgrading OpenTelemetry to @CodeBlanch - FYI |
I'm sorry for the late response. After encountering the issue last time, I resolved it by downgrading OpenTelemetry.Instrumentation.EntityFrameworkCore to version 1.0.0-beta.11, but I didn't personally investigate the root cause |
@vishweshbankwar That's not a fix. Upgrading the packages I mentioned above to 1.9.0 is what causes this issue for us. Edit: These 3 are the only ones we have installed: All other packages are up to date in the solution. |
Lots to unpack here! 🤣 Let's start with root cause. In API public class LoggerProvider : BaseProvider
{
internal virtual bool TryCreateLogger(string? name, out Logger? logger) {}
} API previously: internal class LoggerProvider : BaseProvider
{
protected virtual bool TryCreateLogger(string? name, out Logger? logger) {}
} The SDK ( SDK internal sealed class LoggerProviderSdk : LoggerProvider
{
internal override bool TryCreateLogger(string? name, out Logger? logger) {}
} SDK previous: internal sealed class LoggerProviderSdk : LoggerProvider
{
protected override bool TryCreateLogger(string? name, out Logger? logger) {}
} The issue is going to manifest if you have The fix is to add a reference to This report:
I'm having trouble reconciling that. Because there is no My guess would be it is something more like...
Getting the SDK transitively is the issue here.
Or do the direct reference. What you want to see in your graph is SDK + API versions matching: Bad: Good: Also good (direct reference added to SDK): What could be done to improve this? We have run into other issues before with users on newer instrumentation libraries and older SDKs. @rajkumar-rangaraj @vishweshbankwar @Kielek The way our CI is set up we always test SDK using latest API. Perhaps we should have some steps which test latest API packages using previous SDK? We sort of assume users will be on same version of API & SDK but the way instrumentation libraries work it is easy for graphs to become mismatched. |
@CodeBlanch, correct me if I am wrong, but it is the root cause of the issue:
I suppose that we could add some msbuild task to detect such cases and rise warning if there is incompatibility version between |
I'm also having this issue, can this be reopened? |
The issue is something which was previously
I'm not opposed to this but I would be concerned the net result long term would be users getting stuck on old versions. We can discuss more on SIG?
We could reopen this but I'm not sure what could be done. To fix update your graph so API + SDK packages are on the same version. Let's say we release a new |
I just faced this problem trying to use OpenTelemetry.Instrumentation.StackExchangeRedis version 1.9.0-beta.1 |
) # Pull Request Template ## Description Current OpenTelemetry sample gives runtime error due to mismatched OpenTelemetry version. This is tracked in the Otel repo here: open-telemetry/opentelemetry-dotnet#5741 There is no GA Azure Monitor Otel exporter version that uses OpenTelemetry 1.9.0, so we need to manually lift the version to avoid runtime errors. ## Type of change Please delete options that are not relevant. - [x] Bug fix (non-breaking change which fixes an issue)
A few months later, I came back because I found that some older projects were referencing OpenTelemetry.Instrumentation.EntityFrameworkCore-1.0.0-beta.12, and re-releasing also had this issue. Downgrading to version 1.0.0-beta.11 resolved it. So, why does this package have such an issue, and no one has answered this question? |
Package
OpenTelemetry
Package Version
Runtime Version
.NET6.0
Description
When recompiling and running my application, an error occurs during the startup phase:
The derived method 'TryCreateLogger' in type 'OpenTelemetry.Logs.LoggerProviderSdk' from assembly 'OpenTelemetry, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7bd6737fe5b67e3c' cannot reduce access.
Description: The application relies on OpenTelemetry related packages to provide APM functionality. After encountering the error, I compared it with another application (which starts normally), which references OpenTelemetry.Api version 1.8.1. This led me to suspect that there might have been changes in the OpenTelemetry.Api version 1.9.0 update.
Steps to Reproduce
Upgrading from OpenTelemetry.Api 1.8.1 to 1.9.0 can reproduce the issue.
Expected Result
I hope to locate the problem as soon as possible.
Actual Result
The above exception message is encountered.
Additional Context
No response
The text was updated successfully, but these errors were encountered: