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 = _solver[eulerNumber];
    var solver = solverBuilder();
    solver.Solve();

    return 0;
}

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;
}