Having multiple Program classes in the global namespace.

[DavidVollmers]

Hi there. I am confused...

I have two projects; one ASP.NET Web API and one CLI console app which consumes the API.

Both, of course, have a Program.cs which is written in the new style (without Main method and Program class), which produces a Program class in the global namespace.

So far so good, but now I want to build a test project which uses the TestServer implementation to host the API and triggers the CLI against it. So I can have "e2e" integration tests for my CLI -> API.

Unfortunately I cannot get this to work successfully since now I have two Program classes defined in the global namespace where the compiler cannot resolve neither of them since it always produces an "ambigious reference" error.

The only way to solve this is by putting one of the Program.cs contents into a "real" Program class with the namespace of the project on top.

This feels like a loop hole in the C# spec when it comes to top-level statements...

[HaloFour]

You can alias each of the references so that instead of appearing in the global namespace that they appear in separate namespaces. This is how you can disambiguate classes that have the same fully qualified name in separate assemblies in general:

using CliProgram = cli::Program;
using AppProgram = app::Program;

[DavidVollmers]

I created this example repository to further show my problem:

https://github.com/DavidVollmers/two-programs-ambigious-reference/blob/main/Two.Programs/Try.To.Access.Both/Class1.cs

[333fred]

They're extern aliases, not namespaces. See https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extern-alias.

[bernd5]

They are called "extern alias" - you need to configure them:
see https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extern-alias

[DavidVollmers]

Perfect this solves my problem. Thank you guys :)

[333fred]

@bernd5 jinx!

[DavidArno]

The only way to solve this is ...

This isn't true. There are various ways to solve this.

Firstly though, I'd question why you think this a problem in the first place. That Program class in the global namespace is - by default - internal and it has just one method: private static <Main>$(.... That class and method are not intended to be accessed other than via the CLR at start up. So the moment you want to access them elsewhere, you are "hacking", whether that's through creating a partial class or using reflection. It seems quite unreasonable to describe not being able to hack more easily as a loophole in the language.

A consequence of this is that you really should see that top level code in Program as just a hook into the start-up code. So one one to solve your problem is to call out to your start-up code, which lives in a public static method in a public class to allow easy testing:

// Top level code for your ASP.NET Web API
using StartupCodeNamespace;
WebApiStartUp.Program(args);

// Top level code for your console app
using StartupCodeNamespace;
ConsoleAppStartUp.Program(args);

And for testing purposes, you then access WebApiStartUp.Program and ConsoleAppStartUp.Program directly.

If for some reason, you are determined to put lots of functionality into those top-level statements, then reflection is another way of solving this:

using System.Reflection;

var webApiAassembly = Assembly.LoadFrom("WebApi.dll");
var webApiProgram = webApiAassembly.GetType("Program");
var webApiMain = webApiProgram.GetMethod("<Main>$", BindingFlags.NonPublic|BindingFlags.Static);

var consoleAassembly = Assembly.LoadFrom("Console.dll");
var consoleProgram = consoleAassembly.GetType("Program");
var consoleMain = consoleProgram.GetMethod("<Main>$", BindingFlags.NonPublic|BindingFlags.Static);

And then you can call your two Program top level statements via webApiMain.Invoke(... and consoleMain.Invoke(...

[DavidArno]

@FaustVX, that still falls under my comments about "hacking". I've updated my answer to address that.

[bernd5]

The name of the entry point is compiler dependent / implementation dependent. It could be for example simply Main or $Main...

[DavidVollmers]

Thank you for your elaborate answer. I don't believe you can "hack" a language just by using it though. If there can be two classes of the name in the same namespace it should also be possible to access them separately...

The solution using reflection seems to be the real "hack" here. Also I specificly see this only as a loophole when using top-level statements.

Example repository:
https://github.com/DavidVollmers/two-programs-ambigious-reference/blob/main/Two.Programs/Try.To.Access.Both/Class1.cs

[DavidArno]

Thank you for your elaborate answer. I don't believe you can "hack" a language just by using it though. If there can be two classes of the name in the same namespace it should also be possible to access them separately...

It's this bit:

public partial class Program
{
}

that I'm referring to as a hack. You may not see it as such and you may be happy to use such constructs in your code and that is your choice. To my mind though, it falls foul of the principle of least astonishment (POLA). If you are going to go to the trouble of declaring the program class anyway in order to force it to be public, then it makes sense to just put the code into a Main as used to be the case. Doing a mix of old and new styles will just confuse people, which is not a good thing to do.

[DavidVollmers]

I agree to that. This is why I normally add a comment:

// Required for integration tests
// https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-8.0#basic-tests-with-the-default-webapplicationfactory
public partial class Program
{
}

I don't like it but it is advised by Microsoft to do it and with that I would argue it is intended.

[ehonda]

This should also work (at least with regards to usage via WebApplicationFactory<T>, and is easy to implement, right?

// In Project A Program.cs
public partial class Program;
public class ProgramA : Program;

// In Project B Program.cs
public partial class Program;
public class ProgramB : Program;

// In tests
var programFactoryA = new WebApplicationFactory<ProgramA>();
var programFactoryB = new WebApplicationFactory<ProgramB>();

[DavidVollmers]

Yes but much cleaner what I like to use now is project aliases:

In your test csproj:

<ProjectReference Include="..\ProjectA\ProjectA.csproj" Aliases="global,ProjectA"/>
<ProjectReference Include="..\ProjectB\ProjectB.csproj" Aliases="global,ProjectB"/>

And then in your code:

extern alias ProjectA;
extern alias ProjectB;

var programFactoryA = new WebApplicationFactory<ProjectA::Program>();
var programFactoryB = new WebApplicationFactory<ProjectB::Program>();

[ehonda]

That looks nice, thanks for sharing! 👍