Is it a bad idea to combine a GUI program and a console application into a single EXE?

Question

I'm writing a little utility which has a WPF based interface. I also want to be able to automate the same tasks performed by the utility by executing a program with command line parameters. Is it a bad idea to combine both of these tasks into one program? I have the actual logic and functionality that my tool performs in a separate shared library. So I wouldn't be duplicating a whole lot of code if they were separate.

I was thinking of doing something like this in my App.cs file

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

There are applications that have been doing this for a while now...why would it be a bad idea? If you need a hammer, use a hammer. — Tim, Jul 02 '13 at 19:56
One issue is that if the GUI support is bound on startup (as opposed to fully dynamic reflection based), then you are restricting where your console app can run. You may also be slowing it down. Probably not a big issue with .net/wpf but may be an issue in other contexts. — DrC, Jul 02 '13 at 20:00
You could always follow the hack used by Visual Studio :) Have two executables: one for GUI and one for console. The console executable gets a .com extension (despite being a PE) because .com gets priority over .exe (in the default PATHEXT). Thus, if you execute it from cmd.exe, you get the console version and if you run the .exe you get a GUI. — Peter Huene, Jul 02 '13 at 20:29

Hans Passant · Answer 1 · 2013-07-03T10:58:55.500

You are not actually creating a console so this is not a console mode app.

A GUI program accepting arguments is entirely normal. The boilerplate example is a file association. Like double-clicking a .sln file in Windows Explorer starts Visual Studio which then loads the solution. Double-clicking a bitmap starts MS-Paint. Etcetera. The path of the clicked file is passed to the program through a command line argument, just as if you typed it in the command interpreter.

Whether or not you create a window is entirely up to you. Don't forget the need to report problems.

score 1 · Answer 2 · answered Jul 02 '13 at 19:57

In this case I would create a functional class library that is invoked from different Host projects. MyApp.WPF references MyLib as a dll...MyApp.Console references MyLib as a dll.

edit I see that you already have the class library with the functionality segregated. What is the real benefit of keeping it in the same application then?

score 1 · Answer 3 · edited Jun 20 '20 at 09:12

1

You can definitely do this to run automated tasks or set options from the command line, but keep in mind that a WPF application has no console window, so you won't be able to use Console.WriteLine() or anything like that. If you don't need console output, maybe that isn't a big deal.

There may be some awful win32 hack to attach a console window to a WPF application, but I wouldn't recommend that. If you need a real console, building both a WPF and console front end for your library may be the way to go.

I would also recommend Options.cs to do command line argument processing in C#.

EDIT: I may be wrong about all this, see the comments.

ALSO: Related information about windows application vs. console application: Difference between Windows and Console application

edited Jun 20 '20 at 09:12

Community

1
1

answered Jul 02 '13 at 19:57

WildCrustacean

5,896
2
31
42

1

It's easy to add a console window to a WPF application. After you create the project, simply go to the project properties and change "Start As" to "Console Application". Then, you'll get a console, as well as your main window or whatever. – Steve Jul 02 '13 at 20:41
@Steve - interesting, I thought there was some reason you couldn't do that, but it seems to work fine for me. – WildCrustacean Jul 02 '13 at 20:46
I've never looked into it in depth, but I did have an application fail when run on a certain PC, and I used the console window to help troubleshoot it. Turn it off again by simply changing the option back. :) – Steve Jul 02 '13 at 20:50
One downside for a dual GUI/console mode thing like this is that when you run in GUI mode it would still spawn the console, unless you add code to suppress it on startup. – WildCrustacean Jul 02 '13 at 20:54

Is it a bad idea to combine a GUI program and a console application into a single EXE?

3 Answers3