GIS Converter - Logging - Warnings

Question

GIS Converter - Logging - Warnings

Dani_S 5,261

Hi Michel,

In continue to ticket : https://learn.microsoft.com/en-us/answers/questions/5665977/gis-converter-logging-code

Can you please help to fix these warnings:

warnings.txt

Thanks in advance,

Michael Le (WICLOUD CORPORATION) 7,795 Reputation points Microsoft External Staff Moderator

2025-12-17T10:25:15.4333333+00:00

I cannot access the warnings.txt file. Please make sure you are attaching the file correctly.
Dani_S 5,261 Reputation points

2025-12-17T11:22:52.4933333+00:00

Hi Michel,

Sorry the file loaded correctly.

Here are again he warnings.txt file.

warnings.txt

Please help to fix this warnings.

And updated Log file - from previous post.

Log.txt

Answer accepted by question author

0 additional answers

Your answer

Michael Le (WICLOUD CORPORATION) 7,795 Reputation points Microsoft External Staff Moderator

2025-12-17T10:25:15.4333333+00:00

I cannot access the warnings.txt file. Please make sure you are attaching the file correctly.
Dani_S 5,261 Reputation points

2025-12-17T11:22:52.4933333+00:00

Hi Michel,

Sorry the file loaded correctly.

Here are again he warnings.txt file.

warnings.txt

Please help to fix this warnings.

And updated Log file - from previous post.

Log.txt

Answer 1

Harry Vo (WICLOUD CORPORATION) 3,925 Microsoft External Staff Moderator

Hi @Dani_S ,

Most of these warnings are nullable reference type mismatches. Your classes implement logging interfaces (ILog, ILogger) but your method signatures don’t allow null where the interface says null is allowed.

So basically, it happens because nullable reference types are enabled. C# requires implementations to match the interface nullability exactly (object?, Exception?, etc.).

There is no immediate runtime danger. The code will still run. But you still have to update your method signatures to match the interface (? where required).

Dani_S 5,261 Reputation points

2025-12-17T12:03:51.14+00:00

Please see above. I added the files.
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-18T09:16:01.62+00:00

Hi @Dani_S , I've seen the file and my answer persists:

The issue comes from a mismatch in nullable references between your implementation and the interface (ILog/ILogger). Your methods need to match the interface’s nullability rules.

You can quickly fix it by updating your method signatures to accept nullable types (like object? and Exception?) and handle nulls properly. Or you can just use nullability attributes or suppress the warnings, but that’s really a last resort.
Dani_S 5,261 Reputation points

2025-12-18T09:46:55.3966667+00:00
I fixed the interfaces (ILog/ILogger)) and the their successors implementations.

Can I safely cast the message to string as follow?

For example:

public void Info(object? message)

{

try { _logger.LogInformation((string?)message); } catch { /* swallow - logging must be best-effort */ }

}
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-18T10:05:26.8266667+00:00
Hi @Dani_S , I don't think so.

(string?)message is not safe, as a direct cast will throw InvalidCastException if message is not actually a string. You should use ToString/Convert or pattern matching and handle nulls.

Example:

