Reentrant (?) Console Application....

[carlbono]

I need a way for my console application to stay running and be able to
be called at any time with some parameters, do it's work, then wait to
be called again, repeat.

Here's the details:

I have a C# engine that's used to run a lot of complex financial
calculations and return a report based upon the calculated results. My
program is called by another program... let's just call it "MasterApp"
and i'll call my program "Calc". Calc is the console app exe.

Here's the basic process:
1. User inputs some data into MasterApp.
2. User clicks tells MasterApp to "Go".
3. MasterApp writes out an xml file, then launches "Calc.exe"
4. Calc reads the xml to create the inputs that it understands
(there's some translation there).
5. Calc calls some of it's own dlls (C#), etc. with the translated
inputs.
6. The "guts" of calc.exe (the dlls which are called) take the inputs,
pull the data it needs, calculates and returns a report.
7. The report is written to a directory specified as a paramater to
the calc.exe call.
8. Calc closes.
9. MasterApp waits for Calc.exe to close, then displays the report to
the user.

The real issue here is performance. It's taking way too long to load
everything that's need into memory to run each time (JIT, etc.) and
then close everything back down EVERY time the user runs a report. I'd
like somehow, once the system is run the first time, for it to stay in
memory so that the user does not experience the load time lag every
single time they run a report.

As a note, loading the assemblies into the GAC doesn't appear to help.

I'll go ahead and apologize up front, because I am not certain that i'm
using the correct terminology to describe the issue i'm trying to
resolve.

Thanks in advance for any help/advice you can give.

- Carl

[billr]

I'm not sure I understand the choice of architecture here ...

Is there a NEED for calc.exe to be a command window application?
Can't you package your business logic (i.e.calc.exe) in a dll and call from
a web service, or package as a COM+ application, etc.
--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk
"ca******@gmail .com" wrote:

I need a way for my console application to stay running and be able to
be called at any time with some parameters, do it's work, then wait to
be called again, repeat.

Here's the details:

I have a C# engine that's used to run a lot of complex financial
calculations and return a report based upon the calculated results. My
program is called by another program... let's just call it "MasterApp"
and i'll call my program "Calc". Calc is the console app exe.

Here's the basic process:
1. User inputs some data into MasterApp.
2. User clicks tells MasterApp to "Go".
3. MasterApp writes out an xml file, then launches "Calc.exe"
4. Calc reads the xml to create the inputs that it understands
(there's some translation there).
5. Calc calls some of it's own dlls (C#), etc. with the translated
inputs.
6. The "guts" of calc.exe (the dlls which are called) take the inputs,
pull the data it needs, calculates and returns a report.
7. The report is written to a directory specified as a paramater to
the calc.exe call.
8. Calc closes.
9. MasterApp waits for Calc.exe to close, then displays the report to
the user.

The real issue here is performance. It's taking way too long to load
everything that's need into memory to run each time (JIT, etc.) and
then close everything back down EVERY time the user runs a report. I'd
like somehow, once the system is run the first time, for it to stay in
memory so that the user does not experience the load time lag every
single time they run a report.

As a note, loading the assemblies into the GAC doesn't appear to help.

I'll go ahead and apologize up front, because I am not certain that i'm
using the correct terminology to describe the issue i'm trying to
resolve.

Thanks in advance for any help/advice you can give.

- Carl

[billr]

I'm not sure I understand the choice of architecture here ...

Is there a NEED for calc.exe to be a command window application?
Can't you package your business logic (i.e.calc.exe) in a dll and call from
a web service, or package as a COM+ application, etc.
--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk
"ca******@gmail .com" wrote:

I need a way for my console application to stay running and be able to
be called at any time with some parameters, do it's work, then wait to
be called again, repeat.

Here's the details:

I have a C# engine that's used to run a lot of complex financial
calculations and return a report based upon the calculated results. My
program is called by another program... let's just call it "MasterApp"
and i'll call my program "Calc". Calc is the console app exe.

Here's the basic process:
1. User inputs some data into MasterApp.
2. User clicks tells MasterApp to "Go".
3. MasterApp writes out an xml file, then launches "Calc.exe"
4. Calc reads the xml to create the inputs that it understands
(there's some translation there).
5. Calc calls some of it's own dlls (C#), etc. with the translated
inputs.
6. The "guts" of calc.exe (the dlls which are called) take the inputs,
pull the data it needs, calculates and returns a report.
7. The report is written to a directory specified as a paramater to
the calc.exe call.
8. Calc closes.
9. MasterApp waits for Calc.exe to close, then displays the report to
the user.

The real issue here is performance. It's taking way too long to load
everything that's need into memory to run each time (JIT, etc.) and
then close everything back down EVERY time the user runs a report. I'd
like somehow, once the system is run the first time, for it to stay in
memory so that the user does not experience the load time lag every
single time they run a report.

As a note, loading the assemblies into the GAC doesn't appear to help.

I'll go ahead and apologize up front, because I am not certain that i'm
using the correct terminology to describe the issue i'm trying to
resolve.

Thanks in advance for any help/advice you can give.

- Carl

[C_Bone]

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

[C_Bone]

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail .com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

I would suggest in-proc remoting, that is, let the master application create
a separate Application Domain (AD) that handles the core business (so
you'll have to load the assemblies in that domain). The master application
can pass the XML as an argument in a (asynchronous) remoting call that
starts the business process, let the 'report' be the return 'value' of the
call, or use a call-back when done.

Willy.

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail .com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

I would suggest in-proc remoting, that is, let the master application create
a separate Application Domain (AD) that handles the core business (so
you'll have to load the assemblies in that domain). The master application
can pass the XML as an argument in a (asynchronous) remoting call that
starts the business process, let the 'report' be the return 'value' of the
call, or use a call-back when done.

Willy.

[C_Bone]

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

[C_Bone]

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail .com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

Well, I'm afraid you're stuck, the master application starts a new calc.exe
for each report, so your calc.exe has to start all over again, there is
nothing that can be left in memory once a process has terminated.

Willy.