Duplicate Type Names Cause Compilation Issues

[JasonBock]

Describe the bug
The DnsClient and Aspose.Email packages define DnsClient.DnsQueryOptions. Even with global::DnsClient.DnsQueryOptions, that's not enough. If there's no way to add in the assembly name with global::, I'll have to remove one of the assemblies in the code gen app (probably Aspose.Email), or find a way to isolate the generation with one assembly reference at a time, and that would not be fun.

I realize this is an extremely rare case, but....it is a valid one. If someone was referencing these two packages and wanted to use IDnsQuery, they'd be at a loss.

[JasonBock]

This can be handled with an alias. However, I'm not sure this will help in Rocks. I'd need to know that the package reference has an alias, add the extern alias at the top of the file, and then include that with the FQN whenever that type comes from an assembly in that package.

This may be way too much effort for a very, very small edge case.

[JasonBock]

This may work, need to test this:

ITypeSymbol typeSymbol;
var metadata = compilation.GetMetadataReference(typeSymbol.ContainingAssembly);
_ = metadata.Properties.Aliases;

Thanks to Gérald Barré for pointing all of this out to me.

If there are any aliases, then I can include them in the type name, and then keep track of any aliases in play, and put them at the top of the gen-d file with extern alias.

This just may be doable :). Making a test for it will be "fun", but I have tests for InternalsVisibleTo where I create assemblies on the fly. Not sure how I can include the alias in that case, but, again, something to investigate.

[JasonBock]

If I can get this to work, as a reminder to myself, add Aspose.Email back into the code gen app.