Question

我正在编写一个具有基于WPF的界面的小实用程序。我还希望能够通过使用命令行参数执行程序来自动执行该实用程序执行的相同任务。将这两个任务合并到一个程序中是一个坏主意吗？我具有我的工具在单独的共享库中执行的实际逻辑和功能。所以，如果它们是分开的，我就不会复制很多代码。

我想在我的App.cs文件中做这样的事情

private void Application_Startup(object sender, StartupEventArgs e)
    {
        if (e.Args.Length > 1)
        {
            //Go do automated tasks
        }
        else
        {
            //open GUI

            Window window = new Window();

            this.MainWindow = window;

            window.Show();
        }
    }

Answer 1

您实际上并未创建控制台，因此这不是控制台模式应用程序。

接受参数的GUI程序完全正常。样板示例是file association。就像在Windows资源管理器中双击.sln文件一样，启动Visual Studio然后加载解决方案。双击位图启动MS-Paint。等等。单击文件的路径通过命令行参数传递给程序，就像在命令解释器中键入它一样。

您是否创建窗口完全取决于您。不要忘记报告问题的必要性。

Answer 2

在这种情况下，我将创建一个从不同的Host项目调用的函数类库。 MyApp.WPF将MyLib引用为dll ... MyApp.Console将MyLib引用为dll。

编辑我看到您已经拥有了隔离功能的类库。那么将它保存在同一个应用程序中的真正好处是什么？

Answer 3

您绝对可以执行此操作来运行自动化任务或从命令行设置选项，但请记住，WPF应用程序没有控制台窗口，因此您将无法使用Console.WriteLine()或类似的任何内容那。如果你不需要控制台输出，也许这不是什么大问题。

可能有一些糟糕的win32黑客将控制台窗口附加到WPF应用程序，但我不建议这样做。如果您需要一个真正的控制台，可以为您的库构建WPF和控制台前端。

我还建议Options.cs在C＃中进行命令行参数处理。

编辑：我可能错了这一切，请参阅评论。

另请注意：有关Windows应用程序与控制台应用程序的相关信息：Difference between Windows and Console application

将GUI程序和控制台应用程序组合到一个EXE中是一个坏主意吗？

3 个答案: