T
TimPGade
I would like to add Remoting capabilities to my IP Form so that I can
establish InterProcess communications with another VB.Net application that I
lauch from IP as a new process thread.
My goal is to have IP become the Remoting Server and have the external app
as the Remoting Client. I have built a simple working example outside of IP
that consists of a Server.exe and Client.exe communicating via tcp on port
9080.
When I embed the "server" code into my IP form (which is nothing more than
setting a reference to the RemoteObjects.dll and executing the following
command:
RemotingConfiguration.Configure("SimpleServer.exe.config")), my client is
not able to find the server on the designated port.
The end result I am hoping to achieve is to have my external app (which is a
Windows Form application) pass back results without having to use external
files (ie. temp files or sql server). I need this because some of the
WebServices I use may not return the results in a timely manner, and because
IP does not support Async communications, I plan to catch the timeout error
and give the user the option to launch an external app that can wait on the
WebService and then notify IP when the results are available via a remoting
callback.
If I could eliminate the need for UI in my external app I can use the
Process stdin and stdout redirects to pass a stream back to the IP form.
Since I do need the UI, I am temporarily stuffing the base64 stream in a SQL
binary field and passing back the RowId as the ExitCode and trapping the
Process.Exited event. There is at least one advantage of doing it this way as
I can query SQL from IP at a latter time to see if the results have been
posted (in the event I miss the event). Right now the SQL/file based overhead
is a little too costly.
Launch external app
External app posts to SQL
External app has to close
IP has to fetch from SQL
IP has to dispose of SQL record
vs.
Launch external app
External app calls IP via remoting
Any ideas?
establish InterProcess communications with another VB.Net application that I
lauch from IP as a new process thread.
My goal is to have IP become the Remoting Server and have the external app
as the Remoting Client. I have built a simple working example outside of IP
that consists of a Server.exe and Client.exe communicating via tcp on port
9080.
When I embed the "server" code into my IP form (which is nothing more than
setting a reference to the RemoteObjects.dll and executing the following
command:
RemotingConfiguration.Configure("SimpleServer.exe.config")), my client is
not able to find the server on the designated port.
The end result I am hoping to achieve is to have my external app (which is a
Windows Form application) pass back results without having to use external
files (ie. temp files or sql server). I need this because some of the
WebServices I use may not return the results in a timely manner, and because
IP does not support Async communications, I plan to catch the timeout error
and give the user the option to launch an external app that can wait on the
WebService and then notify IP when the results are available via a remoting
callback.
If I could eliminate the need for UI in my external app I can use the
Process stdin and stdout redirects to pass a stream back to the IP form.
Since I do need the UI, I am temporarily stuffing the base64 stream in a SQL
binary field and passing back the RowId as the ExitCode and trapping the
Process.Exited event. There is at least one advantage of doing it this way as
I can query SQL from IP at a latter time to see if the results have been
posted (in the event I miss the event). Right now the SQL/file based overhead
is a little too costly.
Launch external app
External app posts to SQL
External app has to close
IP has to fetch from SQL
IP has to dispose of SQL record
vs.
Launch external app
External app calls IP via remoting
Any ideas?