hi all!

i've created a windows service written on c#. i've added some methods into
the "main" class inherited from System.ServiceProcess.ServiceBase. is there
any way to get an access to them from any other .net application? when i try
to add a reference using the service's exe file as a source, i get a message
like "a reference to '...' could not be added. this is not valid assembly or
COM component. only assemblies with extention 'dll' and COM components can
be referenced.", etc.

so how can i get an access to the methods and properties of my service from
other .net applications?

thanks.

---
mr.black's here...

I use .NET remoting for this, and it works fine.
Basically you set up your Windows Service as a remoting
server so your client can access it. Performance through
TCPChannel/binary is very good for what I do, but I
certainly haven't pushed it hard enough to get some hard
figures.

There may be other ways too, but I'm not very sure about
what and how.

Cheers,
Donald Xie

>-----Original Message-----
>hi all!
>
>i've created a windows service written on c#. i've added
some methods into
>the "main" class inherited from
System.ServiceProcess.ServiceBase. is there
>any way to get an access to them from any other .net
application? when i try
>to add a reference using the service's exe file as a
source, i get a message
>like "a reference to '...' could not be added. this is
not valid assembly or
>COM component. only assemblies with extention 'dll' and
COM components can
>be referenced.", etc.
>
>so how can i get an access to the methods and properties
of my service from
>other .net applications?
>
>thanks.
>
>---
>mr.black's here...
>
>
>.
>

Alexander Cherny wrote:
> hi all!
>
> i've created a windows service written on c#. i've added some methods
> into the "main" class inherited from
> System.ServiceProcess.ServiceBase. is there any way to get an access
> to them from any other .net application? when i try to add a
> reference using the service's exe file as a source, i get a message
> like "a reference to '...' could not be added. this is not valid
> assembly or COM component. only assemblies with extention 'dll' and
> COM components can be referenced.", etc.
>
> so how can i get an access to the methods and properties of my
> service from other .net applications?

It all depends on what you want to do. ServiceController allows you to
'send' a custom 'control message' to the service through ExecuteCommand,
this is handled by your implementation of ServiceBase.OnCustomCommand.
ExecuteCommand goes through the Service Control Manager, os it can be called
by another process. Of course, you cannot pass data or get results through
this method. To do that you should either implement the service as a .NET
remoting server (as has been suggested) or you could use the .NET sockets
classes and implement a socket server. This second option has the advantage
that any code can call the socket server.

Richard
--
my email (E-Mail Removed) is encrypted with ROT13 (www.rot13.org)

> It all depends on what you want to do.

when i programmed on DCOM/COM+, i created an ATL project as a windows
service (NT service), then added an ATL class. the service part keeps, for
example, a collection, i could get an access from COM-part of the project
to. as a result, i could start the service on a computer and get an access
from any other COM-compatible clients (c++, vb, asp applications) to this
collection (alone for the service). besides, the service could manage its
collection (check for expiration time and delete expired items, for
example). it was very useful.

so, i'm looking something similar in the .NET ideology.

> ServiceController allows you to
> 'send' a custom 'control message' to the service through ExecuteCommand,
> this is handled by your implementation of ServiceBase.OnCustomCommand.
> ExecuteCommand goes through the Service Control Manager, os it can be
called
> by another process. Of course, you cannot pass data or get results through
> this method. To do that you should either implement the service as a .NET
> remoting server (as has been suggested) or you could use the .NET sockets
> classes and implement a socket server. This second option has the
advantage
> that any code can call the socket server.

ServiceController has very limited possibilities to manage the service -
only start, stop, etc. but i need to communicate with the service. besides,
i need to keep objects (for example, .NET-instances) in its collection.

so, probably, it makes sence to take a look at .NET remoting servers..

thanks anyway.

---
mr.black's here...

> yeah, one of the issues of moving from COM to .NET is that COM inproc
> servers are treated as a 'lightweight' version of local (EXE) servers[1]
so
> there is not a great difference between EXE and DLL COM servers. In .NET,
> there is a much bigger difference between library (DLL) and EXE
assemblies:
> a library assembly can be used by any other assembly (assuming suitable
> evidence is available), but an EXE assembly serves solely as a 'housing'
for
> .NET (and hences libraries) to run; other than .NET remoting there is no
way
> to get access to .NET objects in the EXE as .NET objects. Even with .NET
> remoting you have to provide some library assembly that has the metadata
> that can be imported to satisfy the compiler - which usually means that
such
> objects should be implemented in library assemblies.
>
> [1] You do have more control over things like the threading of the class
> factory and security with local servers.

it sounds like COM+ applications. actually COM object, being placed into
some COM+ application, takes characteristics of an out-of-process COM
component (EXE COM server): it runs in the separate process (providing by a
separate dllhost.exe), doesn't it? and .NET remoting looks very similar to
this. but, in COM+ it's done much easier: you don't need to implement any
"interface" elements. you get it absolutely automatically, just by placing
your COM object into a suitable COM+ application. and besides you get more
control like security, etc., too.

however, the truth is you could do this just with in-process COM object. to
have any control over out-of-process COM there was only one way - DCOM. but
there's no additional stuff to get an access to such a DCOM server. for any
COM compatible client applications it's clear (on the programming level) to
get an access either to an in-process COM object, or to an out-of-process
object, or to a COM object placed into COM+ application.

may be .NET remoting enough easy, too. i'm gonna investigate it.

---
mr.black's here...