I think a plugin architecture would be a little overkill unless you're interested in versioning or deploying the sub-modules separately. You haven't shown the sub-modules (the actual solvers) but I'd probably define an interface for them and then use a `Dictionary` instead of the `switch` statement. Really, it's pretty minor, but I see a couple of advantages of the `Dictionary`:

- You go from three lines for a new definition to a single line; this will start to make a difference after 10 or so sub-modules since you'll fit on the same screen
- It makes explicit that this main method is solely for determining the sub-module; the switch statement leaves room for other code, so it needs to be scanned when reading the code
- Since the dictionary is explicitly data, it'd be easier to abstract out later if you wanted
- You may want to inject other components into your sub-modules (such as a logger, or an abstracted input/output routine) and having a single init routine will make that easier.

So, a quick implementation would be something like:

    interface ISolver {
        void Solve();
    }
  
    class EulerOne : ISolver {
    }


    static void Main(string[] args)
    {
        // Using a Func to allow a new copy and/or some custom init if needed
        Dictionary<int, Func<ISolver>> solvers = new Dictionary<int, Func<ISolver>>() {
           { 1, () => new EulerOne() },
           { 2, () => new EulerTwo() },
           { 3, () => new EulerThree() }
        };

        int eulerNumber;

        Console.WriteLine("Please enter the number of the Problem you want to solve.");

        while (!int.TryParse(Console.ReadLine(), out eulerNumber))
        {
           Console.WriteLine("Please enter a valid number.");
           Console.WriteLine();
           Console.WriteLine("Please enter the number of the Problem you want to solve.");
        }
    
        var solverBuilder = solvers[eulerNumber];
        var solver = solverBuilder();
        solver.Solve();

        return 0;
    }