Compile-time logging source generation example triggers analyzer error "partial method must have an implementation part because it has accessibility modifiers"

[wjrogers]

When I write a class like the one in the example on this page,

public static partial class Log
{
    [LoggerMessage(
        EventId = 0,
        Level = LogLevel.Critical,
        Message = "Could not open socket to `{hostName}`")]
    public static partial void CouldNotOpenSocket(
        ILogger logger, string hostName);
}

the IDE flags it with an error:

Partial method 'void CouldNotOpenSocket(ILogger, string)' must have an implementation part because it has accessibility modifiers.

However, the code compiles and executes successfully. Will you please add some guidance to this page about this error, especially if there is a way to silence it?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6fc4ecf0-19e4-54d3-c34e-b6eadb80262b
• Version Independent ID: decc74aa-a2d5-8727-f22b-3862bacde737
• Content: Compile-time logging source generation
• Content Source: docs/core/extensions/logger-message-generator.md
• Product: dotnet-fundamentals
• GitHub Login: @maryamariyan
• Microsoft Alias: maariyan

---

Associated WorkItem - 68965

[tdykstra]

@maryamariyan can you help with this question?

[maryamariyan]

thanks will take a look

[maryamariyan]

I got a repro for this. Thanks for your report @wjrogers.

@pranavkm what approach do you recommend to silence a diagnostic?

[pranavkm]

You could use a pragma warning suppress to do this: https://docs.microsoft.com/dotnet/fundamentals/code-analysis/suppress-warnings#use-a-preprocessor-directive

[dotnetshadow]

You could use a pragma warning suppress to do this: https://docs.microsoft.com/dotnet/fundamentals/code-analysis/suppress-warnings#use-a-preprocessor-directive

I did try the following but the error still came up

#pragma warning disable CS8795 // Rethrow to preserve stack details

Also the link to this doc produces an 404
https://docs.microsoft.com/en-us/dotnet/csharp/misc/sorry-we-don-t-have-specifics-on-this-csharp-error?f1url=%3FappId%3Droslyn%26k%3Dk(CS8795)

[maryamariyan]

Also the link to this doc produces an 404
https://docs.microsoft.com/en-us/dotnet/csharp/misc/sorry-we-don-t-have-specifics-on-this-csharp-error?f1url=%3FappId%3Droslyn%26k%3Dk(CS8795)

FYI, this issue is tracked by #23900

[ds185357]

I got the same behavior. The code compiles successfully, but VS with static analysis enabled produces CS8795 and CA1822. The CA1822 can be suppressed, CS8795 cannot.

[stap123]

I also get the CS8795 error for all methods. The project successfully compiles and works as expected but VS 2022 shows an error for every method.

I'm not sure this is actually a doc error and not a VS 2022 issue?

[seangwright]

I experience this same issue. #pragma directives didn't solve it. However I was able to resolve the errors by authoring the code, then closing VS, and finally starting VS and opening the solution back up. No amount of rebuilding solutions/projects or closing/reopening files solved the issue. I had to restart VS.

I've noticed this same issue with other source generator related code/libraries and it was solved in the same way.

Note: I am using Visual Studio 17.1.1

[shashank-raut]

I can too confirm that closing and opening the Visual Studio solved this issue for me.
Visual Studio Details - Microsoft Visual Studio Professional 2022 (64-bit) - Current
Version 17.1.3

[jasonvasquez]

For what it's worth, I see this issue with Rider as well. I suspect it's not a Visual Studio issue specifically, but perhaps a Roslyn issue. (The same close and re-open workaround works with Rider)

[RealDotNetDave]

I have the same issue, but only when the solution builds on Linux.

[tdykstra]

@maryamariyan I can't repro this in VS 2022 17.5, so it seems to have been at least partially addressed, just not in Linux per @RealDotNetDave. That being the case it seems not to be a docs issue -- should I transfer this issue to the runtime repo?

[tdykstra]

ping @maryamariyan

[dbead]

Seems fixed atm in 17.5.2 for me but was happening in 17.5.1 using dotnet 6.

[maryamariyan]

cc @dotnet/area-extensions-logging

[layomia]

Thanks @maryamariyan.

@RealDotNetDave are you still seeing this issue on Linux with the latest VS version?

[wjrogers]

I can't reproduce the error in VS 17.5.2, either. I notice that the generated source (visible in Solution Explorer under Dependencies > Analyzers) updates almost immediately after editing the LoggerMessage attribute, even without saving the file. A couple versions ago, I had noticed these generated sources didn't update until a complete Visual Studio restart. Possibly a related issue has been fixed?

[MrBildo]

I'm still seeing this issue in 17.5.4. No amount of suppression makes it go away. I have NoWarn in my project. .serverity = none in .editorconfig. Like others, it'll go away for a little while then crop back up.

I'm seeing it using the https://mapperly.riok.app/ library which uses heavy source generation.

Edit: I'm not using Linux

[tdykstra]

@layomia Given that it looks like this may still be an issue, is the runtime repo the right place to transfer this issue to?

[tarekgh]

This looks the same issue dotnet/roslyn#58913 and supposes to be fixed a while ago by dotnet/roslyn#58990.

@jasonmalinowski do you know why this still repro for the users?

CC @Youssef1313

[MrBildo]

I'm happy to provide more details. Again, this is being triggered from a 3rd party library, which certainly is the underlying cause. However, I would expect to be able to suppress it in some way.

[Youssef1313]

This is roslyn-related issue.

I see dotnet/roslyn#67123 which mentions:

IntelliSense not working correctly (red squiggly lines all over the place for generated members)

So this seems very similar.

[Youssef1313]

Also there is dotnet/roslyn#65044

[tdykstra]

This looks the same issue dotnet/roslyn#58913 and supposes to be fixed a while ago by dotnet/roslyn#58990.

@jasonmalinowski do you know why this still repro for the users?

@tarekgh Can we close this as a duplicate of dotnet/roslyn#58913? It doesn't appear to be a doc issue.

[jasonmalinowski]

Yeah, this is a product bug, so I'm not sure why we'd document workarounds rather than, well, fixing it.

[tarekgh]

Can we close this as a duplicate of dotnet/roslyn#58913? It doesn't appear to be a doc issue.

@MrBildo was claiming the issue is still reported from a third-party library #27471 (comment). If this is not the case anymore then we can close. Otherwise, it will be good if @MrBildo provide a repo if the issue is still showing up.

[MrBildo]

In the case of Mapperly, the library I was using, it is no longer an issue, nor have I seen it recently with other source generators. Something fixed it along the way. I no longer have an issue. Regardless it doesn't seem like a doc problem.

[jasonmalinowski]

Yep: if there's an issue here, the issue should be in the Roslyn repo as a bug, not a doc issue asking for a workaround. This can just be closed.