[Brar]

After the discussion in #194 I had a look into the relevant code and figured, that CommandLineApplication.Execute was complicated to the point where a simple minded person like me isn't able to safely add any aditional level of complexity while still claiming to know what he's doing.
This is why i went ahead and refactored it.
This PR doesn't add any features but really tries to keep everything as it is and simply make the code easier to understand by using named classes and members to express intent.
As always refactoring is subject to taste and local standards an I can't claim that I know yours.
Also I didn't bother about performance, which I wouldn't consider problematic in this context.
So feel free to reject this PR if you don't find it useful or if it doesn't fit into your concept.
Anyways I'd be happy about some feedback if you can find the time.
Regards,
Brar

[dnfclas]

@Brar,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

[natemcmaster]

Thanks for the pull request @Brar. I can't promise we will take this change, but wanted to let you know that we will be meeting next week to triage issues on this repo. We will take a look at this then.

[Brar]

@natemcmaster that's perfectly ok for me.
I just wanted you to know that I did this so that you can possibly save some time or take some ideas once you get to refactor the code.
I don't expect maintainers to accept random unrequested pull requests that don't even add a feature.
Best Regards,
Brar

[Eilon]

@Brar indeed, thanks for this PR. Given that this implementation is designed for just what the ASP.NET/EF Core tools need, we try to minimize the work here. If you could send a PR for just the bugs you found I think that's something we'd be interested in.

As it is, it's a bit hard to see in this PR what part is refactoring and what part is bug fixes (despite having multiple commits), so given that, I'm closing this PR.

[Brar]

@Eilon actually they weren't bugs in your code but rather in mine ;-)
Sorry for not being clear about this in the commit message.
Due to the complexity of CommandLineApplication.Execute I heavily relied on the existing tests when refactoring the code.
After creating the pull request I got a gut feeling that some code path in the method might not be covered by unit tests making me introduce regressions. That's why I looked at every code path and the tests covering it and added some missing tests for code paths that currently aren't covered by tests.

I've created #204 which only adds tests for existing functionality that previously wasn't covered by tests (but was working!) and two (currently skipped) that show some (IMO) counterintuitive behavior.