TextColorToGenerator - Is there a way to prevent the package to generate code?

[loop8ack]

I refer to the CodeGenerator TextColorToGenerator and the ColorAnimationExtensions_ classes generated by it.

If I have two projects, one project references the other and both have "CommunityToolkit.Maui" installed, then in both projects these classes are generated, but since they are always public, this causes conflicts.

Why are these classes always public?
Wouldn't it be better if these classes were internal?

As far as I can see, the issue is this line:
https://github.com/CommunityToolkit/Maui/blob/main/src/CommunityToolkit.Maui.SourceGenerators/Generators/TextColorToGenerator.cs#L60
Here it would be enough to change the public to internal.

Can someone explain this to me?
Or maybe there is a workaround so I don't have to wait for an update?

[pictos]

I don't know why it's public, maybe this can help for now
https://stackoverflow.com/a/66130446

[loop8ack]

Yes, that helps, the idea is great.
My solution in the Directory.Build.props:

<PropertyGroup>
  <Disable_CommunityToolkit_Maui_SourceGenerators Condition="'$(Disable_CommunityToolkit_Maui_SourceGenerators)' == ''">false</Disable_CommunityToolkit_Maui_SourceGenerators>
</PropertyGroup>

<Target Name="Disable_CommunityToolkit_Maui_SourceGenerators"
        Condition="$(Disable_CommunityToolkit_Maui_SourceGenerators)"
        BeforeTargets="CoreCompile">

  <ItemGroup>
    <Analyzer Remove="@(Analyzer)" Condition="'%(Filename)' == 'CommunityToolkit.Maui.SourceGenerators'"/>
  </ItemGroup>
    
</Target>

And in the project that references the package:

<PropertyGroup>
  <Disable_CommunityToolkit_Maui_SourceGenerators>false</Disable_CommunityToolkit_Maui_SourceGenerators>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="CommunityToolkit.Maui" Version="3.0.0" />
</ItemGroup>

Works great, thanks :)

However, it would of course be better if this is changed to internal or there is a setting for it.

[pictos]

@loop8ack I just remember that we create internal methods, but for that your control should be internal as well, since the Maui controls are public, the generated helpers will be public as well.

[loop8ack]

I thought the same at first and wanted to change that a hardcoded access modifier is always used for Maui controls.

However, this is already the case,
Maui controls are handled independently and the logic you mention only affects the controls that are also defined in the project.

Maybe that was the original thought behind public, because the controls are always public?
Or is that exactly what you meant?

[pictos]

@brminnick what do you think about changing it to be always internal?

[TheCodeTraveler]

I think this is a god idea! And despite feeling like a breaking change, it shouldn't be a breaking change.

Let's try it out and write some more unit tests to ensure it doesn't break edge cases where a type is in a different namespace and in a different assembly.

[loop8ack]

And despite feeling like a breaking change, it shouldn't be a breaking change.

We could also make it adjustable?
A MSBuild property that defines the access modifier for Maui Controls.
The default setting could be internal and anyone can change it back to public.

Give me a few days (my week is completely blocked) and I'll get on it.

to ensure it doesn't break edge cases where a type is in a different namespace and in a different assembly.

Hm - what do you mean?
I can't think of a situation where that would be a problem.
Maybe if someone uses the workaround from above.

[CliffAgius]

Closed as answered