Razor intellisense not finding types in referenced project that consumes a source generator

[gulbanana]

I have a model project which contains generated code, produced by a source-generator in a nuget package. I also have a blazor application which references this model project and uses its types. When using Visual Studio 17.7, that works fine in .cs files, but in .razor files there is no code completion for generated types and Go To Definition doesn't work. The project builds, but it's difficult to work on it productively.

https://github.com/gulbanana-bugs/repro-razor-intellisense is a repository demonstrating the issue. Steps to reproduce:

1. Open broken.sln and working.sln in Visual Studio.
2. Build the solutions; both should compile successfully.
3. Observe that in broken.sln, WebApp1/Pages/Index.razor doesn't know about the type IFoo. Pressing ctrl-. after typing "foo." does nothing, and go to definition on foo.Bar() doesn't work either.
4. These functions work in WebApp1/Pages/Index.razor.cs, as well as in working.sln's WebApp2/Pages/Index.razor and WebApp2/Pages/Index.razor.cs. The difference is that working.sln uses a <Reference> instead of a <ProjectReference> to ClassLib.

Broken .razor intellisense:

Working .cs intellisense:

[davidwengier]

@jasonmalinowski heads up, I haven't investigated this yet, but I suspect it will be coming your way as I cannot fathom how this could possibly be a Razor tooling issue 😁

[davidwengier]

Well this is interesting. If I type a . I can repro no completion with the supplied project. If I press Ctrl+J to invoke completion, after the . is already in the document, I get only IntelliCode completions. I find this very surprising, but adds weight to this being a Roslyn issue, surely.

[davidwengier]

I debugged through this and confirmed that the Roslyn LSP was not sending us back any completions.

[mpagliaro98]

I'm running into this same issue as my company is transitioning to building our product in Blazor. I wrote several source generators that generate static classes, and those static classes have several readonly static properties. These live in a class library referenced by the Blazor web app project. In my razor files, text completions do not appear for any of the generated files in the referenced project. This is making it difficult to develop new pages, as the results of the source generators are used frequently, and we have to directly dig into the generated code and copy the name we want to use, or reference documentation instead of having the full list easily available in text completions.

I've also made a minimal reproduction of my issue: https://github.com/mpagliaro98/IntellisenseTest

There's more details in this stackoverflow post I originally made, before I was pointed here, but I believe this issue is the same as what I'm facing: https://stackoverflow.com/questions/78321911/intellisense-not-finding-generated-code-in-referenced-project

[gulbanana]

Yep, that's the same issue. I believe this will become more of a problem over time, as source generators and razor are both growing in popularity.

Here's a workaround I'm using at the moment: load the class library with the generators using <Reference> rather than <ProjectReference>. This will avoid the missing Roslyn feature because its workspace doesn't know about the generator source code.

An example - in the class library:

    <Target Name="HideFromRoslyn" AfterTargets="Build" Inputs="$(OutputPath)\$(AssemblyName).dll" Outputs="$(OutputPath)\hidden\$(AssemblyName).dll">
        <Copy SourceFiles="$(OutputPath)\$(AssemblyName).dll;$(OutputPath)\$(AssemblyName).pdb" DestinationFiles="$(OutputPath)\hidden\$(AssemblyName).dll;$(OutputPath)\hidden\$(AssemblyName).pdb" />
    </Target>

And in the web project:

    <Reference Include="..\ClassLib\bin\$(Configuration)\$(TargetFramework)\hidden\ClassLib.dll" />

[mpagliaro98]

What side-effects have you noticed from using this workaround? I've not done it myself, but I understand that referencing a dll instead of a project causes things like find by reference to not work on references in the dll, or issues coming up with multiple versions of the dll needing to be referenced. The project I'm working on is a large enterprise application deployed through Azure, so any workaround I go with would be safe and work in all use cases (until this gets fixed)