5

我正在编写一个小实用程序，它具有基于 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();
        }
    }
4

3 回答 3

2

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

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

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

于 2013-07-02T21:46:43.280 回答
1

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

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

于 2013-07-02T19:57:20.580 回答
1

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

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

我还推荐Options.cs在 C# 中进行命令行参数处理。

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

ALSO：有关 Windows 应用程序与控制台应用程序的相关信息：Windows 和控制台应用程序之间的区别

于 2013-07-02T19:57:51.897 回答