WCF ExceptionShielding Błąd Identyfikator nie zgadza się z handlingInstanceId przekazane Handler

Question

Mam następujący urządzone na mojej służbie

<ExceptionShielding("MyExceptionPolicyName")> 

gdy wyjątek Błąd jest generowany, moja polityka podnosi błąd i loguje się dobrze. Zajmuje identyfikator HandlingInstance Id i rejestruje go wraz z błędem dla odniesienia. Zauważam, że Guid zwrócony w błędzie "Error ID:" jest inny niż ten przekazany do obsługi instanceId.

Ja również próbował ozdobić operację jak tak

<FaultContract(GetType(ValidationFault))> 

ale to daje te same rezultaty.

To, co chciałbym zrobić, to sposób, w jaki przechwycono ten "Error ID:" do konsumenta, aby móc go zarejestrować wraz z wyjątkiem. * informacje o dodatkach: procedura obsługi wyjątku jest niestandardowa, która pobiera wyjątek i rejestruje różne właściwości i dane w określonym schemacie db dziennika wyjątków.

Ktoś wie, jak to osiągnąć?

UPDATE: na komentarz @Jay Patel „s, dodałem to do mojego config, aby umożliwić śledzenie

<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> 

Potem wykonał prośbę, aby uzyskać odpowiedź na uszkodzenia ekranowany przez ekranowanie wyjątków. Łańcuch odpowiedzi na błąd jest sformatowany w następujący sposób: "Wystąpił błąd podczas korzystania z tej usługi.Aby uzyskać więcej informacji, skontaktuj się z administratorem .. Identyfikator błędu: {GUID}"

Następnie przejrzałem dziennik śledzenia i nie znalazłem żadnych dowodów GUID lub tego łańcucha.

Oto link pastebin do traceloga dla każdego, kto dba o przykład takiego rozwiązania podczas korzystania z ExceptionShielding.

Update2:

Znowu na komentarz @Jay Patel, dodanych w tym. Wypróbowałem -1 i maksymalną wartość int dla maxMessageLog, aby upewnić się, że otrzymuję największą ilość danych w tym dzienniku.

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

Dziennik nie jest pomocny. Obejmuje ona nic o mnie o wszystkim, nawet blisko odpowiadając na moje pytanie.

Aby wyjaśnić w przypadku, gdy nie jest jasne, powyżej ... Chcę, aby móc uchwycić GUID po „ID błędu:” w wiadomości z powrotem do klienta, więc mogę zalogować się go z tą różnicą, że jest zalogowany przez procedurę obsługi wyjątku. W ten sposób klienci mogą skontaktować się z "Administratorem", jak mówi komunikat z identyfikatorem błędu, i faktycznie mogą znaleźć coś.

Oto pełna ślad włączony pastbin

Answer 1

Według http://msdn.microsoft.com/en-us/library/ff649012.aspx:

Można również określić źródło „{GUID}”, aby dodać bieżącego Handling id instancji do właściwości zamówienia usterki.

W pliku .config:

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

W swojej ValidationFault FaultContract:

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

Uwaga: "{GUID}" źródło wydaje się być specjalny marker do obsługi Instance ID.

Zobacz także: http://entlib.codeplex.com/discussions/232049

I, 2 ostatnie wpisy: http://entlib.codeplex.com/discussions/243558

Answer 2

jest rejestrowanie wiadomość zostanie pomocna? Jeśli więc myślę, że trzeba coś takiego w swojej konfiguracji:

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

Proszę zauważyć, że nazwy źródła tutaj jest „System.ServiceModel.MessageLogging”, a nie „System.ServiceModel”.

Pełen przykład można znaleźć w tym artykule: http://msdn.microsoft.com/en-us/library/dd788183.aspx

nadzieję, że to pomoże.