Reputation: 2733
I have a third-party application in which I can script via VBScript. Now I want to call a running .NET application from it. If I want to do this with COM I'd have to use an ExeComServer
. There is the problem that this is not possible in my workflow. A COM+ Server is also impossible because of the strong-name.
I had to forward an object from VBScript to .NET.
Upvotes: 1
Views: 480
Reputation: 124794
One way to call a running .NET application would be to expose a WCF service from the .NET application. VBScript can call web services, e.g. using the XMLHTTP object.
On the other hand, you also said:
I had to forward an object from VBScript to .NET.
If by this you mean marshal a COM object, I don't think you have any alternative but to use COM.
Upvotes: 0
Reputation: 17356
If COM is out of question for you, you can try using sockets from VBScript but you're going to run into all kinds of problems. There are some 3rd-party COM-based socket libraries that you can buy but I've never used any so I can't recommend any of them. Your .NET application would also have to be modified quite heavily to listen to a port and communicate with your script - this would be some work.
Another possible option that I can think of is to create a COM-enabled .dll in .NET that implements the socket logic for you and talks to your .NET application. You can then create an instance of this object from VBScript and talk to it through COM. Your .dll will then use sockets to talk to the .NET .exe. This gives you 2 .NET objects on the ends of the socket - it's easier to implement this in .NET. You'd still have to change your main .exe to listen to a socket.
This is somewhat complicated because VBScript was designed to use COM - your requirement to not to use COM is a limiting factor on what you can do. (Even my idea would involve a COM object but at least it'd remove the requirement of an EXE COM server.) There could be simpler options - this is just off the top of my head.
Upvotes: 1