Invoking an EXE in same Solution. Can it be a DLL instead?

Question

This is completely outside my experience so excuse me if this is dumb question. I've spent a couple of hours on Google looking for an answer to this and I can't find one that seems to apply directly to my situation.

I'm working with a group that has a Solution XYZ. The Solution has two Projects: XYZ and XYZOrchestrator. They bundle up the BIN folders from both Projects and deploy it to one folder on the server. XYZOrchestrator does nothing but figure out how many copies of XYZ.exe it needs and spins off that many threads each invoking XYZ.exe:

private Process m_pProcess = new Process();
this.m_pNotify = pNotify;
ProcessStartInfo pInfo = new ProcessStartInfo("XYZ.exe");
pInfo.Arguments = m_pProcessId.ToString() + " " + m_pDataFile + " " +  m_pLogFile + " " + m_pReportFile + " " + m_pErrorFile;
pInfo.WindowStyle = ProcessWindowStyle.Hidden;

m_pProcess.StartInfo = pInfo;
m_pProcess.Start();

They also have a references to XYZ.exe in XYZOrchestrator and call methods within XYZ.exe like it was a DLL. So my question is: Could XYZ.exe be built instead as a DLL? Can you execute a thread as above using a DLL instead of an EXE? If I could change this to a DLL it would fit nicely into our build/deployment automation model.

What about leaving XYZ as an exe and including the exe as a reference in the XYZOrchestrator Solution? — sgmoore, Feb 26 '14 at 15:42
That's the approach I've been looking at but it creates problems with our build system... — Richard Schaefer, Feb 26 '14 at 18:58

score 1 · Answer 1 · answered Feb 26 '14 at 15:33

1

No, it is impossible to run a dll. To clean the structure, I would create a new Assembly (dll) called something like "XYZLib", and put all the code that is shared by XYZ and XYZOrchestrator in there. Then the dependency structure would be more clear.

answered Feb 26 '14 at 15:33

Grzenio

35,875
47
158
240

@Rotem, of course you can do it using reflection as well, but I guess these kind of techniques don't make it more transparent and maintainable (if you have control over the source of course). – Grzenio Feb 26 '14 at 15:51
@Grzenio - There's no shared code. The function of XYZOrchestrator is to read data from a DB and based on that figure out how many copies of XYZ to spawn to process each unique case in the data. Pretty slick actually but the way they structured the Solution in VS is creating build automation problems for me... – Richard Schaefer Feb 26 '14 at 19:01

score 0 · Answer 2 · answered Feb 26 '14 at 15:35

0

Yes. Basically if you think that starting a process is calling Main with command line arguments, you could do it yourself, each time spawning a new thread. But be aware that you don't have the same level of isolation (exception handling, garbage collection etc). You may want to create a new appdomain for each instance.

answered Feb 26 '14 at 15:35

Lev

434
2
9

OK. So I have a No (@Grzenio) and a Yes (@Lev). – Richard Schaefer Feb 26 '14 at 19:00
I just did that last month - took a service which was in self-hosted exe and changed it so it was started from another application. A primitive form of that is really that easy: 1. Compiling the service as DLL. 2. just calling the Main() function of the service from another program in a newly spawned thread. – Lev Feb 26 '14 at 19:51
@Lev, its a new thread and not a new process though. I am sure they need separate processes, otherwise they wouldn't introduce all these orchestrations. – Grzenio Feb 27 '14 at 09:49
As I said, I recommend creating a new appdomain for each instance. That is quite close to process level isolation. – Lev Feb 27 '14 at 09:52

Invoking an EXE in same Solution. Can it be a DLL instead?

2 Answers2