roslyn-sdk

roslyn-sdk copied to clipboard

Is there a global IServiceProvider or ILoggerFactory I can call to get an ILogger<> instance from my implementation of ISourceGenerator?

Did I post this in the correct place?

There isn't a global logger, but you can report diagnostics when necessary. Can you provide some additional information about the motivating scenario?

It's for testing. Currently I see odd behavior in the analyzer based on why MSBuild started the build. For example, if my source generator has dependencies, they don't always wind up being copied to the analyzer launcher folder, it's just the DLL for the analyzer that gets copied, so I have to locate build output for the source generator relative to the solution folder and copy the dependencies.

But sometimes the Source Generator is run from its build folder, in which case copying is unnecessary.

If I could get an instance of ILogger<> during static initialization then I could write all of the paths and such that were in play directly to the build output. Console.WriteLine is inconsistent, and I think it's because whatever is choosing where to execute the source generator from a specific location consumes stdout in some scenarios, but not others.

Having a stable logger would also allow me to confidently utilize a repeatable, event-driven framework for source generation and to execute test runs that utilize an ILogger that outputs to xUnit when unit testing the framework.

For example, if my source generator has dependencies, they don't always wind up being copied to the analyzer launcher folder, it's just the DLL for the analyzer that gets copied, so I have to locate build output for the source generator relative to the solution folder and copy the dependencies.

This sounds like a configuration error. For debugging this, I would recommend building the project which uses the source generator with -bl, and then using the MSBuild Structured Log Viewer to review the resulting build log. The error can be detected by finding the place(s) where source generator binaries are passed to the Csc task through the Analyzers property; one or more dependencies is getting omitted from this list which you can trace back from this location.

... then I could write all of the paths and such that were in play directly to the build output ...

This is already included in the build output when -bl is passed to MSBuild (see previous paragraph).

Having a stable logger would also allow me to confidently utilize a repeatable, event-driven framework for source generation and to execute test runs that utilize an ILogger that outputs to xUnit when unit testing the framework.

I highly recommend using Microsoft.CodeAnalysis.CSharp.SourceGenerators.Testing.XUnit for testing the source generator. It's constructed over multiple years based on the literal dozens of cases where test authors failed to account for a wide variety of important cases that led to product regressions. The tests have a straightforward form:

await new VerifyCS.Test
{
    TestState =
    {
        Sources = { "source1", "source2" },
        AdditionalFiles = { ("/0/AdditionalFileName.txt", "content") },
        GeneratedSources =
        {
            (typeof(TGenerator), "HintName.cs", "Generated content"),
        },
    },
}.RunAsync();

A complete example can be seen here:

https://github.com/dotnet/roslyn-analyzers/blob/79e037ac130e1a02f5efa5d4c14b5def30b4fb21/src/Microsoft.CodeAnalysis.ResxSourceGenerator/Microsoft.CodeAnalysis.ResxSourceGenerator.UnitTests/ResxGeneratorTests.cs#L82-L158

I would recommend building the project which uses the source generator with -bl

How do you add msbuild command line parameters to the csproj file?

Bump.