public void Info(object? message) { try { var text = message?.ToString() ?? string.Empty; _logger.LogInformation(text); } catch { // swallow — logging is best-effort } }
Dani_S 5,261 Reputation points

2025-12-18T10:28:09.0466667+00:00
1.I got now:

The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.

2.Chat said is it right? Which project level or per-file?

if project level-do it to all my projects?

Which to choose

• Prefer enabling nullable project-wide (<Nullable>enable</Nullable>) for new code: it improves safety and is the modern recommendation.

• Use #nullable enable for a quick per-file opt-in if you cannot change the project file.

Example — project-level change (recommended)

Which to choose

• Prefer enabling nullable project-wide (<Nullable>enable</Nullable>) for new code: it improves safety and is the modern recommendation.

• Use #nullable enable for a quick per-file opt-in if you cannot change the project file.

Example — project-level change (recommended)

Example — per-file opt-in

csharp GitConverter.Lib\Logging\NullLogger.cs

#nullable enable

using System;

namespace GisConverter.Lib.Logging

{

**public sealed class NullLogger : IAppLogger** **{** **public static readonly NullLogger Instance = new NullLogger();** **internal NullLogger() { }** **public void Debug(object? message) { /* intentionally no-op */ }** **public void Info(object? message) { /* intentionally no-op */ }** **public void Warn(object? message) { /* intentionally no-op */ }** **public void Error(object? message, Exception? ex = null) { /* intentionally no-op */ }** **}**

}
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-18T10:53:25.54+00:00

Hi @Dani_S

The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.

That warning means you are using nullable reference annotations (object?, Exception?,...) in code where nullable reference types are not enabled. If nullable annotations are not enabled, the compiler warns because ? has no defined context.

You can enable it at the project level by adding <Nullable>enable</Nullable> to the project file. This ensures consistency across all files and avoids having to repeat #nullable enable in every source file that implements interfaces such as ILog or ILogger.

The warning is about configuration, not a logic error. The code itself is fine; you just need to enable nullable reference types in the appropriate scope so the compiler can interpret the annotations correctly.
Dani_S 5,261 Reputation points

2025-12-18T12:03:11.48+00:00

Hi Michel,

There are more warnings now, can you please help ?

In project level of GisConvert.Lib I added <Nullable>enable</Nullable>.

All others projects had it.

1.Warnings

Warnings.txt

2.Logging Code

# GisConverter.Lib.txt

Logging

README.md.txt

IAppLogger.cs.txt

Log.cs.txt

Log4NetAdapter.cs.txt

LogHelper.cs.txt

NullLogger.cs.txt

3.Logging Tests Code

# GisConverter.TestsApp.txt

Logging Tests

README.md.txt

FileLoggingNegativeTests.cs.txt

FileLoggingTests.cs.txt

Log4NetAdapterTests.cs.txt

LogDisableTests.cs.txt

LoggingCollectionDefinition.cs.txt

MsLoggerAdapter.cs.txt

MsLoggerAdapterSwallowTests.cs.txt

MsLoggerAdapterTests.cs.txt
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-19T07:34:52.0233333+00:00
Hi @Dani_S

Enabling <Nullable>enable</Nullable> at the project level of GisConvert.Lib causes the compiler to re-evaluate all public APIs and interface implementations.

For now, the best approach is to suppress the nullable warnings in GisConvert.Lib.

<PropertyGroup> <Nullable>enable</Nullable> <NoWarn> CS8600;CS8602;CS8603;CS8604; CS8614;CS8619;CS8620;CS8625; CS8633;CS8767 </NoWarn> </PropertyGroup>

This is just a quick suppression step for now. A proper redesign that handles nulls would definitely be a better approach.
Dani_S 5,261 Reputation points

2025-12-19T07:40:34.1+00:00

Hi Harry,

Can you please use the better approach -a proper redesign that handles nulls .

I gave all the Logging Code + Logging Code Tests.

Thank in advance,
Dani_S 5,261 Reputation points

2025-12-19T07:42:05.0733333+00:00

Michel said: that the Logging Code us good + Logging Code Tests covered all tests.

Need only to fix the warnings.
Dani_S 5,261 Reputation points

2025-12-19T07:43:57.8133333+00:00

Most of the errors are in Log4NetAdapterTests.cs.

Harry Vo (WICLOUD CORPORATION) 3,925 Microsoft External Staff Moderator

Here are some examples you can have a look to modify your code:

Log4NetAdapterTests.cs - CollectingILog class: Change all method signatures to add ? for nullable parameters:

// BEFORE: 
public void Debug(object message) 
public void Debug(object message, Exception exception) 
public void DebugFormat(string format, params object[] args) 
public void DebugFormat(string format, object arg0) 
public void DebugFormat(string format, object arg0, object arg1) 
public void DebugFormat(string format, object arg0, object arg1, object arg2)
public void DebugFormat(IFormatProvider provider, string format, params object[] args) 
// AFTER: 
public void Debug(object?  message) 
public void Debug(object? message, Exception?  exception) 
public void DebugFormat(string format, params object? []? args) 
public void DebugFormat(string format, object?  arg0) 
public void DebugFormat(string format, object?  arg0, object?  arg1) 
public void DebugFormat(string format, object?  arg0, object? arg1, object? arg2) 
public void DebugFormat(IFormatProvider? provider, string format, params object?[]? args)

Apply the same pattern to all Info, Warn, Error, and Fatal methods.

MsLoggerAdapterTests.cs - CollectingLogger class

// BEFORE: 
public IDisposable BeginScope<TState>(TState state) => NullScope.Instance; 
public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter) 
// AFTER: 
public IDisposable?  BeginScope<TState>(TState state) where TState : notnull => NullScope.Instance; 
public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception, Func<TState, Exception?, string> formatter)

