Redaction LoggerMessage generator fails when classification namespace requires global::

[dmeeze]

Description

Compilation fails with an error in Logging.g.cs

The issue seems to be that the generated method for a LoggerMessage static method generates a fully qualified name but not global prefix for the redaction classification attributes, eg:

       [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Gen.Logging", "10.1.0.0")]
       private static readonly Microsoft.Extensions.Compliance.Classification.DataClassification _Web_Classfications_SecretAttribute = new Bar.Classifications.SecretAttribute().Classification;

if the namespace of SecretAttribute is Bar.Classifications and the namespace of the class containing the LoggerMessage is Foo.Bar, this results in:

Logging.g.cs(**,**): Error CS0234 : The type or namespace name 'Classfications' does not exist in the namespace 'Foo.Bar' (are you missing an assembly reference?)

One workaround is to change the namespace, but where we have any overlap that's a little uncomfortable.

Reproduction Steps

Not completely but fairly minimal repro project at https://github.com/dmeeze/LogGeneratorRepro

• use logging and redaction (Microsoft.Extensions.Compliance.Redaction, Microsoft.Extensions.Telemetry)
• add <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> to csproj PropertyGroup to allow diagnosis
• create a data classification attribute X in namespace B.C
• create a partial class with a LoggerMessage partial static in namespace A.B
  • one parameter should be marked with attribute [X]
• try to compile

observe that the compiler complains in Logging.g.cs about being unable to find namespace A.B.C

Expected behavior

generated code should use global:: namespaces to prevent overlaps causing faults.

Actual behavior

generated code fails to compile.

Regression?

No response

Known Workarounds

move redaction classification attributes into a new namespace which has no conflicts with any part of any other namespace in the project.

Configuration

dotnet 10.0.101 (arm64)
macOS X v15.7

This does not appear likely to be environment or SDK specific.

Other information

i haven't yet proved this, but i'd guess
https://github.com/dotnet/extensions/blob/main/src/Generators/Microsoft.Gen.Logging/Parsing/Parser.cs#L559-L562
which seems to be where param attribute classes are resolved into strings requires might require the display format to explictly be SymbolDisplayFormat.FullyQualifiedFormat