Если Вы являетесь разработчиком/архитектором/тестировщиком и в своих проектах используете WCF, то опрос (Welcome to the .NET WCF Interoperability Survey), проводимой командной разработчиков Windows Communication Foundation, создан специально для Вас.
Обеспечение интероперабельность между платформами должны быть легко и просто, правда? Но, к сожалению, это не всегда так. Но Ваш feedback позволит в значительной мере улучшить совместимость и взаимодействие между платформами, в частности по средствам WCF. Пожалуйста, отправьте свой отзыв до 15 июля!
Опрос: http://mymfe.microsoft.com/WCF/Feedback.aspx?formID=283
Inproc SxS - это новый функционал CLR 4.0, который позволяет запускать несколько версий .Net CLR в рамках одного процесса (см. статью "Подход In-Process Side-by-Side"). Данная возможность особенно актуальная с выходом .Net 4.0, т.к. теперь помимо новых возможностей платформы .Net, мы имеем и новую среду выполнения – CLR 4.0. Как видно из рисунка ниже .Net 2.0/3.0/3.5/3.5SP1 все использовали и базировались на CLR версии 2.0. Очевидно, что с введение новой CLR возникнет вопрос о совместимости и работоспособности кода, ранее написанного для платформы .Net младших версий.
Основная задача Inproc SxS - это решить вопрос совместимости и параллельного использования модулей/надстроек (Add-In и т.п.), написанных на .Net различных версий. Данный вопрос хорошо освещен в следующей статье "In-Process Side by Side (Part1)", поэтому не будем подробно на этом останавливаться, а приведем несколько примеров использования In-Process Side-by-Side для Office Add-In:
Важно понимать, что Inproc SxS - это решение вопроса совместимости модулей/надстроек, написанных на различных версиях .Net. Inproc SxS - это не замена миграции или решения вопроса совместимости приложения целиком с новой версией .Net.
Рассмотрим следующие два сценария:
Задача: установить между клиентом и сервисом WCF безопасное соединение на транспортном уровне (с использование сертификата) и при этом применить аутентификацию по протоколу Kerberos.
Решение: кастомная привязка (binding) c параметром authenticationMode, установленным в значение KerberosOverTransport.
<customBinding> <binding name="kerberosCustomBinding"> <security authenticationMode="KerberosOverTransport" /> <httpsTransport /> </binding> </customBinding>
Примечание: при подобной конфигурации необходимо прописать для учетной записи, от которой работает WCF сервис (пул IIS), SPN (Service Principal Name), например, setspn.exe -a http\<serverFQDN> <domain\wcfserviceaccount>. А в конфигурационном файле клиента выставить соответствующие значение (<servicePrincipalName> тэг), например, <servicePrincipalName value="http\<serverFQDN>">, где <serverFQDN> - полное доменное имя сервера, а <domain\wcfserviceaccount> - доменная учетная запись, от имени которой запущен WCF сервис.
Допустим у нас есть следующий код:
IServiceContract proxy = ChannelFactory<IServiceContract>.CreateChannel(binding, address); ((IClientChannel)proxy).Open(TimeSpan.FromMinutes(1)); proxy.Method1(); proxy.Method2();
Для выполнения данной задачи нам необходимо выполнить преобразование к IContextChannel интерфейсу и установить значение параметра OperationTimeout, либо напрямую получить доступ к InnerChannel и выставить значение OperationTimeout.
proxy.Service1Client client = new proxy.Service1Client(); client.InnerChannel.OperationTimeout = TimeSpan.FromMinutes(5); Console.WriteLine(client.Method1()); client.InnerChannel.OperationTimeout = TimeSpan.FromMinutes(10); Console.WriteLine(client.Method2()); Console.ReadLine();