Allowing other apps access to methods in a .net app

[cj]

I've often used methods exposed by software purchased for other uses to
automate tasks. For instance back in the late 90's I found the terminal
emulation package the company exposed methods that allowed me to write a
VB program that could use that terminal emulation package to connect to,
read, and enter data on the company's mainframes. I think this was
called OLE?

Well now I'm on the other end of the picture and I need to write into a
..net program the ability to allow Microsot MOM or System Center Manager
(whatever it's called now) to check the value of a few variables.
Ideally this would be done in such a way that any other software could
call a method of my app and get the value of a variable. I'm not sure
OLE will work because unlike the terminal emulation software which was
started up by the VB program, in this case my .net program is constantly
running and working independently it just needs to be probed for status
info.

Can someone tell me the buzz word for what I need to do so I can find
some info on how do do it? BTW my application is a Windows App, NOT
ASPX so a web service is NOT what I'm looking for.

If all else fails I'll just keep some environment variables set and
updated that MOM can look at.

Thanks!

 

[Bruce W. Roeser]

CJ,

The term that describes what you're trying to do is called "COM Interop".
Dot-Net code can call into ActiveX DLL's using the Com Interop feature. At
our company we have made extensive use of this ability as we migrate our
application forward a piece at a time.

-bwr-

 

[Michel Posseth [MCP]]

If i understand you correctly the scenario is :

The app that you developed is running constantly on a system other programs
written by third parties must have the ability to comunicate with this one
running instance .

Well in this case a inmediate COM interface wil not solve the problem as COM
creates a new instance in the past ( VB6 ) you could create ACTIVEX
executables with VB6 in apartment threaded state so 1 instance could server
many clients since .Net this is not possible annymore with COM , every .Net
COM instance is actually a new instance of your component .

What can you do to solve this :

You could make your app a service and control it with the service
controler or through a database
You could create your app as a singletong remoting object hosted in a
remoting server
You could use WCF ( requires framework 3.0 )

Ofcourse for all options you could write a COM dll that acts as a wrapper to
the actuall interface , this for legacy clients

This sort of application is also called a "distributed application"

HTH

regards

Michel

 

[cj]

If i understand you correctly the scenario is :

The app that you developed is running constantly on a system other programs
written by third parties must have the ability to comunicate with this one
running instance .
YES!

Well in this case a inmediate COM interface wil not solve the problem as COM
creates a new instance in the past ( VB6 ) you could create ACTIVEX
executables with VB6 in apartment threaded state so 1 instance could server
many clients since .Net this is not possible annymore with COM , every .Net
COM instance is actually a new instance of your component .

This was my fear, however I can write a vb program that will use an
already running instance of Excel and do things in it. How does excel
allow this?

What can you do to solve this :

You could make your app a service and control it with the service
controler or through a database
You could create your app as a singletong remoting object hosted in a
remoting server
You could use WCF ( requires framework 3.0 )

Your loosing me here except that I know WCF is supposed to be the
replacement for Web Services.

 

[Guest]

This was my fear, however I can write a vb program that will use an
already running instance of Excel and do things in it. How does excel
allow this?

Through it's COM interface:

http://en.wikipedia.org/wiki/Component_Object_Model

Your loosing me here except that I know WCF is supposed to be the
replacement for Web Services.

What Michel meant was to expose your application as a network app - this
allowing external applications to make network calls... either through
WCF, webservices, or another channel. However, if the applications which
need to talk to your app are COM, this may not be the best choice since
COM/ActiveX don't really interact with newer technology too well.

??????

..NET has the ability to expose your application/library/etc via a COM
interop layer thus allowing legacy clients to talk to the application.
The machine running the app still needs to have .NET installed, but
legacy applications can use COM to interface with the app.

http://www.codeproject.com/dotnet/nettocom.asp

Unfortunately COM isn't something straightforward to do ... and seeing
you don't know much about .NET - this maybe out of your league? You may
want to try exposing a simpiler app first (i.e. a hello world DLL), then
move your way up to exposing your current application.