Also fix your assertions:

// BEFORE: 
Assert.True(msLogger.Messages.Any(m => m.IndexOf("hello", StringComparison.OrdinalIgnoreCase) >= 0)); 
// AFTER: 
Assert.Contains(msLogger.Messages, m => m.Contains("hello", StringComparison.OrdinalIgnoreCase));

MsLoggerAdapterSwallowTests.cs - ThrowingLogger class

// BEFORE: 
public IDisposable BeginScope<TState>(TState state) => null; 
public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter) 
// AFTER: 
public IDisposable? BeginScope<TState>(TState state) where TState : notnull => null; 
public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception, Func<TState, Exception?, string> formatter)

Overall, just add the ? nullable annotations and generic constraints where the interfaces require them.

Dani_S 5,261 Reputation points

2025-12-19T10:55:59.0266667+00:00

Hi Harry,

All GIS Converter - Logging - Warnings fixed.

There are more 18 warnings that connected to others files.

I will open a new ticket for them.

Thank you very much for your help.

You are a very professional programmer.
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-19T11:03:52.0666667+00:00

Thanks @Dani_S , I'm glad it fixes some of the issues!

Feel free to raise more questions, we're willing to help you all of the struggle!
Dani_S 5,261 Reputation points

2025-12-19T11:19:23.0233333+00:00
Another warning I forgot:

Warning:

Severity Code Description Project File Line Suppression State Details

Warning (active) CS8603 Possible null reference return. GisConverter.Lib D:\GIT\GitConverterEngine\GisConverter\GitConverter.Lib\Logging\Log.cs 188

Code:

`private static log4net.Core.Level ParseLogLevel(string logLevel)`

{

var levelMap = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)

{

["ALL"] = "ALL",

["DEBUG"] = "DEBUG",

["INFO"] = "INFO",

["WARN"] = "WARN",

["ERROR"] = "ERROR",

["FATAL"] = "FATAL",

["OFF"] = "OFF"

};

var normalizedLevel = (logLevel ?? "ALL").Trim().ToUpperInvariant();

var levelName = levelMap.ContainsKey(normalizedLevel) ? levelMap[normalizedLevel] : "ALL";

var entry = Assembly.GetEntryAssembly();

var repoAssembly = (Assembly)(entry ?? Assembly.GetExecutingAssembly());

var repo = LogManager.GetRepository(repoAssembly);

var hierarchy = repo as log4net.Repository.Hierarchy.Hierarchy;

return hierarchy?.LevelMap[levelName] ?? hierarchy?.LevelMap["ALL"];

}
Dani_S 5,261 Reputation points

2025-12-19T11:19:51.3333333+00:00

Compliant on this line:

return hierarchy?.LevelMap[levelName] ?? hierarchy?.LevelMap["ALL"];
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-22T07:27:28.0866667+00:00
Hi @Dani_S ,

return hierarchy?.LevelMap[levelName] ?? hierarchy?.LevelMap["ALL"];

From the compiler’s perspective:

hierarchy can be null

hierarchy.LevelMap[...] can return null

Therefore, the entire expression can evaluate to null

But your method signature returns log4net.Core.Level (non-nullable)

So the compiler is correctly warning that a null value could be returned.

If your design requires this method to always return a valid level, enforce it explicitly:

var level = hierarchy?.LevelMap[levelName] ?? hierarchy?.LevelMap["ALL"] ?? log4net.Core.Level.All; return level;

This removes the warning and makes the behavior explicit and safe.

If you find the situation is more complex than you expected, feel free to raise new questions on our platform!
Dani_S 5,261 Reputation points

2025-12-22T07:44:47.2733333+00:00

Hi Harry,

Thank you very much.

You are very professional programmer!!
Harry Vo (WICLOUD CORPORATION) 3,925 Reputation points Microsoft External Staff Moderator

2025-12-22T10:11:10.5533333+00:00

Thanks @Dani_S 😊, I'm really appreciate that!

Share via

GIS Converter - Logging - Warnings

0 additional answers

Your answer