Roslyn: Unable to find roslyn workspace in Source Generators

[ysmoradi]

I've read both cookbook and design document and I was unable to find out the way I can get an instance of roslyn's Workspace.
I've several code generators that heavily depend on Roslyn workspace and they do need both syntax trees and compilations.
I'm using MSBuild tasks to run my code generators and there is a performance penalty here because I'm creating a new instance of MSBuildWorkspace and I'd like to make it better using source generators.

[jmarolf]

Some of the services that currently live in the workspace layer will likely need to be moved down to the compilation layer for source generators.

Access to the compilation and services that related to that make sense to me. I assume you do not depend on anything that is looking as the solution or other global settings?

[ysmoradi]

Sorry, but I'm not getting your point )-:
Could you please make it clear to me.
Thanks

[tmat]

By design, analyzers and code generators do not have access to the Workspace. What do you use MSBuild tasks for?

[ysmoradi]

This is a nuget package that I've which contains MsBuild task
And this is the msbuild task source code.
In the MsBuild task, I run an exe that contains my code generator source code code.
I the code, I create an instance of MsBuildWorkspace because I need the data it provides. For example, projects, class declarations, comments, solution path, etc.

[jcouv]

FYI @chsienki

[sharwell]

@ysmoradi I have marked this as By Design since workspace assemblies are not available in compilation scenarios. I'm leaving this open for discussion to find alternative approaches to achieving your ultimate end goals.

[iSazonov]

I am PowerShell repo maintainer and I want to share a related feedback.
PowerShell consists of several csproj files that link to another ones (tree). We have a custom script and tool to generate a dictionary based on assemblies, one from cscroj-s (SDK,csproj) depends on. On first step, the script gets Project.References for the SDK,csproj using dotnet msbuild, custom target and build the project at design time. On second step, we use our custom tool to generate from the assembly list a dictionary (type name -> full-qualified assembly name). The dictionary is placed and used in another csproj (SMA.csproj).
I created a draft of a source generator and add reference to it in SDK,csproj file. After I run a build of whole PowerShell I get in the source generator the Compilation for _whole PowerShell_.

1. My expectations were that if I attached a generator to this SDK,csproj project, then I would receive a Compilation for this project and not for all csproj-s.
2. In the example I guess it is not critical to add the generated source code to the Compilation for whole PowerShell. But in general, projects could be more independent (ex.: in different nuget packages) and in the case a code could be generated in one project for another project.
3. I wonder does it make sense to reference a source generator not in a root csproj file?
4. I wonder is it possible to get more granular information from MSBuild about build process (since source generators is for build process) now or in future?

Now I see the only way to resolve the problem - to use Workspace.OpenProject() with hard-coded path to SDK,csproj file. Thoughts?

[jasonmalinowski]

@iSazonov I've moved your concern to https://github.com/dotnet/roslyn/issues/49417 so we can track it separately since I think there's answers there but maybe not to the original issue.