Home/ Questions/Q 5958407
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T18:32:18+00:00

Let’s say I have created a Windows Service exposing a method foo(param1 as string)

  • 0

Let’s say I have created a Windows Service exposing a method foo(param1 as string)

Is it possible to somehow invoke foo("SomeAwesomeString") from VBScript directly (i.e., without it having to launch an additional process)?

The use case is this: I am trying to write an ‘extension’ application for hMailServer (hMS), but hMS can only invoke VBscript scripts when an event happened. I can have the VBscript launch an .exe every time the event happened, but the processing involve opening and closing a connection to a back-end database. So, every invocation is very expensive. I had been thinking that I can reduce the expense by having a Service to maintain the connection (i.e., opening it once and re-open it if the connection closed). Plus by implementing the processing as background worker threads will result in a non-blocking processing + less process-starting overhead.

Update: How I did it

Whew. After lots of searching and experimentation, I think I found a way. I’ll post it as an answer below. If anyone can give a better answer than mine, feel free to post. If it’s indeed better, I’ll unmark my answer and mark yours.

Minor update/erratum:

I forgot to tell you that the Windows Service is created using VB.Net 2010. Sorry.

Final Update: I Give Up

After searching all over the Internet — and experimenting without end — I give up.

I decided to not expose the method, but use Named Pipes instead. Now the VBScript script just need to write to an FSO opened to the //./pipe/PIPENAME, and let the service figure out what the heck the VBScript wants.

Thanks anyways for your attempts to help, friends.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You might combine the two approaches.

    Implement your service, as you suggest, to maintain the requisite connections.

    Then you from VBScript, invoke a tiny .exe whose entire purpose is to communicate its command line parameter to the aforementioned service.

    In fact, rather than having to create a different .exe for each api (e.g., “hms-foo.exe”, “hms-bar.exe” or whatever), make the name of the api just another command line parameter.

    Now, you might have one very simple .exe called, say, hmscom.exe, which VBScript could invoke with a command line like, “hmscom.exe foo SomeAweSomString”. Internally, hmscom.exe would do whatever is necessary to invoke the exported API, foo() with the parameter “SomeAweSomString”.

    Even better would be to implement the above functionality within a DLL instead of an .exe and use the standard rundll32.exe to invoke an entry point of the DLL with the command line arguments as parameters, said function then communicating with the service as described above for the .exe.

    This would make it more difficult for a user to spuriously call your service by accidentally double clicking an .exe file since there won’t be one.

    • 0