Support `extern alias` in generated code.

[teo-tsirpanis]

I was benchmarking the old and new version of my library and the benchmark methods were returning objects of a type with the same name from the old or new assembly. I can't vary the NuGet package versions because the new version is not yet released and the API is different.

In my benchmark code I used extern alias to point to the old library but this did not carry over to the code BenchmarkDotNet generated, causing error CS0433: The type 'Grammar' exists in both 'Farkle, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' and 'FarkleNeo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

I found a workaround by returning object so I guess it's a pretty niche scenario.

[timcassell]

For this to be done automatically, this is blocked by #1403 (unless we want to pass /r arguments to the compiler). We also will need to figure out how to determine when to use extern alias (I suspect we'll have to scan all assemblies for the type to check for duplicated Type.FullName, since we don't have the /r compilation information at runtime).

We could possibly expose an API to support this case manually, but I'd prefer not to.

[timcassell]

@teo-tsirpanis How did you get it to work outside of BDN? When I try, I hit this long-standing issue. dotnet/msbuild#4943

I'm not sure if we can support this in BDN if msbuild doesn't even properly support it.

[teo-tsirpanis]

In my case the two assemblies have different names (one is called Farkle and the other is called FarkleNeo). I use extern alias in my benchmark, and because I return object from my methods, the auto-generated files don't require to use extern alias.

[Madajevas]

Any update or workaround for this?

[teo-tsirpanis]

You can avoid exposing the extern aliased type in the signature of your benchmark methods. For my case I changed the methods to return object.