accessing to a windows service

  • Thread starter Thread starter Alexander Cherny
  • Start date Start date
A

Alexander Cherny

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.
 
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
Click to expand...
System.ServiceProcess.ServiceBase. is there
 
Alexander said:
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?
Click to expand...

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
 
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.
Click to expand...

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.
 
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.
Click to expand...

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.
 
Back
Top