2014-10-13 2 views
0

людям, я столкнулся с какой-то странной проблемой, когда создал клиент SL для доступа к службе WCF, размещенной в IIS7. Мой контракт службы, как показано ниже:Исключение async произошло, когда служба wcf доступа к Silverlight размещалась в iis 7

[ServiceContract] 
public interface IAuthorizationService 
{ 
    [OperationContract] 
    RoleMetadata GetRoleMetadata(); 

    [OperationContract] 
    void CreateNewRole(Guid id, string name, string description); 
    [OperationContract] 
    void UpdateRole(Guid id, string name, string description); 
    [OperationContract] 
    void RemoveRole(Guid id); 

    [OperationContract] 
    void AddPersonsToRole(Guid roleID, IEnumerable<int> pids); 
    [OperationContract] 
    void RemovePersonsFromRole(Guid roleID, IEnumerable<int> pids); 

    [OperationContract] 
    void GrantRolePermissions(Guid roleID, Int64 mask); 
    [OperationContract] 
    void RevokeRolePermissions(Guid roleID, Int64 mask); 
} 

Я сказал, что проблема странно, потому что части методов этой службы могут быть доступны и другие не доступны. условие есть, когда я попытался получить доступ к методу GetRoleMetadata, я получил ошибку, которая показала исключение async, и результат был недействительным. Но когда я позвонил в CreateNewRole, я получил плавно новую запись в базе данных.

Я проверял как обслуживание, так и конфигурацию клиента много раз и переписывал службу в некоторых различных реализациях, и я получил ненужную культуру. Поэтому я надеюсь, что могут быть мастера, которые могут помочь мне победить его.

Еще одна вещь, она отлично работает в условиях разработки (vs2013, sqlexpress 2008). Проблема возникает после реализации проекта на сервере (предприятие Windows Server2008 R2, предприятие SQLServer 2008, IIS7, .net framework 4.0).

[2014-10-16] Я переписал сервис и соответствующий клиентский код с режимом канала WCF. новые контракты:

[ServiceContract] 
public interface IAuthority 
{ 
    [OperationContract(AsyncPattern = true)] 
    IAsyncResult BeginGetRoles(AsyncCallback callback, object state); 
    RoleMetaData EndGetRoles(IAsyncResult result); 
    [OperationContract(AsyncPattern = true)] 
    IAsyncResult BeginUpdateRole(bool addNewRole, Guid id, string name, string description, AsyncCallback callback, object state); 
    void EndUpdateRole(IAsyncResult result); 
    [OperationContract(AsyncPattern = true)] 
    IAsyncResult BeginRemoveRole(Guid id, AsyncCallback callback, object state); 
    void EndRemoveRole(IAsyncResult result); 
    [OperationContract(AsyncPattern = true)] 
    IAsyncResult BeginAlterRoleMembers(Guid roleID, bool addMembers, IEnumerable<int> pids, AsyncCallback callback, object state); 
    void EndAlterRoleMembers(IAsyncResult result); 
    [OperationContract(AsyncPattern = true)] 
    IAsyncResult BeginAlterRolePermissions(Guid roleID, bool grantPermissions, Int64 mask, AsyncCallback callback, object state); 
    void EndAlterRolePermissions(IAsyncResult result); 
} 

, а затем со стороны клиента я использую ChannelFactory и Channel для доступа к сервису. Однако проблема остается. Я могу получить доступ ко всем методам, но GetRoles. На этот раз я получил новое сообщение об ошибке: «[HttpWebRequest_WebException_RemoteServer] NotFound». Мое сердце разбивается. Следующий шаг: я собираюсь переписать весь пользовательский интерфейс и прокси-сервер службы, а именно совершенно новый клиент для проверки этой проблемы. Боже, благослови меня.

[2014-10-16 23:32 Chengdu] Я написал нового простого клиента для доступа к сервису. Проблема все еще существует. Однако это дает понять, что что-то на сервере неверно. Завтра я должен тщательно проверять вещи на стороне сервера. Конфигурация IIS является подозреваемым №1? Но есть еще 5 служб, которые используют одни и те же конфигурации с этой неудачной службой авторизации и работают как ожидалось.

WCF следы тоже не показывал должное уважение! Я сконфигурировал трассировку в web.config следующим образом и просто получил пустой файл.

<system.diagnostics> 
     <sources> 
      <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true" > 
       <listeners> 
        <add name="xml" /> 
       </listeners> 
      </source> 
      <source name="System.ServiceModel.MessageLogging"> 
       <listeners> 
        <add name="xml" /> 
       </listeners> 
      </source> 
     </sources> 
     <sharedListeners> 
      <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="D:\trace.xml"/> 
     </sharedListeners> 
    </system.diagnostics> 
<system.serviceModel> 
     <diagnostics> 
      <messageLogging logEntireMessage="true" 
             logMalformedMessages="true" 
             logMessagesAtServiceLevel="true" 
             logMessagesAtTransportLevel="true" 
             maxMessagesToLog="500"/> 
     </diagnostics> 
<!--...--> 
</system.serviceModel> 

Мастера, пожалуйста, покажите мне прозрение и спас меня!

ответ

1

О да! Я починил это! Я получил большой урок и должен подвести итог. Мои этапы:

1.Чтобы прочитать спецификации трассировки WCF. (http://www.codeproject.com/Articles/36031/WCF-Tracing-FAQs, также есть статьи о детальной настройке трассировки в MSDN, которые можно легко обнаружить). И я считаю, что наилучшей практикой является настройка трассировки с использованием Service Configure Editing Инструмент вместо ручного редактирования, таким образом, может избежать ошибок конфигурации, которые могут привести к неудачной трассировке.

2. После правильной настройки трассировки wcf я получил журнал ошибок активности с красным фоном в средстве просмотра журнала трассировки. После проверки я быстро обнаружил ошибку и исправил ее.

3. Мое исключение - от уровня доступа к данным (DAL). Неожиданный коллега модифицировал процедуру хранения - просто заменил позиции двух столбцов одного и того же типа данных. Он не знал об этом и не уведомлял меня. Это имело место только на сервере внедрения не в среде разработки. Поэтому я не генерировал новые классы DAL из базы данных сервера. Таким образом, логическая ошибка всегда возникала при моем обслуживании.Это показывает, что Entity Framework, вероятно, является хорошим выбором, который может избежать подобных проблем.

4. Еще один урок заключается в том, что управление нашей специальной группой для этого проекта слишком слабое. Сотрудничество можно считать неудачным в некоторой степени из-за такого большого коммуникационного вопроса.

Смежные вопросы