RunDll or remote activation needed

[David Merrill]

In the .NET Framework Developer's Guide there is a page
titled Building a Host application.
Within this page there is a note:

Unlike COM, remoting does not start the host or server
application for you. This is an important difference
between .NET remoting and remote activation in COM.

I need this functionality.
I need to be able to start a seperate win32 process and
communicate with it.
The trick is that there must not be any need for
configuration files or such.
I could approach the problem one of two ways.
Either my client dll can reference the server exe (but
referencing an exe is not allowed by the IDE).
Or I can reference and execute a dll.
The reason I want to reference it is to make sure that VS
always puts a copy of it where I can find it, so I can
execute it.

Another possibility is to make the server app also a COM
server and just register it that way, but this is not
managed and VS will not register an exe this way.

 

[Yan-Hong Huang[MSFT]]

Hello David,

Thanks for posting in the group.

------------------------------------
Unlike COM, remoting does not start the host or server application for you.
This is an important difference between .NET remoting and remote activation
in COM.
------------------------------------

This sentence means that in COM, when a client access a server, COM manager
in the system will run the COM server exe automatically. However, in
Remoting, it is not done automatically. We need to make sure that the
hosting application is running before we call the object from the client.

The goal of configuration file here is that we could use settings in the
file when running hosting app or remoting client. If the configuration file
changed, there is no need for us to rebuild hosting app or client exe. It
will make use of the new configuration automatically. Surely we could
program all the settings in code. But in that way, we need to rebuild the
project to apply new settings.

Based on your description, I feel what you need is a hosting app which is
running always. If so, I think you could develop the hosting app as a
windows service. So the client could access it at any time. Please correct
me if I have misunderstood your meanings.

Also, could you please describe some more on "client dll" in the post? I am
not sure of its exact meaning. Based on my understanding of these MSDN
articles, the DLL is for the remotable object. It should not be related to
the client or the hosting app.

Making server app a COM server could be one of your choice. However, I
think that goes back to typical DCOM programming.

If there is any unclear, please feel free to post here.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[David Merrill]

I know what the sentence means, I referenced it to make a
point.
I know how configuration files work, users are not
capable of understanding or manipulating them via any
means, so I do not use them. Also we have many many
client applications, requiring all those config files to
be edited is silly.
What is needed is a completely automatic and plug-n-play
means of starting the host app.
The host app cannot be an NT service, it cannot have
anything which ties it specifically to NT. And I do not
want it running all the time.

Looks like the only solution I have is to simply assume
that the host is in the same directory as the executing
assembly.
However, with the stupid way that Visual Studio copies
referenced assemblies to each projects bin directory,
developers will have to manually copy the host to each
and every directory that they have an exe in.
This is a serious problem.
Visual Studio also has problems if you configure the
outputs of every project to go in the same directory.
When editing or debugging it loads the assemblies into
its memory. When compiling it doesn't unload them thus
preventing them from being replaced and producing a
compile error.

 

[Yan-Hong Huang[MSFT]]

Hello David,

The internal implementation of DCOM and Remoting is different. In DCOM,
there is a system service who will monitor the port and run corresponding
COM server depending on the request. However, in .NET remoting, it is the
host application which listens to a port and handles requests from the
client. So if the host application is not started first, it is not possible
to reply to the request automatically. That is why I suggest you use a
windows service to run hosting app. In this way, they won't load assembly
if there is no request. So it won't do hard to system performance. If you
don't want it to tie to NT, you could run it as a autostart application
also.

For the reference probelm, I suggest you use "project reference" in the
solution, so that when there is any update, it will copy the new DLL to the
correcponding directory.

For the last problem, could you please post here with detailed steps so
that I could get more information on it for you?

Thanks very much. If you have any more concerns on it, please feel free to
post here.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.