0

Good morning.
This is a weird question, I know, but be patient with me, please! :-)

Scenario
Years ago I made a simple C# console application (call it MyApp, myapp.exe) that does some work for a big COBOL application (call it CblApp).
This app generally read some files, do requested work (like calling web services, etc..) and writes some output files.
Interaction with CblApp works in this manner:

  • CblApp calls myapp.exe, for example myapp.exe -i:readinputfilefile.xml -w:writeresults.xml
  • CblApp blocks itself until myapp.exe is closed (synchronous way)
  • When myapp.exe finished and closes itself, CblApp read result files

MyApp is plugin based, and now it is a monster with 40 plugins, logging, ineternet connection check, etc...; loading it every time from scratch takes a while, so I created a new version that works as a single istance application with tray icon.
Nice, but CblApp can't use it: CblApp can't change his way to interact with myapp.exe.
Question
Now the question: can I simulate to the CblApp that myapp.exe is closed without really doing it?
Now I wrote a fake myapp.exe tha calls the single istance app, waits until work is done, than closes itself, but I don't like this solution.
Hope someone will undestand this tangled question. :-)
Thanks!
Nando

Ferdinando Santacroce
  • 1,047
  • 3
  • 12
  • 31
  • 1
    Make myapp.exe a remoting client. Make some other app the remoting server. – leppie Jun 22 '12 at 10:01
  • As I read my ideas converged on the idea of: write a fake myapp.exe tha calls the single istance app, waits until work is done, than closes itself. But You say you don't like that idea, why? – ctrl-alt-delor Jun 22 '12 at 10:04
  • How does _clbApp_ communicate with _mayapp.exe_? What condition is it looking for to determine whether it finished? – Attila Jun 22 '12 at 10:06
  • It is not just the fake exit. You have a fake start, except first time. So the client server approach in your question sounds good, but in the client a way to launch the server if it does not exist. – ctrl-alt-delor Jun 22 '12 at 10:10
  • @leppie I used remoting (I forgot to mention I can use .NET 2.0 only, need Win2000 compatibility, unfortunately...), using sockets; NamedPipes sounds terrible to debug to me, and this piece of crap I wrote is used from thousands (literally!) computer all across my country, so I need to be able to inspect, debug and find solution as soon as possible, when needed – Ferdinando Santacroce Jun 22 '12 at 14:07
  • @richard 1) it's just what I've done; not the best I can do, I think, due to the possible fragility of communication layer (possible myapp.exe or myappserver.exe hangs, or so) – Ferdinando Santacroce Jun 22 '12 at 14:07
  • @Attila CblApp makes a call to an external app using AcuCobol runtime specification; it's just like we used to do with Process, but not so flexible. – Ferdinando Santacroce Jun 22 '12 at 14:09
  • @richard 2) I implemented a way to start the server, if not running ;-) – Ferdinando Santacroce Jun 22 '12 at 14:10

1 Answers1

2

You could consider a Windows Service instead of a Console app.

The service could be started once and run in the background always, so you won't need to initialize everything on each call. To communicate with the windows service you can use files or sockets or a database, whatever fits your needs.

Stelian Matei
  • 11,553
  • 2
  • 25
  • 29
  • Better recommend WCF to communicate with the win service. I was thinking that he can also keep the console app and have it communicate with the service over WCF. Then the app is lightweight and can be opened and closed as many times as needed. – Marcel N. Jun 22 '12 at 10:04
  • @thecoon: WCF is overkill for IPC. Just use remoting over named pipes. Easy to setup and fast as lightening. – leppie Jun 22 '12 at 10:06
  • @leppie: Remoting is deprecated. Please see http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.100).aspx – Marcel N. Jun 22 '12 at 10:09
  • @thecoon: I dont really care what MS say or think. Remoting is alive and well, and is still used widely in the .NET framework code itself. WCF cannot replace remoting for IPC. The person that spread that FUD should be shot. And if you read the link you provided, it specifically mentions to use WCF for distributed applications and IPC is hardly distributed. – leppie Jun 22 '12 at 10:15
  • @leppie: You're entitled to your opinion, but that doesn't make it correct. Remoting is dead. – Marcel N. Jun 22 '12 at 10:17
  • @thecoon: So why does `AppDomain`s and `MarshallByRefObject` still exist? Why arent those classes marked as `Obsolete`? – leppie Jun 22 '12 at 10:20
  • @mazzucci sorry, I forgot to metion I'm in stuck with .NET 2.0, cannot use newer framewroks due to Win2000 compatibility needs (yes, a 15teen years old s.o.) – Ferdinando Santacroce Jun 22 '12 at 14:12
  • I'm sorry for this flame about remoting; yes, it is deprecated, and I probably will use WCF if possible, but for me it has his niche where to live. – Ferdinando Santacroce Jun 22 '12 at 14:15
  • @mazzucci windows service is a deploy problem for me; CblApp and myapp need to be X-COPY deployable. Yes, I know, I'm in a cage.... :-D – Ferdinando Santacroce Jun 22 '12 at 14:18
  • @FerdinandoSantacroce Sorry to hear that... I don't have other suggestions for now. I can see why you wanted a fake exit on a console app, but I am not sure if and how it can be done. – Stelian Matei Jun 22 '12 at 18:57
  • @mazzucci my need to have a fake console exit behaviour is to cut off this server-client overhead, if possibile; but for now I'm settled for this solution, probably the best compromise I can get for now. Thank you all! :) – Ferdinando Santacroce Jun 25 '12 at 07:21