Я вообще не использую сгенерированные прокси. У меня просто есть общая сборка между моим клиентом и сервером, которая определяет интерфейсы контрактов на обслуживание + следующая ловкость рук.
// this class can be used to instantiate a unidirectional proxy (one that doesn't require callbacks from the server)
public class UniDirectionalServiceProxy<T> : System.ServiceModel.ClientBase<T> where T : class
{
public UniDirectionalServiceProxy()
{
}
public UniDirectionalServiceProxy(string endpointConfigurationName) :
base(endpointConfigurationName)
{
}
public UniDirectionalServiceProxy(string endpointConfigurationName, string remoteAddress) :
base(endpointConfigurationName, remoteAddress)
{
}
public UniDirectionalServiceProxy(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) :
base(endpointConfigurationName, remoteAddress)
{
}
public UniDirectionalServiceProxy(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) :
base(binding, remoteAddress)
{
}
// new keyword allows us to supercede the inherited protected member and make it public.
public new T Channel
{
get
{
return base.Channel;
}
}
}
Выглядит знакомо, верно? Создайте этот объект, и затем вы просто измените свои звонки, чтобы использовать члена канала.
Вы также можете использовать ChannelFactory, чтобы получить почти такой же результат (я предполагаю, что они сделали Channel защищенным членом ClientBase, чтобы поощрять разработчиков использовать ChannelFactory), но я предпочитаю этот механизм, так как в итоге вы получаете один объект, который инкапсулирует управление связью. и звонки по проводам. Очевидно, что таким образом вы потеряете асинхронные методы из svcutil, но в любом случае это довольно легко сделать самостоятельно с делегатами.