Building the Toolkit Sample project requires Long Path Support to be enabled.

Description

One cannot build the Toolkit Sample project without Enabling Long Path support in windows. It appears that the Source generators are using some sort of mixed Project/TypeName scheme to store output files and avoid name collisions.

I’ve looked but not located any Wiki or other build discussion that mentions the Long Path support requirement. TBH, I didn’t look that hard even after the issue, and I didn’t dig farther than the landing page readme.md when I cloned the project.

One example of many that results from the output of building Project: CommunityToolkit.Maui.Sample:

4>CSC : error CS0016: Could not write to output file 'C:\MauiTesting\Maui\samples\CommunityToolkit.Maui.Sample\obj\GeneratedFiles\CommunityToolkit.Mvvm.SourceGenerators\CommunityToolkit.Mvvm.SourceGenerators.ObservablePropertyGenerator\CommunityToolkit.Maui.Sample.ViewModels.Converters.EnumToBoolConverterViewModel.cs' -- 'Could not find a part of the path 'C:\MauiTesting\Maui\samples\CommunityToolkit.Maui.Sample\obj\GeneratedFiles\CommunityToolkit.Mvvm.SourceGenerators\CommunityToolkit.Mvvm.SourceGenerators.ObservablePropertyGenerator\CommunityToolkit.Maui.Sample.ViewModels.Converters.EnumToBoolConverterViewModel.cs'.'

I cloned the project into the default C:\MauiTesting\ folder that VS2022 preview uses as the default project dir. So the root path is just about as small as it gets. Thus C:\MauiTesting\Maui\samples\CommunityToolkit.Maui.Sample\obj is the project contribution to the path and the generator adds:

\GeneratedFiles\CommunityToolkit.Mvvm.SourceGenerators\CommunityToolkit.Mvvm.SourceGenerators.ObservablePropertyGenerator\CommunityToolkit.Maui.Sample.ViewModels.Converters.EnumToBoolConverterViewModel.cs

While I understand the basic premise here is to avoid name collisions I wonder if the same effect might be observed by removing all the path/folder redirection and sticking with namespace prefixed filenames? In my Source Generator code I inject information about the Generator that created the file using attributes such as: (I’m using Scriban templates here and can provide an example if you’d like)

namespace {{ RootNamespace }}
{
    [ GeneratedCode("{{ GeneratorName }}", "{{ Version }}" ) ]
    [ CompilerGenerated ]
    internal class AGeneratedClass : ISomeInterface

While not an issue for me at the moment some organizations lock users out of OS changes as well which might be a bit of a struggle if the IS organizations are like most I’ve encountered over the years.

Link to Reproduction Sample

Toolkit Sample Project

Steps to Reproduce

1. Disable Long Path support in windows if you already have it.
2. Build the sample project.

Expected Behavior

You can build the project without taking extra OS configuration steps.

Actual Behavior

Confusing build errors and Registry edits required to get it to build.

• IDE: VS2022 17.3.0 Preview 1

Workaround

Enabling Long Path support in windows.

[pictos]

@bijington will not affect any functionality around VS and generated code. That configuration is there to workaround some issues, at the time that we implemented the SGs, on VS Windows and Mac.

@bakerhillpins yes, you’re right, but at the time that we did the SG that view was broken and on VSMac you can’t see the generated files inside the IDE. We’ll disable that csproj configuration by default to avoid devs to hit this issue.

[bijington]

@bakerhillpins having read your error message again I can see that the issue is in one of the samples dependencies CommunityToolkit.Mvvm.SourceGenerators and not actually our source generators.

That toolkit is over at: https://github.com/CommunityToolkit/dotnet

This information may be beneficial to them.