This generator is not generating files. But build works fine

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

I’m using the source generator in the Attached screenshot. VS 2022 claims that the class does not implement the interface, but it compiles, build and debug without problems. Other developers of my team have the same problems, other developers of my team doesn't. The developers who doesn't have the problems, instead of the "this generators is not generating files." message, can see the generated files.

This seems to be the same problem: https://developercommunity.visualstudio.com/t/Code-generated-by-Source-Generator-is-ma/1636837?ref=native&refTime=1717591876532&refUserId=b37eec92-69bd-6611-a596-8af859bc02dd

![Uploading image.png…]()

---

Original Comments

Feedback Bot on 6/5/2024, 06:57 PM:

(private comment, text removed)

Graham Watts on 6/6/2024, 06:27 AM:

(private comment, text removed)

Sam Harwell [MSFT] on 6/6/2024, 08:08 AM:

(private comment, text removed)

William Bonazzoli on 6/6/2024, 08:39 AM:

(private comment, text removed)

Sam Harwell [MSFT] on 6/6/2024, 09:14 AM:

(private comment, text removed)

William Bonazzoli on 6/7/2024, 01:51 AM:

(private comment, text removed)

William Bonazzoli on 6/19/2024, 02:29 AM:

(private comment, text removed)

Feedback Bot on 6/18/2024, 10:18 PM:

(private comment, text removed)

Feedback Bot on 6/19/2024, 07:08 AM:

(private comment, text removed)

Sam Harwell [MSFT] on 6/19/2024, 08:55 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[CyrusNajmabadi]

Repro project is at: https://github.com/WilliamBonazzoliAbletech/BugSourceGenerator_10676451.

Looking now.

[CyrusNajmabadi]

Hrmm. Not seeing any issues on latest builds.

[CyrusNajmabadi]

i am getting;

2>c:\users\cyrusn\appdata\local\microsoft\visualstudio\17.0_f5ecc225roslyndev\extensions\microsoft\roslyn compilers\42.42.42.4242424\Microsoft.CSharp.Core.targets(147,10): error MSB4064: The "ReportIVTs" parameter is not supported by the "Csc" task loaded from assembly: Microsoft.Build.Tasks.CodeAnalysis, Version=4.6.8.25908, Culture=neutral, PublicKeyToken=31bf3856ad364e35 from the path: C:\Users\cyrusn\.nuget\packages\microsoft.net.compilers.toolset.framework\4.6.0\tasks\net472\Microsoft.Build.Tasks.CodeAnalysis.dll. Verify that the parameter exists on the task, the <UsingTask> points to the correct assembly, and it is a settable public instance property.
2>c:\users\cyrusn\appdata\local\microsoft\visualstudio\17.0_f5ecc225roslyndev\extensions\microsoft\roslyn compilers\42.42.42.4242424\Microsoft.CSharp.Core.targets(89,5): error MSB4063: The "Csc" task could not be initialized with its input parameters.

so i'm not sure if i'm fully repro'ing the user's scenario. @sharwell do yo uknow what's up with that ReportIVTs error?

[CyrusNajmabadi]

ok. so if i load the project in a normal release VS then it works fine from inside VS. oddly enough, the build itself fails with:

3>CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\sdk\9.0.100-preview.5.24307.3\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.dll' references version '4.9.0.0' of the compiler, which is newer than the currently running version '4.6.0.0'.
3>D:\github\BugSourceGenerator_10676451\WebApplication1\WeatherForecast.cs(18,16,18,21): error CS1061: 'Class1' does not contain a definition for 'Prop2' and no accessible extension method 'Prop2' accepting a first argument of type 'Class1' could be found (are you missing a using directive or an assembly reference?)

Since the command line build is failing, this may be an issue inside the compiler. Tagging in @chsienki

[CyrusNajmabadi]

@chsienki this fails to build 100% of the time in VS:

Microsoft Visual Studio Enterprise 2022 (64-bit) - Int Preview
Version 17.12.0 Preview 1.0 [35128.42.main]

Within VS this works fine:

No errors there, and goto def on Prop2 works:

So it works in vs, but not outside. Can you ptal.

[chsienki]

I can't repro in either case. @CyrusNajmabadi I suspect you have something funky going on with your SDK which is why you were seeing errors.

I suspect this might be a case of the non-reloadable generator issue. The repro provided by the customer has a generator referenced locally, so any changes made in the same VS session won't show up until VS is restarted. If one team member makes a change, it doesn't work in their VS, but when committed and opened on another team members machine it would now work because the generator got reloaded.

[wazzamatazz]

I commented on the original issue on Developer Community. In my case I was also referencing a local generator project rather than a package but there had been no changes to the generator project and the issue persisted after restarting Visual Studio. Visual Studio was reporting that other generators in the same project were generating files.

The generator that VS reported was not generating any files generated a class that was responsible for ensuring that the output assemblies for other projects in the solution were automatically loaded at runtime so that various types in those assemblies could be registered with the hosting application. The pipeline was constructed by combining the CompilationProvider and the AnalyzerConfigOptionsProvider on the generator context.

