Can't debug source generator using roslyn component if total dependency file path lengths is too big

[KieranDevvs]

Here is a repo with steps to reproduce the problem: https://github.com/KieranDevvs/SourceGeneratorBugSample/tree/master
I also encounter this when referencing non nuget packages i.e David Fowlers Bedrock.Framework package. (I can't confirm this as it is the only package that I have used that is not in a nuget.org feed thus the problem may be related to something else).

This is using the 5.0.400 SDK in VS2019 version 16.11.1 (also described within the repo readme).

Steps to reproduce:

1. Install the .NET compiler platform SDK (described in this post: http://stevetalkscode.co.uk/debug-source-generators-with-vs2019-1610)
2. Clone the repository and open it in visual studio 2019 version 16.11.1.
3. Build the solution and find no build errors.
4. Set the SourceGenerator project to be the startup project.
5. Debug the project.
6. See error:

7. Open the SomeLibrary csproj file and remove <FrameworkReference Include="Microsoft.AspNetCore.App" />.
8. Debug the project again, this time no error will show and the project will successfully execute with the debugger attached.

This also appears to occour with dependencies that arent in nuget.org (I cant confirm this easily as I have only used one dependency that did not come from nuget.org thus, this may just be a coincidence).

[Skleni]

I just encountered the same problem, however I'm trying to generate source for an ASP.NET Core project which doesn't have an explicit <FrameworkReference Include="Microsoft.AspNetCore.App" /> element in the .csproj file.

[KieranDevvs]

I just encountered the same problem, however I'm trying to generate source for an ASP.NET Core project which doesn't have an explicit <FrameworkReference Include="Microsoft.AspNetCore.App" /> element in the .csproj file.

Could you post the reference list you are using please?

[Skleni]

For the generator project:

<ItemGroup>
  <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.2" PrivateAssets="all" />
  <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.11.0" PrivateAssets="all" />
  <PackageReference Include="Scriban" Version="4.0.1" IncludeAssets="Build" />
  <PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
</ItemGroup>

For the target project:

<ItemGroup>
  <PackageReference Include="AutoMapper.Extensions.Microsoft.DependencyInjection" Version="8.1.1" />
  <PackageReference Include="Azure.Extensions.AspNetCore.Configuration.Secrets" Version="1.2.1" />
  <PackageReference Include="Azure.Identity" Version="1.4.1" />
  <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.18.0" />
  <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="5.0.9" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="5.0.9">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
  </PackageReference>
  <PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="5.0.9" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.9" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.Design" Version="1.1.6" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.9">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
  </PackageReference>
  <PackageReference Include="NSwag.AspNetCore" Version="13.13.2" />
  <PackageReference Include="SimpleInjector" Version="5.3.2" />
  <PackageReference Include="SimpleInjector.Integration.AspNetCore.Mvc.Core" Version="5.3.0" />
  <PackageReference Include="softaware.CQS.SimpleInjector" Version="3.0.0" />
</ItemGroup>.

Additionally, there are 4 project references to .NET 5 libraries in the same solution as well as the generator project

[chsienki]

This is a known issue with the component debugger: we pass the CSC command line to CreateProcess as part of starting debugging. At some point it becomes too large for windows to handle, and the process fails to start.

We have a fix in the works that will use an RSP file instead.

[ElanHasson]

@chsienki Thanks for the update.

Can I work around this by shortening the path to the target project? via a symlink/junction?

[ElanHasson]

Answer is no: **

**

To clarify, the project seems to have to be what is loaded in the sln as a debug target also (guess)

[KieranDevvs]

This is a known issue with the component debugger: we pass the CSC command line to CreateProcess as part of starting debugging. At some point it becomes too large for windows to handle, and the process fails to start.

We have a fix in the works that will use an RSP file instead.

Will this go out as part of .NET 6 / VS2022?

[chsienki]

@KieranDevvs We had hoped to ship it in VS 2022 (this a VS only component decoupled from .NET releases) but it looks unlikely now due to scheduling. It should make it into 2022 update 1 though.

[chsienki]

Can I work around this by shortening the path to the target project? via a symlink/junction?

@ElanHasson Yeah, it won't work if the path to the project isn't the same project thats loaded inside VS. We use VS to query the launch arguments, and it doesn't know about a symlink version as it (incorrectly) thinks they're different projects due to path mismatch.

I think if you symlink and change the SLN path to be the symlink it should work. Not great but might get you unblocked.

Another option is to skip the component debugger altogether and launch it manually. If you build your 'target' project with /bl you can extract out the command line. If you paste that into a response (.rsp) file somewhere, you can make a manual launch profile by adding something like this to your launchSettings.json file.

{
  "profiles": {
    "Manual Component": {
      "commandName": "Executable",
      "executablePath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\MSBuild\\Current\\Bin\\Roslyn\\csc.exe",
      "commandLineArgs": "@\"path\\to\\args.rsp\"",
      "workingDirectory": "\"path\\to\\targetProjectDir\""
    }
  }
}

Note that you'll need to update the command line if you add files or change references on the target project.

[ElanHasson]

Thanks @chsienki, if I get time to circle back around I'll give it a try. Right now I just copy and pasted code I wanted to have generated 😢

Can you share an example .rsp?

[bart-degreed]

I’m experiencing the same limitation, using both VS 2019 and VS 2022. I didn’t see anything in ProcMon that relates to this error, so it seems CreateProcess is never even called. Based on my experiments, it seems source generators can only be debugged in extremely simple projects without real-life dependencies such as ASP.NET and third-party libraries.

Please prioritize to fix this, because source generators are quite useless for production this way. The momentum is now, if you’re going to hold off a fix for another six months, nobody cares anymore and we’ve already chosen a competing solution without source generators.

[mrgleba]

This error persists event with long paths enabled:
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Is VS2022 long path aware?
Would that solve the problem if it were?

[twsouthwick]

I just tried using this feature after upgrading to 17.1 Preview 2 and seeing the same issue. Is it still planned on making it into 17.1?

[KieranDevvs]

@chsienki Just saw the announcement for 17.1 GA, I assume this didn't make the cut?

[chsienki]

@KieranDevvs Hmm, I thought it made it in, but i'll double check and get back to you.

[mrgleba]

I'ts definitely not in 17.1 :(
The error persists.

[chsienki]

@KieranDevvs @mrgleba Unfortunately it looks like the Roslyn SDK didn't get updated as part of 17.1, so although we checked in the fix, it didn't make it into the product.

It's now been merged in so will be available in the next preview. If you're blocked, its possible to build the SDK from source here https://github.com/dotnet/roslyn-sdk and patch the Roslyn.ComponentDebugger.dll in visual studio. I can provide detailed instructions if any one is interested in doing it.

[KieranDevvs]

@KieranDevvs @mrgleba Unfortunately it looks like the Roslyn SDK didn't get updated as part of 17.1, so although we checked in the fix, it didn't make it into the product.

It's now been merged in so will be available in the next preview. If you're blocked, its possible to build the SDK from source here https://github.com/dotnet/roslyn-sdk and patch the Roslyn.ComponentDebugger.dll in visual studio. I can provide detailed instructions if any one is interested in doing it.

Thanks for the update, I'm currently "debugging" by writing values from the source gen to disk as a work around which should keep me going until the next preview.

[jonmiller1]

Its not in 17.2 Preview 1 either :(

[KieranDevvs]

For all that are still waiting on this, it looks to be fixed in the latest 17.2 update released a few hours ago.

[bkoelman]

I can confirm this is fixed in v17.2, so I believe this issue and https://developercommunity.visualstudio.com/t/unable-to-debug-source-generator-with-the-new-rosl/1398618 can be closed.