1.8.1 and 1.8.2 versions gives generated file conflict build warning

[MichaelLogutov]

After upgrading to 1.8.1 and 1.8.2 version I've encounter following build warning (as error due to treat warnings as error setting):

1>(CliServiceCollectionExtensions).g.cs(51,40): Error CS0436 : The type 'CliServiceProviderExtensions' in 'DotMake.CommandLine.SourceGeneration\DotMake.CommandLine.SourceGeneration.CliCommandGenerator\(CliServiceProviderExtensions).g.cs' conflicts with the imported type 'CliServiceProviderExtensions' in 'BugReport, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'DotMake.CommandLine.SourceGeneration\DotMake.CommandLine.SourceGeneration.CliCommandGenerator\(CliServiceProviderExtensions).g.cs'.

Here's a repo: BugReport.zip

[calacayir]

Thanks for the bug report. This is now fixed with v1.8.3:

• Fixed "CS0436 : The type 'CliServiceProviderExtensions' in ..." compiler error when project is referenced by another project.
• Generated Builder classes will be put in GeneratedCode sub-namespace of the definition class's namespace to prevent namespace pollution. Global GeneratedCode namespace was already being used by delegate-model, now class-based model will use GeneratedCode sub-namespace.

[MichaelLogutov]

Thanks, but adding InternalsVisibleTo (as we usually do with tests sattelite projects) still gets the same error.

Here's updated repo with DI extension usage (as in real project): BugReport.zip

[calacayir]

Ok v1.8.4 should now fix it completely:

• Updated to latest daily build 2.0.0-beta4.24126.1 of System.CommandLine.

• Fixed compiler error related to CliServiceProviderExtensions and CliServiceCollectionExtensions when project is referenced by another project. Class conflict errors occur due to same namespace in different assemblies.

  This can't be fixed via PrivateAssets in PackageReference because although default value is "contentfiles;analyzers;build", source generator still flows to the parent project via ProjectReference and PrivateAssets="all" prevents flow of source generator but it also prevents flow of "compile" so it becomes useless.

  First attempt to fix (in v1.8.3), was making CliServiceProviderExtensions and CliServiceCollectionExtensions classes internal but the problem resurfaces if user adds InternalsVisibleTo attribute in child project.

  So we finally solve this problem, by detecting if current compilation is a parent project in the solution, if so we do not inject feature extensions as they already come transitively from the child project. This way we can also keep CliServiceProviderExtensions and CliServiceCollectionExtensions classes public.

[MichaelLogutov]

Yes, now everything works fine. Thanks. And thank you for such neatly done project - a pleasure to use.