The generator was originally generating the entire class (i.e. it wasn't partial) but the only way that I could get rid of the red squiggles was to put a partial class and method declaration in the target project and then use the generator to provide the implementation.

The logic for initialising the generator was as follows:

public void Initialize(IncrementalGeneratorInitializationContext context) {
    // We want to regenerate source when the compilation or analyzer config options change.

    var pipeline = context.CompilationProvider
        .Combine(context.AnalyzerConfigOptionsProvider)
        .Select(static (item, _) => {
            var compilation = item.Left;
            var options = item.Right;

            var projectReferences = new List<string>();
            var diagnostics = new List<Diagnostic>();

            // This generator should only run for the hosting project
            if (!Constants.HostingAssemblyName.Equals(compilation.AssemblyName)) {
                return (projectReferences: projectReferences.ToImmutableArray(), diagnostics: diagnostics.ToImmutableArray());
            }

            var projectDir = options.GlobalOptions.TryGetValue("build_property.projectdir", out var path)
                ? new DirectoryInfo(path)
                : null;

            // Ensure that the project directory exists.

            if (projectDir == null) {
                diagnostics.Add(Diagnostic.Create(Diagnostics.ProjectDirUndefined, location: null, messageArgs: null));
                return (projectReferences: projectReferences.ToImmutableArray(), diagnostics: diagnostics.ToImmutableArray());
            }

            if (!projectDir.Exists) {
                diagnostics.Add(Diagnostic.Create(Diagnostics.ProjectDirNotFound, location: null, projectDir.FullName));
                return (projectReferences: projectReferences.ToImmutableArray(), diagnostics: diagnostics.ToImmutableArray());
            }

            var srcDir = projectDir.Parent;

            foreach (var reference in compilation.References) {
                var assemblySymbol = compilation.GetAssemblyOrModuleSymbol(reference);
                if (assemblySymbol == null) {
                    diagnostics.Add(Diagnostic.Create(Diagnostics.CannotResolveMetadataReference, location: null, reference.Display));
                    continue;
                }

                var referenceFile = new FileInfo(reference.Display);

                // If the referenced file is not in a subdirectory of the source directory, 
                // it has come from e.g. a NuGet package and we can skip it.
                if (!IsSubdirectory(srcDir.FullName, referenceFile.DirectoryName)) {
                    continue;
                }

                projectReferences.Add(assemblySymbol.Name);
            }

            projectReferences.Sort();
            return (projectReferences: projectReferences.ToImmutableArray(), diagnostics: diagnostics.ToImmutableArray());
        });

    context.RegisterSourceOutput(pipeline, (ctx, data) => {
        if (data.diagnostics.Length > 0) {
            foreach (var diagnostic in data.diagnostics) {
                ctx.ReportDiagnostic(diagnostic);
            }
            return;
        }

        if (data.projectReferences.Length == 0) {
            return;
        }

        var code = GenerateAssemblyLoaderCode(data.projectReferences);
        ctx.AddSource(
            "HostingAssemblyLoader.g.cs",
            SourceText.From(
                code,
                Encoding.UTF8));
    });
}

[WilliamBonazzoliAbletech]

I'm the author of the original issue on Developer Community. If you need more information don't hesitate to ask I have access to 5 PC, only 2 of them have the issue

I checked "dotnet --list-sdks" and "dotnet --list-runtimes" but I got no useful informations from it. Ex. PCs with Sdks 8.0.301 and 8.0.160 have the issue PCs with Sdks 8.0.200, 8.0.202 and 8.0.300 don't have the issue

[chsienki]

@WilliamBonazzoliAbletech If it's still reproducing it would be great to get ETW traces of the project when they are correctly and incorrectly generating files.

Unfortunately, the VS report a problem tool doesn't currently include the counters we need to debug the issue, but you can collect them manually with PerfView. Start with the instructions here: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/eventsource-collect-and-view-traces#collect-a-trace-1 but when you get to step 3 choose 'Collect' instead of 'Run' and in step 4, enter Microsoft-CodeAnalysis-General instead of Demo:1:4

Once the collection is running, go back to VS and perform an edit where you would expect the generator to run. I would suggest using your simple repro project if possible, to keep the traces as simple as possible. Do this collection on one PC where it is working and on one PC where it is failing, and we should hopefully be able to see what is/isn't running and why.

ETW files have a lot of potentially sensitive information in them, so please upload them via the original developer community post so they aren't publicly disclosed.

Happy to walk you through any of the needed steps if needed. Thanks!

[WilliamBonazzoliAbletech]

@chsienki The instructions were clear, thanks I got the PerfViewData.etl.zip file on both the PCs. I think I can't upload anything anymore on the original developer community post because it is closed, so comments and solutions are readonly How do you prefer to get the files? Do you want I submit another report on developer community just to attach the files?

[chsienki]

@WilliamBonazzoliAbletech Great, thanks! Yes, please open another developer ticket and upload the files there.

[WilliamBonazzoliAbletech]

@chsienki Done, you can find the new ticket at this link https://developercommunity.visualstudio.com/t/Private-trace-for-https:githubcomdot/10717549 Tell me if you nedd even more informations Thanks

[chsienki]

Got them, thanks @WilliamBonazzoliAbletech

@CyrusNajmabadi Going to tag you back in here. Looking at the two ETW traces I see something strange: in the correct one, I can see the generators running in ServiceHub.RoslynCodeAnalysisService, but in the incorrect one, the OOP process is present but doesn't run any generators at all. It seems like they just aren't being run in the IDE in the incorrect case.

I took a look at various events, and other than maybe more cancellation exceptions in the bad case, nothing jumps out as to why. I know we've made a lot of changes here in recent months between OOP and Auto/Balanced. Anything jump out at you as to why they wouldn't be running?

[WilliamBonazzoliAbletech]

If it can help resolve the problem 1) The problem appears to have arisen towards the end of May 2024 2) The problem is not specific to Visual Studio, opening the solution with Rider from the PC where I encountered the problem, the problem persists even on Rider