So I want to have two applications: The first one will be a WinForms GUI (probably .NET Framework) and the second one is a .NET Core console application that does all the processing.
My goal is to have the WinForms applications start the console application when needed and provide the task, which the console application should complete, as a startup parameter. The console application should then work on the task and report the current status/progress back to the GUI every second or so including errors and warnings. When everything is done the console application should report that it has finished and close.
I thought I could start the console application using a ProcessStartInfo that would redirect the output of the console application. The console application would just output all important data each second and the WinForms application would then filter and process this output to get the data.
This looks like a not very optimal way to me and I hope I can get some feedback on what I could try/should use instead of this solution. I am very new to communication between two applications.
I've never done what you are attempting to do but i would look in to C# Socket programing this way you can establish communication between two apps that can send data fluently in between but it will require a Server / Client setup, the good news is that you should be able to start the server by starting the process and then establishing a connection.
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/socket-code-examples
Create a service that runs in the background utilizing either SOAP or Socket
https://www.guru99.com/soap-simple-object-access-protocol.html
ASP.NET MVC API (Least Preferable) but it will support many other project and can run on HTTP
I'm not sure if this solves your problem immediately but I hope it can help you to find the answer that you seek. Something i would recommend is that you
I have two separate programs. One is a winform that hosts a running process with output/input being redirected through the form. The process is a canned product with little chance of being able to modify it myself.
The second program is a service that can pole data from the running process but it doesn't interact with the winform directly.
My goal is to send a string from the service to the winform to then interact with the running process. OR, I wouldn't mind being able to send commands directly to the process but I'm betting that can't happen without modifying the running process source.
I've look at Named Pipes but I'm not sure that that is the best means. Both programs are hosted on the same machine. I'm just not sure what my options are. Any ideas? =)
The full range if IPC (Inter-Process Communication) options available in Windows is outlined on MSDN.
Clipboard
COM
Data Copy
DDE
File Mapping
Mailslots
Pipes
RPC
Windows Sockets
Then there are mechanisms outside of Windows
MSMQ or similar queue systems
Record commands/state in a database or file
Of all these, Named Pipes is probably the best fit for your particular application. I have used them for similar things in the past. They are easy to setup and use.
There are multiple options to achieve this communication. Mainly you can use Named pipes (WCF), MSMQ
I'm wondering what the preferred architecture would be for the following situation:
I'm required to have a .NET application that will perform batch upload of multiple data files concurrently to a SQL Server. This will be invoked from a WPF application which will allow the user to select the files and the destination tables, as well as reporting on the individual progress for each upload (including error messages). I have absolutely no problem writing the code for any of this. However, there is a requirement that the user is able to close the WPF application altogether and for the upload process to continue. Further, if the user restarts the WPF application from the same machine, it should be able to get a handle on the existing uploads and report on the status as if the program were never closed.
My question is what are the ways of achieving this and which would seem the most standard/suitable?
I've considered simply not actually closing the WPF application but hiding all the windows, but this seems a cheat. Would it be best to create a WCF service on the server where the upload is taking place and simply upload the file? I don't think I can do that and report progress % etc though. What about a locally-running Windows Service, can I achieve a similar effect? Should I be thinking of MemoryMappedFiles?
Appreciate all your thoughts.
Because you are talking about long-running task, I would use local Windows Service communicating with your WPF application through MSMQ. For example, each file to upload can be represented by one MSMQ message. Your WPF application will be putting messages into queue and Windows Service, periodically and without any impact if WPF is running or not, should take it from queue and process. This will provide simple and reliable channel of providing tasks (uploads).
To provide internal status of the Windows Service to its clients (your WPF application), I would host inside it a WCF endpoint with simple service that is telling, for example, about progress.
I currently have a WCF Service Library which will be started through a Console Application acting as ServiceHost. The ServiceHost starts the service and then waits with Console.ReadLine() for the "quit" command. If i do "Console.WriteLine();" in the service this will be printed to the ServiceHosts Console of course. The Service prints some information when the clients connect for example.
Is it possible to have the ServiceHost converted to a real Windows Service (to start up when the machine boots without console window) and attach or detach a command prompt (cmd.exe) or another Console Application to it when needed? For example if I want so see which clients connect from now on?
Thanks in advance!
EDIT: I really woudln't like to write and read a LogFile.
Only if you run on an old operating system, XP is the last one that allows a service to interact with the desktop. You'll need to write a separate app that can run on the user's desktop. Talk to the service through, well, WCF. Or a named pipe or socket.
You would be far better off exposing the properties and methods you wish to access on the WCF Service and then creating a console or desktop application that allowed you to access the properties via the WCF service. As you are not limited to a single End Point or interface you could easily implement some form of authentication and use netTcp binding between applications.
I want to turn a program I have into a service so I can use it without logging it. Basically what it does is it backs up specified folders to a specified location using SSH. However the problem I'm running into is I don't know how to tell it these items. I only know how to start, stop, and run a custom command with only an integer with a parameter.
How can I do this?
Windows Service, not a Web Service
edit: The folders it backs up will not remain consistent and will be updated at every runtime
You can instantiate your service and pass command line arguments using the ServiceController class.
using (ServiceController serviceController = new ServiceController(serviceName))
{
string[] args = new string[1];
args[0] = "arg1";
serviceController.Start(args);
}
"arg1" will then be available as regular command line arguments in main() when Windows starts up the service.
I see that you (or someone) voted Sebastian Sedlak's answer down, because he mentioned hosting a WCF Service in the Windows Service. Your reply was
It's in nice bold lettering in the question. Not a Web Service, therefor WCF is out of the question
I think you misunderstood what he meant. He wasn't talking about a Web Service. He was talking about hosting a WCF Service within your Windows Service.
It's far from the same thing. You can host a WCF Service within any Windows (Forms/Console/Service) application. The point of doing so, is that the application is then reachable for communciation via its internal WCF Service, in the same fashion as you can communicate with a Web Service (you can also host WCF Services in IIS, btw, which would then make them "Web Services", in the sense you seem to be referring to).
In a Windows Service, this means you can send any command to it and also get any information you want from it - while it's running.
In fact, I am working on a project right now, which is a Windows Service that I need to be able to contact and pass commands to - and get information from - at runtime. For example, I want to be able to tell it where to store certain things, what to log, to have it reset/restart - and poll it for status messages. I do this by hosting a WCF Service inside the Windows Service. That WCF Service exposes a set of methods, that in my case includes receiving commands and returning status information. So when the Windows Service is running, I can contact it (even remotely), via its built-in WCF Service and tell it what to do.
This an extremely easy thing to implement, and in the case of Windows Services, can provide you with a much richer interface to the Service than through the basic standard commands.
However, you specified that you wanted your Windows Service to receive its folder settoings each time it starts up, which makes such a passive setup less than ideal (as it would be unable to do anything until you passed it the right folders).
One way to deal with this (using a hosted WCF Service), would be to have the Windows Service running all the time (i.e. automatic startup). Its default state would be idle. Then you could issue it a "start processing"-command, feeding it the correct folders to work on (through a call to the corresponding WCF Service method). Similarly, the WCF Service would expose methods giving you the status of the application (current folder, progress, busy/idle etc). Once the processing is done, it would go back into the idle state, waiting for the next set of folders to be supplied to it.
Doing it this way would make it very easy to control remotely - you could even make an online administration panel for it, accessible from anywhere.
The issue, is that, while passing in parameters is not difficult, when the machine restarts and windows tries to restart the service, those parameters are not there. they only exist when someone starts the service from the command line.
for example. I have a windows service which hosts a WCF service. I want the users to be able to specify a non-default port number for the WCF service to listen on. They do this by starting the windows service like so... MyService -port:xxxxx
Which works fine, until the server is rebooted, then windows restarts MyService (but without parameters) and the wcf service defaults to original port #
Any service is capable of receiving command line arguments at start-up.
Would it be possible to use a configuration file to specify these items?
Store the service's startup parameters in the registry: and then, when the registry starts, it should read its startup parameters from the registry.
Windows services have executables like any other. I believe you can write it to accept command-line parameters and specify those parameters in the Windows Service configuration. You can also have it read a config file. If you're using .NET, there are config file classes in the framework.
Why not just Host a WCF Service in the Windows Service to obatain such "admin" functions?
(Remoting is also possible)
RE: config file.
Of course a config file can be used.
And the file can be changed while the service is running.
This would be a nice solution if the config file changes in fact.
All my services use an XML config file, wrapped in a class for easy reuse.
The wrapper has an option to monitor the XML file using fileMonitor for changes, optionally refreshing the content of the config file automatically, and finally raises an event to the service class.
The service then has the option of "resetting" itself as needed to incorporate the new values in the XML configuration file.
Placing configuration into the registry has a few issues:
Security (ie: installer being granted access), depending on what tree is used
The service will not be aware of changes
Portability - although minor as the install should setup registry settings
Where an XML file is easy to copy, edit, share, view and understand.
Throw in some good COMMENT blocks and a detailed XSD file, and it becomes a source of good documentation too.
Look into XPath for easy navigation and extraction of values within the XML file.
$0.02
... david ...
Concerning the app.config file - I'm rather sure that your service will read and use those files as I write all my windows-services this way ;)
So just put everything you need in the app.config under "application" (not user) and put allway edit the "yourname.exe.config" in the folder where you "InstallUtil" the service from.