How to: run some logic in a seperate process - not thread?

Hi Fenh,

Another process means another application. After that it depends what sort
of communication you want. How much data, how often, etc. All the facilities
that Windows provides are available - there's Windows messages, shared memory,
pipes, sockets, the file system, etc.

Can I ask why threading isn't a solution?

Regards,
Fergus

Hello,

"feng" <li******@msn.c om> schrieb:

In our VB.Net application, we need to be able to start
another process (thread won't do it) and run some logic in
it, and still be able to communicate with the main
process. Is this possible and how to do it?

Why not using an other thread? You can use Remoting to communicate with the
other instance of the application.

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
http://www.mvps.org/dotnet

Thanks for your reply.
Our VB.Net app is using an 3rd party component to
communicate with other apps on different plateform. When
using this component (a regular dll, not even COM dll), it
is crital that we have different communication pipe lines
(ports) set up on both sides for each individual calls. In
other words, we don't want the calls to share the same
port. Accroding to the 3rd party component's limit,
unfortunitly, we can only do this by starting this
component in a different process. A different thread just
won't do the job. Not even a different AppDomain.

Any thoughts?

Thanks

-----Original Message-----
Hi Fenh,

Another process means another application. After that it depends what sortof communication you want. How much data, how often, etc. All the facilitiesthat Windows provides are available - there's Windows messages, shared memory,pipes, sockets, the file system, etc.

Can I ask why threading isn't a solution?

Regards,
Fergus
.

Hi Feng,

|| Our VB.Net app is using an 3rd party component to
|| communicate with other apps on different plateform.

You've got a App with a 3rd party component. which communicates with
remote applications through ports. That's as far as I understand then I'm
uncertain. So I have to ask more questions.

|| When using this component (a regular dll, not even COM dll),
|| it is crital that we have different communication pipe lines
|| (ports) set up on both sides for each individual call.

That's ok. What protocol are you using, out of interest?

|| In other words, we don't want the calls to share the
|| same port.

Is there a difficulty in selecting ports?

|| Accroding to the 3rd party component's limit,
|| unfortunitly, we can only do this by starting this
|| component in a different process.

I don't understand why, but different processes is ok. That just means
several copies of your program running simultaneously.

|| A different thread just won't do the job.

Any idea why?

|| Not even a different AppDomain.

What do you mean by an AppDomain?
Are you saying that the component can only do one 'pipe line' per
application ? or has some small limit?
How many pipe lines do you need to set up? How many can the component
handle at any one time? Does it need specific ports?

You'll have to have several copies of your program running at the same
time. Have you any idea what they will need to tell each other in order to
work together ?

Hopefully your answers to these questions will lead us towards getting a
solution for you. :-)

Regards,
Fergus

Hi Feng,

|| It's interesting that I got another reply email with those
|| qustions from you in my personal mailbox but I don't see
|| it here.

I'm not sure what that's about, I checked my Sent folder to see if I
posted to you personally by mistake but there's nothing there. Nor have you
been added to my address book. It's mystery time.

Let's see if I now understand the situation. This is more for me, as I
read your mail, than for you so bear with me.

=============== =============== ======
Ok we have a remote COBOL back-end [as remote as possible, please!! ;-)].

To speak to it you have a 3rd-party rpcCobol dll wrapped by a COM
component (rcpWrapper, say).

This can be hosted inside an application and will provide it with a single
TCP/IP port and no more.

You can't have more than one instance because it's a plain old-fashioned
dll. Multiple instances of rcpWrapper will not get discrete instances of
rpcCobol data.

Having two or more instances of your <application> is fine, however. Each
gets its own TCP/IP port because each provides its own address space to
rpcCobol.

Within your application are multiple sub-programs - 'users' of the Cobol
back-end, which require their own connection, ie. their own port.

These 'users' must co-exist within a given appliaction.

rpcCobol's restriction to one port is a stopping point.

Threads are not a solution because they are in the same address space
sharing the same dll.

Processes is the way to go.

Yes. It's all perfectly clear.

[Except for Application Domain which is a term I don't know]
Correction, I've just read it up and it's not a solution for the same
reason as Threads. Application Domains provide a .NET/CLR separation but still
within the same address space. [In fact that latter point is one of the
benefits of Application Domains, as I understand it.]

=============== =============== ======

What if you rewrite your COM wrapper as an application with an Automation
interface rather than as a component? Then each sub-program can create its own
instance of "appRpcWrap per" which can provide the rpcCobol dll with a separate
address space. It would also make communication easy as you'd be able to
define whatever functions and methods you want and let Interop manage the
to-and-fro.

If that's not a solution, then you'd have to write a standard exe which
would simply host an rpcCobol - and devise another method of communication.
The choice then would depend upon what data you'd need to pass between them,
and how much and how often, etc.

I hope this helps.

Regards,
Fergus

feng,
Based on your's & Fergus's discussion I would do as Herfried suggested. Use
..NET remoting.

Each instance of the DLL would need to be started by an individual
executable as you stated.

I would consider having 2 executables. One that hosted the DLL, which would
be a .NET Remoting Server, and a second that 'hosted' the first executable.
It would be a .NET Remoting Client.

One instance of the 2nd executable would start multiple instances of the
first executable. I would use a collection (in the second) to keep track of
the instances of the first application. The first can raise events (via
remoting) to notify the second of things.

Matthew MacDonald's book "Microsoft Visual Basic .NET Programmer's Cookbook"
from MS Press has some simple examples on using .NET Remoting.

Hope this helps
Jay

"feng" <li******@msn.c om> wrote in message
news:01******** *************** *****@phx.gbl.. .

In our VB.Net application, we need to be able to start
another process (thread won't do it) and run some logic in
it, and still be able to communicate with the main
process. Is this possible and how to do it?

Thanks

Fergus,
I tend to think of Automation as a COM (VB6) term, while .NET Remoting is a
..NET term.

In other words .NET Remoting is how you do Automation in .NET.

Other than the book I referenced I do not have any other good references on
Remoting.

Hope this helps
Jay

"Fergus Cooney" <fi******@tesco .net> wrote in message
news:ua******** ******@TK2MSFTN GP10.phx.gbl...

Hi Jay,

Thanks. :-)

What's the advantage of .NET Remoting overAutomation (bearing in mind that I know very little about Remoting) ?

Regards,
Fergus

Hi Jay,

Thanks - it's an area that I haven't looked at yet.

One area.

Out of a thousand :-(

Lol. :-)

Regards,
Fergus