we are using the SonarQube Server Developer Edition (v2025.2) with C#.
The rule S2629 seems to be correct für the Microsoft logging framework but I think it is misleading using log4net (3.0.0).
log4net can’t handle string pattern like the Microsoft logging framework does using named placeholders. Just index based placeholders for the string.Format method.
Using string interpolation with log4net causes an error by the rule S2629.
logger.Debug($“The value of the parameter is: {parameter}.”);
and the rule suggests to use this
logger.DebugFormat(“The value of the parameter is: {Parameter}.”, parameter);
But log4net does not support this. DebugFormat just uses string.Format internally and the correct using should be
logger.DebugFormat(“The value of the parameter is: {0}.”, parameter);
Additionally I think using the “normal” method Debug instead of DebugFormat with string interpolation should be also fine as the alternative (using string.Format internally) is not better as string interpolation.
So this should be fine with log4net:
logger.Debug($“The value of the parameter is: {parameter}.”);
We hit this case many times in our code and don’t want to disable the rule because we also use it for Microsoft logging where the rule is really helpful.
Correct me if I am wrong, but in my eyes the rule is misleading when working with log4net.
Thank you for acknowledging this as a false positive back in April 2025. It has now been almost a year since the ticket was opened and the issue was confirmed, but there has been no visible progress.
I am in the same situation – using both log4net and the Microsoft logging framework in the same codebase – so disabling S2629 globally is not a viable option. Any guidance would be appreciated.
Could you give us an update on where this stands in the backlog? Is there an estimated timeframe for a fix? Is there a workaround in the meantime that doesn’t involve disabling the rule entirely, such as a way to configure the rule per logging framework?
Thank you for your feedback.
I’ll come back to you soon with an update.
EDIT: We raised the priority of the ticket and we’ll do our best to fix this in one of the next hardening sprints scheduled for the second quarter of the year.
Meanwhile I’ll try to take a look next week and see if there’s any possible workaround on this.
Hi Mary
You mentioned you would try to take a look the following week to see whether there is any possible workaround.
Has there been any update on that, or on the ticket priority/fix timeline? We are still affected by this false positive.
I apologize - due to the current workload this task has been deprioritized in my list (I should have sent an update).
I have set a reminder already to take a look tomorrow that I have some time.
Thanks for your patience.
The only workaround currently is to use the DebugFormat method or suppress the rule.
The first would be pleasing the rule, the second makes unfortunately more sense until we fix this.
Since there’s traction here I have increased the priority of this in our backlog to fix ASAP.
I want to correct myself — in my previous reply I incorrectly called this a false positive and suggested suppressing the rule as a workaround. That was wrong, and I apologize for the confusion.
After digging into the log4net source in more detail, S2629 is flagging a real issue. The core problem is eager string interpolation. When you write:
logger.Debug($"The value of the parameter is: {parameter}.");
The problem is that the formatting seems to happen even if debug levels are disabled.
The rule’s suggestion uses named placeholders ({Parameter}) following the Microsoft.Extensions.Logging convention, but log4net only supports indexed placeholders ({0}, {1}, ...). So for log4net the fix is:
Instead of: logger.Debug($"The value of the parameter is: {parameter}.");
Use: logger.DebugFormat("The value of the parameter is: {0}.", parameter);
We’ll look at making the suggestion clearer for log4net users, but the rule is working as intended.
Again I’m sorry for the confusion - I’m working on this ticket now and I went down all the calls for logger.Debug to re-verify how things work.
Let me know if I have totally missed something!
The message update will come soon - I’ll let you know here when it’s released.
Best
Mary
EDIT: This concerns also Castle.Core - the rule has been updated to give a correct suggestion also for this library.
we’ve updated the issue messages in this rule and the description.
It’s part of the 10.27 latest release which is already available in SonarQube Cloud and via NuGet and will be available in the next release of Sonarqube Server.