Get custom object via WCF in an Explorer-Extension isn't working but in Winform

Question

I have a WCF Host with something like this:

[ServiceContract]
public interface IMountToOs
{
    [OperationContract]
    char GetMountDriveLetter();

    [OperationContract]
    MyTestClass MyTest();
}

public class MyTestClass
{
    public string A { get; set; }
    public string B { get; set; }
}

Client

    private IMountToOs _proxy;
    public IMountToOs Proxy
    {
        get
        {
            if (_proxy == null)
            {
                NetTcpBinding binding = new NetTcpBinding();
                binding.MaxReceivedMessageSize = 2147483647;
                binding.OpenTimeout = TimeSpan.FromMilliseconds(50000);
                EndpointAddress address = new EndpointAddress("net.tcp://localhost:1234/MountToOsHost");
                //_proxy = new MountToOsClient(binding, address);
                ChannelFactory<IMountToOs> factory = new ChannelFactory<IMountToOs>(binding);
                _proxy = factory.CreateChannel(address);
            }

            return _proxy;
        }
    }

While I can access

    MessageBox.Show("Okay - " + Proxy.GetMountDriveLetter());

I can't call this method:

    MessageBox.Show("Okay - " + Proxy.MyTest().A);

The complete extension is not working. But only while using it in an extension. Even if I insert a Messagebox in the first line of the extension it is not hit. I don't know why. It seems to run a pre-check and find the call of the custom class which is refused or so... If I use a winform or so there is no problem.

.net 3.5

curious is that I have a break-point and a message of the hosts side. So I see that the method is not called

Update now I moved the wcf-call in the Load Method of the extension and get a exception:

System.MissingMethodException: method not found: "Contracts.Interfaces.MyTestClass Contracts.Interfaces.IMountToOs.MyTest()".

My winform test and this extension use the same interface so that the method should known from both. no contract or so is outdated

Answer 1

According to what I found here and in the comments of the post: "For creating dynamic service proxy using client channel factory method, you will need datacontracts of the service. If you don't have datacontracts but you have the service URL, then you could use reflection to create proxy at runtime and call the service method."

Seems that the MyTestClass type is not known on the client side, so I think you could use reflection, or share the class between the client and server or much more simple, use the datacontract attribute.

Also, found something on MSDN that says something like this:

"When to use a proxy?

We create proxy using svcutil.exe. The output of this tool gives a proxy class and makes corresponding changes to the application configuration file. If you have a service that you know is going to be used by several applications or is generic enough to be used in several places, you'll want to continue using the generated proxy classes. We use proxy in WCF to be able to share the service contract and entities with the client. Proxies have several restrictions like they need to have gets and sets , contructors can't be exposed , methods other than the service contract cannot be exposed, repetition of code, everytime that we add/modify a service contract/data contract/message contract we need to re-generate the proxy for the client.

When to use ChannelFactory

The other option is using the ChannelFactory class to construct a channel between the client and the service without the need of a proxy . In some cases, you may have a service that is tightly bound to the client application. In such a case, it makes sense to reference the Interface DLL directly and use ChannelFactory to call your methods using that. One significant advantage of the ChannelFactory route is that it gives you access to methods that wouldn't otherwise be available if you used svcutil.exe..

When to use a ChannelFactory vs Proxy class?

A DLL is helpful if the client code is under you control and you'd like to share more than just the service contract with the client -- such as some utility methods associated with entities and make the client & the service code more tightly bound. If you know that your entities will not change much and the client code is less, then a DLL would work better than a proxy. If the client to your service is external to the system, such as API, it makes sense to use a proxy, because it makes sharing the contract easier by giving a code file rather than a DLL."

Answer 2

We cant see the class MountToOsClient: IMountToOs So we can only assume it is ok.

[DataContract] // Missing
public class MyTestClass 
{ 
    [DataMember] // Missing
    public string A { get; set; } 
    [DataMember] // Missing
    public string B { get; set; } 
} 

MountToOsClient can not expose Mytestclass without these attributes.