Calling ServiceWire from a COM client in Windows
berk-csi opened this issue · 2 comments
Hi,
I am planning on using ServiceWire to implement an API for our product. The API is a .NET Framework 4.8 assembly (for now, will migrate to .NET 7 soon) with many interfaces. It is also a COM visible assembly which makes it possible for COM based clients (e.g. Excel VBA, VBScript, C++, etc.) to use the API to automate our product.
ServiceWire named pipes work as expected when the API client is .NET Framework 4.8 based. When the same API client with the exactly same logic is implemented in VBA/VBScript (i.e. use COM), the call to the constructor of NamedPipeClientStream is throwing a "System.NotSupportedException: The given path's format is not supported." (see below screenshot).
As far as I can tell, there's nothing wrong in the arguments being passed to NamedPipeClientStream, and the same set of arguments work when the call is initiated from a .NET Framework 4.8 client rather than a COM client like Excel. The stack trace points to a file IO permission issue, but I don't have any clue why it is happening.
Attached is a simple reproducer solution with 4 projects:
1- APIDLL: shared .NET assembly defining the API interface
2- ClientDLL: .NET based assembly implementing the API in a class and using ServiceWire to call the server. The class is also exposed to COM.
3- ClientEXE: .NET based client using ClientDLL to call the server.
4- ServerEXE: .NET based server implementing the API in a class and using ServiceWire named pipes to listen to connections.
There are also two COM based clients in the folders below. They are functionally identical to .NET based ClientEXE.
1- ClientExcel: Excel client referencing ClientDLL (via COM) to call the server.
2- ClientVBScript: VB Script file using ClientDLL (via COM) to call the server.
Both COM based clients fail the same way when attempting to create an instance of the NamedPipeClientStream.
Building the solution should register ClientDLL for COM (make sure to run Visual Studio as admin), and you can open the Excel file in ClientExcel and run the only macro to reproduce the issue. Similarly you can run the script in ClientVBScript folder from the command line using cscript which leads to the same error. You can also run the ClientEXE project to verify that the same logic works when used from a .NET client.
Many of our users are still using Excel to automate our product via our API, so supporting COM based clients is critical. Any help getting ServiceWire named pipes work with COM is appreciated.
I've never tried this and my VBA/COM days are very old. Named Pipes are like files to the OS in a way. I suspect the VBA context has limited permissions in that respect. That's where I would start the research.
This is a VBA security sandbox issue that ServiceWire is not designed to handle. I'm not able to devote resources to solving this problem but if you want to submit a PR, I'm happy to review it.