Sign in to follow this  
e-u-l-o-g-y

[.net] External program API

Recommended Posts

Hi! Does anybody know of any good tutorials on programming an API for a .NET application? I would like to make it possible to access a program object, and thereby have direct control of the program. Any suggestions? -Thanks in advance

Share this post


Link to post
Share on other sites
Oh... sorry... I was a bit tired when I wrote the message.. what I meant was an external API to control the program like for instance photoshop has. I would like to have a couple of functions that gives you access to the application object from other programs.

Share this post


Link to post
Share on other sites
Just expose the application object (whatever you mean by that) as a public property of something (something static maybe?). Then any application that can use your assembly can access it. I don't quite know what you mean by 'have direct control of the program', but a standard .Net library is usable from other programs with nothing special.

Share this post


Link to post
Share on other sites
Hmm... ok... I'll try to explain a bit better: I have two different projects. One that contains a gui application, and one command line tool that makes it possible to manipulate the first program while it's running. I want the command line tool as well as any other program that includes an API assembly to be able to communicate with the instances of the gui program.

I expect the usage to look a bit like this:

foreach (GuiApplication app in GuiApplication.RunningInstances)
{
app.PerformSomeAction();
}

Share this post


Link to post
Share on other sites
may be a better way but you could always just write a little server in the main app. Then write a little API that communicates with the main app's server via sockets. The little API would have hooks for sending appropriately formatted data streams to the main app's server which would then execute them within the main app. Likewise you could have method calls which would query for info from the main app such as getting a list of objects and such.

-me

Share this post


Link to post
Share on other sites
I wrote a little article on Plugin Interfaces in .NET a little while ago that covers how to implement a plugin archatecture into a .NET environment. In this case, your GUI application would be a plugin to the main console application. When you write a command into the console, you could call a function in the GUI Application (IPlugin).

Share this post


Link to post
Share on other sites
Have your GUI application expose an interface via remoting. Then your application can be accessed like this:


IApplication app = (IApplication)Activator.GetObject(typeof(IApplication), "tcp://localhost:1234/Application");
app.DoStuff();


Share this post


Link to post
Share on other sites
Rob Loach:
I've done something similar, but the problem with this approach is that the gui part of the program is dependent on the console part, which is undesirable in my situation, since I consider the console part to be an external tool.

Arild Fines:
Now that seems interesting.. Could you elaborate on how it works?

Share this post


Link to post
Share on other sites
I suggest putting all of your functionality into a dll, and then calling that dll from your main application.

Another good solution is to create a three tier design, with your access api in the middle tier. You might want to look up n-tier design.

By the way, a good way to learn about api is to read a good database book, or to look at already existing api that you like. Basically api have several kinds of methods for every action.
Get
Set
Remove
Update

Make sure that you use a naming scheme that you can continue to use moving into the future. Ie.) what do you call the method names in version 2, so that nothing breaks in version 1?

Make sure that you stay consistent with your naming convention and the order of parameters.

Have fun.

Share this post


Link to post
Share on other sites
BradSnobar:
I'll google "n tier design" as it sounds a bit like what I was planning on. I'm not really having any problems with designing the API. The problem is getting an object from another process. Exposing functionality in an assembly is definately the way to go, but it doesn't help with this problem. For instance making a static Application object won't make THAT instance accessible to another program.

Share this post


Link to post
Share on other sites
Quote:
Original post by e-u-l-o-g-y
Arild Fines:
Now that seems interesting.. Could you elaborate on how it works?

I can give an example that's in the wild: Draco .NET. It contains of several components, the primary of which is a Windows Service which performs the actual build operations (Draco .NET is a continuous integration/build tool). The other components are a console app, a GUI app and an ASP.NET app. All these latter three communicate with the service through remoting, in order to start and stop builds.

The remoting object is here and is configured in OnStart() here based on the configuration file here.

The console client has numerous examples of using the remote interface.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this