将GUI程序和控制台程序合并成单个EXE文件是一个不好的想法吗？

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

- Eric Anastas

---

有些应用程序已经做了这个一段时间了...为什么这会是一个坏主意呢？如果你需要锤子，就用锤子。 - Tim

一个问题是，如果GUI支持在启动时绑定（而不是完全基于动态反射），那么您会限制控制台应用程序的运行位置。这也可能会减慢它的速度。在.NET/WPF中可能不是一个大问题，但在其他情况下可能是一个问题。 - DrC

你可以跟随 Visual Studio 使用的技巧：拥有两个可执行文件，一个用于图形界面，另一个用于控制台。控制台可执行文件使用 .com 扩展名（尽管它是PE格式），因为在默认的PATHEXT中，.com 优先于 .exe。因此，如果你在cmd.exe中运行它，你会得到控制台版本，如果你运行 .exe 文件，则会得到GUI版本。 - Peter Huene

Answer 1

您并没有创建控制台，因此这不是一个控制台模式应用程序。

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

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

- Hans Passant

Answer 2

在这种情况下，我会创建一个功能类库，它被不同的主机项目调用。MyApp.WPF引用MyLib作为dll...MyApp.Console引用MyLib作为dll。

编辑：我看到你已经将具有功能的类库分离出来了。那么将其保留在同一应用程序中的真正好处是什么？

- mckeejm

Answer 3

你可以通过命令行运行自动化任务或设置选项，但要注意WPF应用程序没有控制台窗口，因此您将无法使用Console.WriteLine()等类似的内容。如果您不需要控制台输出，则可能并不重要。

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

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

编辑：关于这一切我可能是错误的，请参见评论。

另外：关于Windows应用程序与控制台应用程序之间的差异的相关信息：Windows和控制台应用程序之间的区别。

- WildCrustacean

---

在WPF应用程序中添加控制台窗口非常容易。创建项目后，只需转到项目属性并将“启动方式”更改为“控制台应用程序”。然后，您将获得一个控制台，以及您的主窗口或其他内容。 - Steve

@Steve - 很有趣，我以为你不能这样做，但对我来说似乎很好用。 - WildCrustacean

我从未深入研究过它，但是当我在某台电脑上运行应用程序失败时，我使用控制台窗口来帮助进行故障排除。只需将选项改回即可再次关闭它。 :) - Steve

这种双GUI/控制台模式的缺点是，当您在GUI模式下运行时，它仍会生成控制台，除非您添加代码以在启动时抑制它。 - WildCrustacean