Automation error when calling a method in WCF mex Moniker with Excel

Question

I have successfully created a service proxy as a client for my WCF service. But I cannot call any method in a nickname.

At the end of the WCF service, I have a dummy method called TestMethod, as shown below:

Public Function TestMethod(ByVal TestValue As String) As String Implements ICustomerService.TestMethod Return "You said.... " & TestValue End Function 

The following code creates Moniker in Excel.

 Public Sub WCFMexMonkierDemo() ' Create a string for the service moniker including the content of the WSDL contract file Dim mexMonikerString As String mexMonikerString = "service:mexAddress='http://localhost/CustomerService.svc/mex'" & _ ", address='http://localhost/CustomerService.svc'" & _ ", binding=CustomerServices.CustomerService" & _ ", bindingNamespace='http://tempuri.org/'" & _ ", contract=ICustomerService" & _ ", contractNamespace='http://tempuri.org/'" ' Create the service moniker object Dim mexMoniker, result Set mexMoniker = GetObject(mexMonikerString) result = mexMoniker.TestMethod("client call") '<-- error on this line 'Set result = mexMoniker.TestMethod("client call") MsgBox result Set mexMoniker = Nothing Set result = Nothing End Sub 

The above code works with a GetObject call, which implies the successful creation of a nickname. But I get an error message as soon as I try to call any method on it.

The WCF method works great with the Microsoft WCF test client and other WCF clients. Therefore, I know that the problem is not related to the service itself.

Answer 1

For those who are facing the same problem, here is a solution. I myself found out the cause of the problem, having examined a little, and below - what I did to get around this.

Cause of the problem

(It seems that) programs that use COM interfaces using the scroll bar to connect to WCF services have problems with complex types (e.g. classes, structures, arrays, etc.). They can only work with simple types (for example, string, integer, decimal, boolean, etc.). Complex types in method arguments or return type do not work.

Even if the method you want to call may not have any complex types in its method arguments or return type, they will not work if the service has at least one method.

In my case, the methods that interested me did not have complex types as method arguments or return types.

My decision

As soon as I found out what caused the problems, finding a solution around was easy. I just created a separate WCF service (interface) for my own interests and ensured that there are no complex types open in public, i.e. There were no complex types in the method definition — method arguments and return types.

Then I created a class that implements this interface, like any other WCF service. I deduced this class from the original one, so I don’t need to repeat all the business logic implemented there. The only goal this class solves is to overcome the limitation that I have encountered. It was just a wrapper around the source class with a limited number of methods. Methods are simply called the equivalent method of the base class and return the result directly to the client.

Then I modified my app.config file to host this new service, and then replaced the service address in the name bar of this new service address. So, basically, I ended up placing two WCF services - one for clients who can consume complex types, and another for those who cannot.

This is all that was required, and now everything is working fine. :)

---

NOTE that this is simply based on my own observation, and I could be wrong. Maybe something may be something that I can skip, and there may be better ways to get around this problem. If you find that this is the case, feel free to comment or post your decision.