This question already has answers here:
Show Console in Windows Application?
(12 answers)
Closed 6 years ago.
I have a C# console application that I am running with its output type set to "Windows Application" to prevent the console from being seen during normal use. However, I would like the option to alternatively run the program as a console application at will, in case the user wanted to troubleshoot and view the console's output.
Is it possible to pass a command-line argument to the executable to either run the application in "Console" mode or "Windows Application" mode depending on the user's desire? If not, is there any other way to change on the fly if an application will show the console or not?
I think you have an X-Y Problem. The root problem is that you want the user to be able to run either a console or WinForms program that both do the same thing. One solution would be to have a single program that can run as both, but as #roryap pointed out, this is impossible.
A second solution would be to put the business logic of your program into a separate library. You can then write a console program that accesses this library and a WinForms GUI that also accesses this library. The user then decides which program to run. This is a tried-and-true method of separating an application into multiple layers. I recommend you go this route. You'll find that your user-facing layers (console, WinForms) are small. In the future, if you want to make a Web front-end, or a WPF front-end, you only need to write the front-end part, the business logic layer won't change.
No, you can't. There's a fundamental difference between a console application and a winforms application that goes very deep. Once the application is compiled, it cannot be changed at run time.
Related
I'm new in programming with .Net and C# and, as said in the title, I have a WPF app which is accessible in a system tray icon and I want to run it a windows service.
Typically, I want an output like it was described in an answer provided in a discussion here.
If you want it in the system tray I think what you'll have to do is make it a Windows service. I've only written 1 Windows Service and that was years ago, but I believe that's what you'll have to do. If I'm correct about writing a Windows service, then what I would suggest you do is create a new Visual Studio solution and add two projects to it. One would be a DLL which would run as a Windows service. The second project would be a WPF project that will be your UI the user interacts with. Then you'll have to use some messaging system to communicate between the two. For the action messages that would mimic what Outlook does, I've used some WPF toast messages to accomplish that. If you Bing/Google "WPF toast popup" you'll get lots of results.
I have many searched in Internet and find some helpful answers like:
URL1
You can't, not directly, because the windows service will necessarily start when the machine does, not when a user logs in. The service will also be running in a different context, likely as a different user. What you can do is to write a separate system tray based "controller" that interacts with the service.
URL2
It needs some effort to achieve. Well, just two hints: 1) use static property System.Environment.UserInteractive to detect in which mode your application is running, see http://msdn.microsoft.com/en-us/library/system.environment.userinteractive.aspx; 2) get rid of app.xaml, because it will force starting WPF Application in all cases; instead, create and run and instance of System.Windows.Application (or better, a specially derived class) explicitly and only for interactive mode, see http://msdn.microsoft.com/en-us/library/system.windows.application.aspx.
And, I could not apply their instructions.
Thanks advance!
Over the years I've written my own Windows .dll in C# which includes many objects and functions that I normally use. Up until now, all my programs have been console applications so my dll functions write their status, errors and output to the console. For example: "Loading polygon file : Fred.txt" or "Imported 268 polygons from file". Now I'm starting to write Windows Forms programs and I want to reuse the dll functions, but obviously I can't write to the console for a Forms app.
Does anyone have any suggestions as to the best way to handle a dll which contains functions to be used for both console and forms programs? Is it best to have two versions of every function? Are there ways to tell if a function is called from a Form and not write to the console?
Thanks,
Mark
Do you want to display the messages in your windows forms application? Typically DLLs don't deal with UI operations, such as displaying messages. They can however deal with logging, if that's what you're actually looking for. I would say you should look into a logging framework like NLog and implement that in your DLL.
If you have a WinForms project that references the DLL, you could pass information up from the DLL and display at the UI level. It's a question of proper application architecture. Ideally, the DLL would know nothing of the way it's being used, i.e. from a console application vs. a WinForms app.
"but obviously I can't write to the console for a Forms app."
That's not at all true. You could allocate a console, and write the information to it. So you'd have your forms, and also a console that's writing your output. That works great for debugging.
Or, you could redirect the console output to a file. Just pass a reference to an open StreamWriter to Console.SetOut, and everything that you were writing to the console goes to that file. It's a great way to do some informal logging.
If you're wanting to display the methods' outputs and error messages in the Windows Forms app, then you have to give them somewhere to send the output. That will probably require a lot of rewriting your library methods. The idea is that, rather than writing to the console, those methods would call an output method that you supply. That method would probably be part of an interface. Still, that's not a particularly good way to do things because it assumes that your library knows how you'll want information reported in every user interface scenario.
In general, you probably don't want worker methods to supply user interface output. Logging, sure, but you probably don't want the function that loads data from the file to output to the user: "Loaded 287 records from file." Instead, you have something like:
// in your console program
List<Thing> things = LoadThingsFromFile("filename.txt");
Console.WriteLine($"Loaded {things.Count} things from file.");
// in your Windows Forms application
List<Thing> things = LoadThingsFromFile("filename.txt");
StatusLine.Text += $"Loaded {things.Count} things from file.";
StatusLine.Text, of course, is just an example. You might have this in a scrolling list or pop up a message box, etc. The point being that you want the UI code rather than your processing code to decide how information should be communicated to the user.
I have a console application 'DbCreate' which create .mdf file. And I have another application which uses that .mdf file.
How can I call pre-buld action of the second application, which will first call DbCreate application?
Thanks for help
While this is theoretically possible (reparse point) it would be very hard. A "prebuilt" application does what it is programmed to do, which also implies that it does not do what it's not programmed to do. If you want to change the behavior of the second program, you'll most likely need to alter that second program.
If the second program offers configuration options for this feature, then it's possible but it wouldn't be a programming question anymore.
I have a quite small (so far) project which consists of
Core
GUI
TUI
The TUI (console application) is communicating with another console application in order to send and retrieve certain information.
The purpose of the GUI is to make it easier.
However, I am stuck on how would I make my TUI communicate with my GUI. So far, I know I can start my TUI from the GUI like this:
System.Diagnostics.Process.Start(#"cmd.exe", #"/k C:\project\TUI\bin\Debug\TUI.exe");
But now, I do not have any reference to the console application and I do not know to send information forth and back. I tried to search for the answer, but my search would only lead to how to start them in a normal way (not both, together, communicating).
So all in all, my question is: How to start a console application from windows forms project so those two to be able to communicate?
You can use the Input and Outut Streams of the Process.
Read this :
https://msdn.microsoft.com/de-de/library/system.diagnostics.process.standardinput(v=vs.110).aspx
This is based on C#. I am having a classlibrary in which I would like to know specifically if its being called from a windows based application
I searched a lot but all I found was code to know if it was called from a Console application.
I only want to know if its called from a windows based application or not
Please Help
If you want to know whether the application is running as a service or system app and thus cannot display a dialogue, test the state of Environment.UserInteractive.
There is no easy way to determine if the application is a windows or cmd-based application. For example, I might build a winforms-based application that doesn't create a window and instead runs as command-line style application by not opening a window.
Two (not necessarily reliable) ways of testing if it's a windows-based app would be to test Application.OpenForms (if it contains forms, then it's a windows app) or Environment.GetCommandLineArgs() (if 0 args, assume it's a windows app).
If you absolutely need to know whether the app is a console or windows one, then you need to step out of the world of managed code and start delving into the exe file using unmanaged C++ code. There is just one byte difference between the two in the PE header of the exe file: Subsystem is set to 2 for a windows app and 3 for a cmd app. See http://msdn.microsoft.com/en-us/library/ms809762.aspx and http://support.microsoft.com/kb/90493/en-us for details if you really want to do this.