Идентификатор ошибки WCF ExceptionShielding не совпадает с handleInstanceId, переданным обработчику

У меня есть следующее украшение на моем сервисе

<ExceptionShielding("MyExceptionPolicyName")>

когда выдается исключение ошибки, моя политика улавливает ошибку и регистрируется просто отлично. Он принимает идентификатор handleInstance и регистрирует его вместе с ошибкой для справки. Что я замечаю, так это то, что Guid, возвращенный в ошибке «Идентификатор ошибки:», отличается от того, который был передан в обработку instanceId.

Я также пытался украсить операцию так

<FaultContract(GetType(ValidationFault))>

но это дает те же результаты.

Что я хотел бы сделать, так это каким-то образом зафиксировать этот «Идентификатор ошибки:», переданный потребителю, чтобы я мог зарегистрировать его вместе с исключением. * дополнительная информация: обработчик политики исключений является настраиваемым, который принимает исключение и записывает его различные свойства и данные в определенную схему базы данных журнала исключений.

Кто-нибудь знает, как это сделать?

ОБНОВЛЕНИЕ: согласно комментарию @Jay Patel, я добавил это в свою конфигурацию, чтобы включить трассировку

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true">
        <listeners>
          <add name="traceListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "c:\Temp\Traces.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Затем я выполнил запрос, чтобы получить ответ об ошибке, защищенный защитой от исключений. Строка ответа об ошибке имеет следующий формат: «Произошла ошибка при использовании этой службы. Обратитесь к администратору за дополнительной информацией. Идентификатор ошибки: {GUID}»

Затем я просмотрел журнал трассировки и не нашел доказательств GUID или этой строки.

Вот pastebin ссылка на журнал трассировки для тех, кому интересно посмотреть пример использования ExceptionShielding.

ОБНОВЛЕНИЕ 2:

Опять же, согласно комментарию @Jay Patel, добавил это. Я попробовал значение -1 и max int для maxMessageLog, чтобы убедиться, что я получаю наибольший объем данных в этом журнале.

<diagnostics>
  <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="2147483647" />
</diagnostics>

Лог не помогает. Он не содержит ничего ни о чем, даже близком к ответу на мой вопрос.

Чтобы уточнить на случай, если вышеизложенное неясно... Я хочу иметь возможность перехватывать GUID после "Идентификатор ошибки:" в сообщении обратно клиенту, чтобы я мог регистрировать его, за исключением того, что регистрируется обработчиком исключений. Таким образом, клиенты могут связаться с «Администратором», как говорится в сообщении, с идентификатором ошибки и действительно смогут что-то найти.

Вот полная включенная трассировка pastbin


exception .net wcf fault enterprise-library
person wakurth    schedule 09.04.2013    source источник
comment
Итак, я уже однажды назначил награду за это. Если кто-то придет с ответом в какой-то момент, я сделаю все, что в моих силах, чтобы дать им награду в 50 баллов (я даже не уверен, сможете ли вы это сделать, но если придет ответ, и он мне понравится, Я опубликую награду и вознагражу этого человека ... если это не так здесь, в стеке ... ну ... я дам вам виртуальную пятерку и скажу спасибо :)   -  person wakurth    schedule 28.05.2013
comment
Не то чтобы это помогло, но вы пробовали вести журнал с помощью трассировки в WCF Tracing Вы видите здесь тот же идентификатор ошибки?   -  person Jay Patel    schedule 18.07.2013
comment
Я нет. Я это проверю. У компании, в которой я работаю, есть контакт в MS, которому я задал этот вопрос, и мне сказали, что они передадут его команде EntLib в MS и дадут мне ответ. Тем временем я попробую трассировку WCF и посмотрю, поможет ли она мне указать, как зафиксировать это значение на стороне сервера. Благодарю.   -  person wakurth    schedule 18.07.2013
comment
Да, единственной целью трассировки WCF является регистрация всех запросов/ответов/ошибок. Дайте мне знать, как это происходит.   -  person Jay Patel    schedule 18.07.2013
comment
Отвечающая строка ошибки: «Произошла ошибка при использовании этой службы». Пожалуйста, свяжитесь с вашим администратором для получения дополнительной информации. Идентификатор ошибки: {GUID}, и его нет в журналах трассировки.   -  person wakurth    schedule 27.07.2013
comment
Настройте свою службу, как в этом ответе< /а>   -  person Jay Patel    schedule 30.07.2013

Ответы (2)


arrow_upward
2
arrow_downward

Согласно http://msdn.microsoft.com/en-us/library/ff649012.aspx:

Вы также можете указать источник «{Guid}», чтобы добавить текущий идентификатор экземпляра обработки в свойство Fault Contract.

В вашем файле .config:

<mappings>
    <add source="{Guid}" name="HandlingInstanceId" />
</mappings>

В вашем ValidationFault FaultContract:

[DataMember]
public Guid HandlingInstanceId { get; set; }

Примечание. Источник "{Guid}" является специальным маркером для идентификатора экземпляра обработки.

См. также: http://entlib.codeplex.com/discussions/232049

И последние две записи: http://entlib.codeplex.com/discussions/243558

person Daniel Holder    schedule 18.09.2013
comment
Это добавляет его (идентификатор экземпляра обработки) к самой ошибке проверки, возвращаемой потребителю, но не помогает мне с моим вопросом, а именно, как зафиксировать идентификатор ошибки: {GUID}. Захват этого GUID - это именно то, что я изложил в вопросе. - person wakurth; 20.10.2013

arrow_upward
1
arrow_downward

журнал сообщений будет полезен? Если это так, я думаю, вам нужно что-то вроде этого в вашей конфигурации:

<source name ="System.ServiceModel.MessageLogging" 
      switchValue="Verbose, ActivityTracing">        
<listeners>
  <add name="xml" />
</listeners>

Please notice that source name here is 'System.ServiceModel.MessageLogging' and not 'System.ServiceModel'.

Полный пример см. в этой статье: http://msdn.microsoft.com/en-us/library/dd788183.aspx

Надеюсь, что это поможет вам.

person Tony    schedule 01.12.2013