Allow changing the name or namespace of ThisAssembly class

[IlyaBiryukov]

We encountered the following scenario where `ThisAssembly caused a build break.

1. Project A has ThisAssembly generated and also [InternalsVisibleTo] for project B
2. Project B also has ThisAssembly. When it tries to use it, build fails because of ambiguous ThisAssembly class.

The solution to this issue may be either naming ThisAssembly class differently, or placing it inside a namespace (root namespace of the project, perhaps). For backward compatibility, this should be opt-in.

[IlyaBiryukov]

If projects can change the name or namespace of ThisAssembly class, the next step will be to change the visibility, make it public for example. Sometimes one project need to use assembly version of another project, e.g. in VSSDK binding redirection and codebase attributes. This may be a different issue, or part of this one.

[AArnott]

This does not produce an error. It is a warning:

warning CS0436: The type 'ThisAssembly' in 'd:\temp\ClassLibrary1\ClassLibrary2\obj\Debug\netcoreapp3.1\ClassLibrary2.Version.cs' conflicts with the imported type 'ThisAssembly' in 'ClassLibrary1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'd:\temp\ClassLibrary1\ClassLibrary2\obj\Debug\netcoreapp3.1\ClassLibrary2.Version.cs'.

You might see this as an error if you have TreatWarningsAsErrors set to true, but since it originated as an error, you can also suppress it using #pragma warning disable CS0436 so that makes even the error go away.

This is the recommended mitigation when you're using InternalsVisibleTo, so I'm closing this issue as Won't Fix.

[DavidObando]

Hi @AArnott, sorry to comment on a closed issue but we're also hitting this issue in our CI builds but with error CS0433, which is addressable by doing some extern alias magic. In our case we have not one but several conflicting assemblies due to transitivity in the internalsvisibleto and dependent packages, so we're now facing the task of adding a couple dozen aliases for our references.

Would you consider a contribution to the project that enables a way to change either the name or the namespace for the ThisAssembly class? I'd be happy to work on this a bit instead of dealing with a growing number of aliases for the package references.

[AArnott]

@DavidObando If you're getting CS0433 that suggests the failing project does not generate its own ThisAssembly class. Maybe you don't have NB.GV installed to it. And despite it not having its own class, you evidently are compiling code that tries to access it, which would produce CS0433.

CS0436 would happen if you have your own and access to another project's class. This is suppressible as discussed above.
CS0433 I think happens if you don't have your own, and you try to access it anyway but there are several possible matches. Why would you ever want to access any of several others? Do you really mean to be accessing your own, and in that event maybe the fix here is to install Nerdbank.GitVersioning into that project as well. That would change CS0433 to CS0436 and then you can suppress the warning.

This is all educated guessing. Am I on track though?

[alexrp]

@AArnott Considering the generator already has code to emit the namespace (for F#), would it be reasonable to introduce a property that could indicate to NBGV that the user always wants ThisAssembly to be put in RootNamespace?

[AArnott]

I don't think we'd add a boolean switch to forcibly link the namespace of ThisAssembly to RootNamespace. Rather, if we made the namespace flexible I'd say just take a string switch and let it be anything (including $(RootNamespace)).

[alexrp]

@AArnott Given the above, can we reopen this? (I'll try to find time to do a PR for this eventually, but in the meantime, someone might come across this and feel like contributing the enhancement.)

[AArnott]

Sure. But if no one contributes a fix in a few months, I may re-close it.