Aracılığıyla paylaş

İstisnalar ve Hataları Yönetme

Özel durumlar, hizmet veya istemci uygulaması içinde hataları yerel olarak iletmek için kullanılır. Öte yandan hatalar, sunucudan istemciye veya tersi gibi hizmet sınırları arasında hataları iletmek için kullanılır. Aktarım kanalları, hatalara ek olarak genellikle aktarım düzeyi hataları iletmek için aktarıma özgü mekanizmalar kullanır. Örneğin, HTTP aktarımı mevcut olmayan bir uç nokta URL'sini (hata geri göndermek için uç nokta yoktur) iletmek için 404 gibi durum kodlarını kullanır. Bu belge, özel kanal yazarlarına rehberlik sağlayan üç bölümden oluşur. İlk bölümde, özel durumların ne zaman ve nasıl tanımlanacağı ve nasıl atılacağını gösteren yönergeler sağlanır. İkinci bölüm, hata oluşturma ve tüketme konusunda yönergeler sağlar. Üçüncü bölümde, çalışan uygulamalarda sorun giderme konusunda özel kanalınızın kullanıcısına yardımcı olmak için izleme bilgilerinin nasıl sağlanmaları açıklanır.

Özel durumlar

Özel durum oluştururken göz önünde bulundurulması gereken iki şey vardır: İlk olarak, kullanıcıların özel duruma uygun şekilde tepki verebilen doğru kod yazmasına olanak tanıyan bir türde olması gerekir. İkincisi, kullanıcının neyin yanlış gittiğini, hata etkisini ve nasıl düzeltileceğini anlaması için yeterli bilgi sağlaması gerekir. Aşağıdaki bölümler, Windows Communication Foundation (WCF) kanalları için özel durum türleri ve iletileriyle ilgili yönergeler sağlar. Özel Durumlar için Tasarım Yönergeleri belgesinde .NET'teki özel durumlarla ilgili genel yönergeler de vardır.

Özel Durum Türleri

Kanallar tarafından oluşturulan tüm özel durumlar, System.TimeoutException, System.ServiceModel.CommunicationException veya CommunicationException türünden türetilmiş olmalıdır. (Gibi ObjectDisposedException özel durumlar da oluşturulabilir, ancak yalnızca çağıran kodun kanalı kötüye kullandığını belirtmek için. Bir kanal doğru şekilde kullanılıyorsa, yalnızca belirli özel durumları oluşturması gerekir.) WCF, kanallardan CommunicationException türetilen ve kanallar tarafından kullanılmak üzere tasarlanmış yedi özel durum türü sağlar. Sistemin diğer bölümleri tarafından kullanılmak üzere tasarlanmış başka CommunicationExceptiontüretilmiş özel durumlar vardır. Bu özel durum türleri şunlardır:

Özel Durum Türü Anlamı İç İstisna İçeriği Kurtarma Stratejisi
AddressAlreadyInUseException Dinleme için belirtilen uç nokta adresi zaten kullanımda. Varsa, bu özel duruma neden olan aktarım hatası hakkında daha fazla ayrıntı sağlar. Mesela. PipeException, HttpListenerExceptionveya SocketException. Farklı bir adres deneyin.
AddressAccessDeniedException İşleme dinleme için belirtilen uç nokta adresine erişim izni verilmiyor. Varsa, bu özel duruma neden olan aktarım hatası hakkında daha fazla ayrıntı sağlar. Örneğin, PipeExceptionveya HttpListenerException. Farklı kimlik bilgileriyle deneyin.
CommunicationObjectFaultedException ICommunicationObject kullanılan şey hata durumundadır (daha fazla bilgi için bkz. Durum Değişikliklerini Anlama). Birden çok bekleyen çağrıya sahip bir nesne Hatalı durumuna geçtiğinde, yalnızca bir çağrının hatayla ilgili bir özel durum oluşturduğunu ve çağrıların geri kalanının bir CommunicationObjectFaultedExceptionoluşturduğunu unutmayın. Bu özel durum genellikle bir uygulamanın bazı özel durumları göz ardı etmesi ve büyük olasılıkla asıl özel durumu yakalayan iş parçacığından farklı bir iş parçacığında hatadan muzdarip bir nesne kullanmaya çalışması nedeniyle oluşur. Varsa, iç özel durum hakkında ayrıntılar sağlar. Yeni bir nesne oluşturun. Hataya ICommunicationObject neyin neden olduğuna bağlı olarak, kurtarmak için gereken başka çalışmalar olabileceğini unutmayın.
CommunicationObjectAbortedException ICommunicationObject Kullanılan durduruldu (daha fazla bilgi için bkz. Durum Değişikliklerini Anlama). Benzer şekilde CommunicationObjectFaultedException ifadesi, uygulamanın başka bir iş parçacığından nesneyi Abort ile çağırmış olması nedeniyle nesnenin artık kullanılamaz hale geldiğini gösterir. Varsa, iç özel durum hakkında ayrıntılar sağlar. Yeni bir nesne oluşturun. İlk etapta ICommunicationObject'nin neden durdurulduğuna bağlı olarak, tam kurtarma için başka çalışmalar gerekebilir, bunu unutmayın.
EndpointNotFoundException Hedef uzak uç nokta dinlemiyor. Bu, uç nokta adresinin herhangi bir bölümünün yanlış, çözümlenemez veya uç noktanın devre dışı olmasından kaynaklanabilir. Örnek olarak DNS hatası, Kuyruk Yöneticisi kullanılamıyor ve hizmet çalışmıyor. İç özel durum, genellikle temel alınan aktarımdan ayrıntıları sağlar. Farklı bir adres deneyin. Alternatif olarak, gönderen bir süre bekleyebilir ve hizmetin devre dışı olması durumunda yeniden deneyebilir
ProtocolException Uç noktanın ilkesinde açıklandığı gibi iletişim protokolleri, uç noktalar arasında uyumsuzdur. Örneğin, çerçeve içerik türü uyuşmazlığı veya maksimum ileti boyutu aşıldı. Varsa, belirli bir protokol hatası hakkında daha fazla bilgi sağlar. Örneğin, QuotaExceededException hata nedeni MaxReceivedMessageSize değerini aştığında iç özel durumdur. Kurtarma: Gönderen ve alınan protokol ayarlarının eşleştiğinden emin olun. Bunu gerçekleştirmenin bir yolu, hizmet uç noktasının meta verilerini (ilkesi) yeniden içeri aktarmak ve oluşturulan bağlamayı kullanarak kanalı yeniden oluşturmaktır.
ServerTooBusyException Uzak uç nokta dinliyor ancak iletileri işlemeye hazır değil. Eğer varsa, dahili İstisna SOAP hatası veya aktarım düzeyindeki hata ayrıntılarını sağlar. Kurtarma: Bekleyin ve işlemi daha sonra yeniden deneyin.
TimeoutException İşlem zaman aşımı süresi içinde tamamlanamadı. Zaman aşımıyla ilgili ayrıntıları sağlayabilir. Bekleyin ve işlemi daha sonra yeniden deneyin.

Yeni bir özel durum türü yalnızca bu tür mevcut tüm özel durum türlerinden farklı belirli bir kurtarma stratejisine karşılık geliyorsa tanımlayın. Yeni bir özel durum türü tanımlarsanız, bu ya CommunicationException ya da bunun türetilmiş sınıflarından biri olmalıdır.

İstisna Mesajları

Özel durum iletileri, kullanıcının sorunu anlamasına ve çözmesine yardımcı olmak için yeterli bilgi sağlamaları için programı değil kullanıcıyı hedefler. İyi bir özel durum iletisinin üç temel bölümü şunlardır:

Ne oldu. Kullanıcının deneyimiyle ilgili terimleri kullanarak sorunun net bir açıklamasını sağlayın. Örneğin, hatalı bir özel durum iletisi "Geçersiz yapılandırma bölümü" olabilir. Bu, kullanıcının hangi yapılandırma bölümünün yanlış olduğunu ve neden yanlış olduğunu merak eder. Geliştirilmiş bir ileti "Geçersiz yapılandırma bölümü <customBinding>" olabilir. Daha uygun bir mesaj şu şekilde olabilir: "myTransport adlı aktarım, myBinding adlı bağına eklenemiyor çünkü bağı zaten myTransport adlı bir aktarım içeriyor". Bu, kullanıcının uygulamanın yapılandırma dosyasında kolayca tanımlayabildiği terimleri ve adları kullanan çok özel bir iletidir. Ancak, hala birkaç önemli bileşen eksik.

Hatanın önemi. Mesajda hatanın anlamı açıkça belirtilmezse, kullanıcı bunun önemli mi yoksa göz ardı edilebilir mi olduğunu merak eder. Genel olarak, iletiler hatanın anlamı veya önemiyle başlamalıdır. Önceki örneği geliştirmek için, "ServiceHost bir yapılandırma hatası nedeniyle Açılamadı: Bağlamada zaten myTransport adlı bir aktarım olduğundan myBinding adlı bağlamaya myTransport adlı aktarım eklenemiyor" iletisi olabilir.

Kullanıcının sorunu nasıl düzeltmesi gerektiği. İletinin en önemli kısmı, kullanıcının sorunu düzeltmesine yardımcı olmaktır. İleti, sorunu çözmek için nelerin denetlenmesi veya düzeltilmesi gerektiği hakkında bazı yönergeler veya ipuçları içermelidir. Örneğin, "ServiceHost bir yapılandırma hatası nedeniyle Açılamadı: Bağlamada zaten myTransport adlı bir aktarım olduğundan myBinding adlı bağlamaya myTransport adlı aktarım eklenemiyor. Lütfen bağlamada yalnızca bir taşıma olduğundan emin olun".

Hataları Bildirme

SOAP 1.1 ve SOAP 1.2 her ikisi de hatalar için belirli bir yapı tanımlar. İki özellik arasında bazı farklar vardır, ancak genel olarak Message ve MessageFault türleri hataları oluşturmak ve tüketmek için kullanılır.

SOAP 1.2 Hatası ve SOAP 1.1 Hatası
SOAP 1.2 Hatası (sol) ve SOAP 1.1 Hatası (sağ). SOAP 1.1'de yalnızca Fault öğesi ad alanı ile nitelenmiş.

SOAP, hata iletisini yalnızca bir hata öğesini (adı <env:Fault>olan bir öğe) öğesinin <env:Body>alt öğesi olarak içeren bir ileti olarak tanımlar. Hata öğesinin içeriği, şekil 1'de gösterildiği gibi SOAP 1.1 ile SOAP 1.2 arasında biraz farklılık gösterir. Ancak, System.ServiceModel.Channels.MessageFault sınıfı bu farkları tek bir nesne modelinde normalleştirir:

public abstract class MessageFault  
{  
    protected MessageFault();  
  
    public virtual string Actor { get; }  
    public virtual string Node { get; }  
    public static string DefaultAction { get; }  
    public abstract FaultCode Code { get; }  
    public abstract bool HasDetail { get; }  
    public abstract FaultReason Reason { get; }  
  
    public T GetDetail<T>();  
    public T GetDetail<T>( XmlObjectSerializer serializer);  
    public System.Xml.XmlDictionaryReader GetReaderAtDetailContents();  
  
    // other methods omitted  
}

Code özelliği, (veya env:Code SOAP 1.1'de) öğesine karşılık gelir faultCode ve hatanın türünü tanımlar. SOAP 1.2, için faultCode beş izin verilen değeri (örneğin, Gönderen ve Alıcı) tanımlar ve herhangi bir alt kod değeri içerebilen bir Subcode öğe tanımlar. (İzin verilebilen hata kodları listesi ve anlamları için SOAP 1.2 belirtimine bakın.) SOAP 1.1'in biraz farklı bir mekanizması vardır: Tamamen yenilerini tanımlayarak veya nokta gösterimini kullanarak genişletilebilen faultCodedört faultCodes değeri (örneğin, İstemci ve Sunucu) tanımlar. Örneğin, Client.Authentication.

Hataları programlamak için MessageFault kullandığınızda, FaultCode.Name ve FaultCode.Namespace, SOAP 1.2'nin env:Code veya SOAP 1.1'in faultCode adı ve ad alanına eşlenir. FaultCode.SubCode, SOAP 1.2 için env:Subcode ile eşlenir ve SOAP 1.1 için değeri null'dur.

Bir hatayı program aracılığıyla ayırt etmek ilginçse yeni hata alt kodları (veya SOAP 1.1 kullanıyorsanız yeni hata kodları) oluşturmanız gerekir. Bu, yeni bir özel durum türü oluşturmaya benzer. DOT gösterimini SOAP 1.1 hata kodlarıyla kullanmaktan kaçınmalısınız. (WS-I Temel Profili, hata kodu nokta gösteriminin kullanımını da caydırır.)

public class FaultCode  
{  
    public FaultCode(string name);  
    public FaultCode(string name, FaultCode subCode);  
    public FaultCode(string name, string ns);  
    public FaultCode(string name, string ns, FaultCode subCode);  
  
    public bool IsPredefinedFault { get; }  
    public bool IsReceiverFault { get; }  
    public bool IsSenderFault { get; }  
    public string Name { get; }  
    public string Namespace { get; }  
    public FaultCode SubCode { get; }  
  
//  methods omitted  
  
}

Reason özelliği, bir özel durumun iletisine benzer şekilde, hata koşulunun insan tarafından okunabilen açıklaması olan env:Reason (SOAP 1.1'de faultString) ile karşılık gelir. sınıfı FaultReason (ve SOAP env:Reason/faultString), genelleştirme açısından birden çok çeviriye sahip olmak için yerleşik desteğe sahiptir.

public class FaultReason  
{  
    public FaultReason(FaultReasonText translation);  
    public FaultReason(IEnumerable<FaultReasonText> translations);  
    public FaultReason(string text);  
  
    public SynchronizedReadOnlyCollection<FaultReasonText> Translations
    {
       get;
    }  
  
 }

Hata ayrıntı içeriği, TGetDetail ve <() gibi >GetReaderAtDetailContentsçeşitli yöntemler kullanılarak MessageFault'ta kullanıma sunulur. Hata detayı, hata hakkında ek bilgi taşıyan kapalı bir unsurdur. Hatayla birlikte taşımak istediğiniz rastgele yapılandırılmış bazı ayrıntılar varsa, bu yararlı olur.

Hata Oluşturma

Bu bölümde, kanalda veya kanal tarafından oluşturulan ileti özelliğinde algılanan bir hata koşuluna yanıt olarak hata oluşturma işlemi açıklanmaktadır. Tipik bir örnek, geçersiz veri içeren bir istek iletisine yanıt olarak hatanın geri gönderilmesidir.

Hata oluştururken, özel kanal hatayı doğrudan göndermemelidir, bunun yerine bir özel durum oluşturmalı ve yukarıdaki katmanın bu özel durumu bir hataya dönüştürip dönüştürmeyeceğine ve nasıl göndereceğine karar vermesine izin vermelidir. Bu dönüştürmeye yardımcı olmak için kanal, özel kanal tarafından oluşan özel durumu uygun hataya dönüştürebilen bir FaultConverter uygulama sağlamalıdır. FaultConverter şu şekilde tanımlanır:

public class FaultConverter  
{  
    public static FaultConverter GetDefaultFaultConverter(  
                                   MessageVersion version);  
    protected abstract bool OnTryCreateFaultMessage(  
                                   Exception exception,
                                   out Message message);  
    public bool TryCreateFaultMessage(  
                                   Exception exception,
                                   out Message message);  
}

Her özel hata oluşturan kanalın FaultConverter uygulaması ve GetProperty<FaultConverter> çağrısından döndürmesi gerekir. Özel OnTryCreateFaultMessage uygulamanın, özel durumu bir hataya dönüştürmesi veya iç kanalın FaultConverter işlevine devretmesi gerekir. Kanal bir taşıma aracıysa, özel durumu dönüştürmeli veya kodlayıcıya FaultConverter ya da WCF'de sağlanan varsayılan FaultConverter değerine atamalıdır. Varsayılan değer FaultConverter , WS-Addressing ve SOAP tarafından belirtilen hata iletilerine karşılık gelen hataları dönüştürür. Örnek bir OnTryCreateFaultMessage uygulama aşağıda verilmiştir.

public override bool OnTryCreateFaultMessage(Exception exception,
                                             out Message message)  
{  
    if (exception is ...)  
    {  
        message = ...;  
        return true;  
    }  
  
#if IMPLEMENTING_TRANSPORT_CHANNEL  
    FaultConverter encoderConverter =
                    this.encoder.GetProperty<FaultConverter>();  
    if ((encoderConverter != null) &&
        (encoderConverter.TryCreateFaultMessage(  
         exception, out message)))  
    {  
        return true;  
    }  
  
    FaultConverter defaultConverter =
                   FaultConverter.GetDefaultFaultConverter(  
                   this.channel.messageVersion);  
    return defaultConverter.TryCreateFaultMessage(  
                   exception,
                   out message);  
#else  
    FaultConverter inner =
                   this.innerChannel.GetProperty<FaultConverter>();  
    if (inner != null)  
    {  
        return inner.TryCreateFaultMessage(exception, out message);  
    }  
    else  
    {  
        message = null;  
        return false;  
    }  
#endif  
}

Bu düzenin bir etkisi, hata şartları için katmanlar arasında atılan istisnaların, ilgili hata oluşturucunun doğru hatayı oluşturması için yeterli bilgi içermesi gerektiğidir. Özel kanal yazarı olarak, bu tür özel durumlar yoksa farklı hata koşullarına karşılık gelen özel durum türleri tanımlayabilirsiniz. Kanal katmanlarından geçen istisnaların opak hata verileri yerine hata koşulunu iletmesi gerektiğini unutmayın.

Hata Kategorileri

Genellikle üç hata kategorisi vardır:

  1. Yığının tamamı boyunca yaygın olan hatalar. Bu hatalarla kanal yığınındaki herhangi bir katmanda karşılaşılabilir, örneğin InvalidCardinalityAddressingException.

  2. Yığındaki belirli bir katmanın üzerinde herhangi bir yerde karşılaşılabilecek hatalar, örneğin akışlı bir işlemle veya güvenlik rolleriyle ilgili bazı hatalar.

  3. Yığındaki tek bir katmana yönlendirilen hatalar, örneğin WS-RM sıra numarası hataları gibi hatalar.

Kategori 1. Hatalar genellikle WS-Addressing ve SOAP hatalarıdır. WCF tarafından sağlanan temel FaultConverter sınıf, WS-Addressing ve SOAP tarafından belirtilen hata iletilerine karşılık gelen hataları dönüştürür, böylece bu özel durumların dönüştürülmesini kendiniz işlemek zorunda olmazsınız.

Kategori 2. Bir katman, iletiye o katmanla ilgili ileti bilgilerini tamamen tüketmeyen bir özellik eklediğinde hatalar oluşur. Daha sonra daha yüksek bir katman ileti özelliğinden ileti bilgilerini daha fazla işlemesini istediğinde hatalar algılanabilir. Bu tür kanallar, daha yüksek katmanın GetProperty doğru hatayı geri göndermesini sağlamak için daha önce belirtileni uygulamalıdır. Bunun bir örneği TransactionMessageProperty'dir. Bu özellik, üst bilgideki tüm veriler tam olarak doğrulanmadan iletiye eklenir (bunun yapılması dağıtılmış işlem düzenleyicisine (DTC) başvurmayı içerebilir.

Kategori 3. Hatalar yalnızca işlemcideki tek bir katman tarafından oluşturulur ve gönderilir. Bu nedenle tüm özel durumlar katman içinde yer alır. Kanallar arasındaki tutarlılığı geliştirmek ve bakımı kolaylaştırmak için özel kanalınızın dahili hatalar için bile hata iletileri oluşturmak üzere daha önce belirtilen deseni kullanması gerekir.

Alınan Hataları Yorumlama

Bu bölüm, hata iletisi alınırken uygun özel durumu oluşturmaya yönelik rehberlik sağlar. Yığındaki her katmanda bir iletiyi işlemeye yönelik karar ağacı aşağıdaki gibidir:

  1. Katman iletinin geçersiz olduğunu düşünüyorsa, katman 'geçersiz ileti' işlemini yapmalıdır. Bu tür işlemler katmana özgüdür, ancak iletiyi bırakma, izleme veya hataya dönüştürülen özel durum oluşturma işlemlerini içerebilir. Örnekler arasında gerektiği gibi güvenli olmayan bir iletiyi alan güvenlik birimi veya hatalı bir sıra numarasına sahip bir ileti alan RM yer alır.

  2. Aksi takdirde, ileti özellikle katmana uygulanan bir hata iletisiyse ve ileti katmanın etkileşimi dışında anlamlı değilse, katman hata koşulunu işlemelidir. Bunun bir örneği, RM kanalının üstündeki katmanlar için anlamsız olan ve RM kanalında hata oluşturup bekleyen işlemleri yarıda kesmeyi gerektiren RM Dizisi Reddedildi hatasıdır.

  3. Aksi takdirde, ileti Request() veya Receive() içinden döndürülmelidir. Bu, katmanın hatayı tanıdığı durumları içerir, ancak hata yalnızca bir isteğin başarısız olduğunu gösterir ve bu durum kanalın hatalı olduğu ya da bekleyen işlemlerin kesileceği anlamına gelmez. Bu tür bir durumda kullanılabilirliği artırmak için, katman GetProperty<FaultConverter>'ü uygulamalı ve hatayı özel duruma dönüştürebilen bir türetilmiş FaultConverter sınıfı, OnTryCreateException'yi geçersiz kılarak döndürmelidir.

Aşağıdaki nesne modeli iletileri özel durumlara dönüştürmeyi destekler:

public class FaultConverter  
{  
    public static FaultConverter GetDefaultFaultConverter(  
                                  MessageVersion version);  
    protected abstract bool OnTryCreateException(  
                                 Message message,
                                 MessageFault fault,
                                 out Exception exception);  
    public bool TryCreateException(  
                                 Message message,
                                 MessageFault fault,
                                 out Exception exception);  
}

Bir kanal katmanı, hata iletilerini özel durumlara dönüştürmeyi desteklemek için uygulanabilir GetProperty<FaultConverter> . Bunu yapmak için, OnTryCreateException öğesini geçersiz kılın ve hata iletisini inceleyin. Tanındıysa dönüştürmeyi yapın, yoksa iç kanaldan bunu dönüştürmesini isteyin. Varsayılan SOAP/WS-Addressing FaultConverter'ı elde etmek için taşıma kanalları FaultConverter.GetDefaultFaultConverter'ye yetki vermelidir.

Tipik bir uygulama şuna benzer:

public override bool OnTryCreateException(  
                            Message message,
                            MessageFault fault,
                            out Exception exception)  
{  
    if (message.Action == "...")  
    {  
        exception = ...;  
        return true;  
    }  
    // OR  
    if ((fault.Code.Name == "...") && (fault.Code.Namespace == "..."))  
    {  
        exception = ...;  
        return true;  
    }  
  
    if (fault.IsMustUnderstand)  
    {  
        if (fault.WasHeaderNotUnderstood(  
                   message.Headers, "...", "..."))  
        {  
            exception = new ProtocolException(...);  
            return true;  
        }  
    }  
  
#if IMPLEMENTING_TRANSPORT_CHANNEL  
    FaultConverter encoderConverter =
              this.encoder.GetProperty<FaultConverter>();  
    if ((encoderConverter != null) &&
        (encoderConverter.TryCreateException(  
                              message, fault, out exception)))  
    {  
        return true;  
    }  
  
    FaultConverter defaultConverter =  
             FaultConverter.GetDefaultFaultConverter(  
                             this.channel.messageVersion);  
    return defaultConverter.TryCreateException(  
                             message, fault, out exception);  
#else  
    FaultConverter inner =
                    this.innerChannel.GetProperty<FaultConverter>();  
    if (inner != null)  
    {  
        return inner.TryCreateException(message, fault, out exception);  
    }  
    else  
    {  
        exception = null;  
        return false;  
    }  
#endif  
}

Farklı kurtarma senaryolarına sahip belirli hata koşulları için türetilmiş bir sınıfını ProtocolExceptiontanımlamayı göz önünde bulundurun.

"MustUnderstand" İşleme

SOAP, gerekli bir üst bilginin alıcı tarafından anlaşılmadığını belirten genel bir hata tanımlar. Bu arıza, mustUnderstand arızası olarak bilinir. WCF'de özel kanallar hiçbir zaman hata oluşturmaz mustUnderstand . Bunun yerine, WCF iletişim yığınının en üstünde bulunan WCF Dağıtıcısı, MustUnderstand=true olarak işaretlenmiş tüm üst bilgilerin temel yığın tarafından anlaşıldığını denetler. Herhangi biri anlaşılmadıysa, bu noktada bir mustUnderstand hata oluşturulur. (Kullanıcı bu mustUnderstand işlemeyi kapatmayı seçebilir ve uygulamanın tüm ileti üst bilgilerini almasını sağlayabilir. Bu durumda işleme gerçekleştirmek mustUnderstand uygulamanın sorumluluğundadır.) Oluşturulan hata, Anlaşılmayan MustUnderstand=true ile tüm üst bilgilerin adlarını içeren bir NotUnderstood üst bilgisi içerir.

Protokol kanalınız MustUnderstand=true ile özel bir üst bilgi gönderir ve bir mustUnderstand hata alırsa, bu hatanın gönderdiği üst bilgiden kaynaklanıp kaynaklandığını anlamalıdır. sınıfında bunun için yararlı olan iki üye MessageFault vardır:

public class MessageFault  
{  
    ...  
    public bool IsMustUnderstandFault { get; }  
    public static bool WasHeaderNotUnderstood(MessageHeaders headers,
        string name, string ns) { }  
    ...  
  
}

IsMustUnderstandFault, hata true hatası olduğunda mustUnderstand döndürür. Belirtilen ad ve ad alanına sahip üst bilgi hataya NotUnderstood üst bilgisi olarak eklenmişse WasHeaderNotUnderstood, true değerini döndürür. Aksi takdirde falsedeğerini döndürür.

Kanal MustUnderstand = true olarak işaretlenmiş bir üst bilgi yayarsa, bu katman Özel Durum Oluşturma API'sini de uygulamalı ve bu üst bilgiden kaynaklanan hataları daha önce açıklandığı gibi daha kullanışlı bir özel duruma dönüştürmelidir mustUnderstand .

İzleme

.NET Framework, üretim uygulamalarını veya zamansal sorunları tanılamada program yürütmesini izlemek için bir mekanizma sağlar; hata ayıklayıcıyı her zaman ekleyip kodu adım adım izlemek mümkün olmadığında bu mekanizma yardımcı olur. Bu mekanizmanın temel bileşenleri ad alanındadır System.Diagnostics ve şunlardan oluşur:

bileşenleri izleme

Özel Kanal Üzerinden İzleme

Özel kanallar, çalışan uygulamaya hata ayıklayıcı eklemek mümkün olmadığında sorunları tanılamaya yardımcı olmak için izleme iletileri yazmalıdır. Bu, iki üst düzeydeki görevi içerir: bir TraceSource örneği oluşturma ve izleri yazmak için yöntemlerini çağırma.

örneğini TraceSourceoluştururken, belirttiğiniz dize bu kaynağın adı olur. Bu ad, izleme kaynağını yapılandırmak (etkinleştirme/devre dışı bırakma/izleme düzeyini ayarlama) için kullanılır. Ayrıca izleme çıkışının kendisinde de görünür. Özel kanallar, izleme çıktısı okuyucularının izleme bilgilerinin nereden geldiğini anlamasına yardımcı olmak için benzersiz bir kaynak adı kullanmalıdır. İzleme kaynağının adı olarak bilgileri yazan derlemenin adını kullanmak yaygın bir uygulamadır. Örneğin WCF, System.ServiceModel derlemesinden yazılan bilgiler için izleme kaynağı olarak System.ServiceModel kullanır.

Bir izleme kaynağınız olduğunda, izleme dinleyicilerine izleme girdileri yazmak için TraceData, TraceEvent, veya TraceInformation yöntemlerini çağırırsınız. Yazdığınız her izleme girdisi için, olay türünü içinde TraceEventTypetanımlanan olay türlerinden biri olarak sınıflandırmanız gerekir. Bu sınıflandırma ve yapılandırmadaki izleme düzeyi ayarı, izleme girişinin dinleyiciye gönderilip gönderilmeyeceğini belirler. Örneğin, yapılandırmadaki izleme düzeyi Warning olarak ayarlandığında Warning, Error ve Critical izleme girdilerinin yazılmasına izin verir, ancak Bilgi ve Ayrıntılı girdileri engeller. Aşağıda, izleme kaynağının örneğini oluşturma ve Bilgi düzeyinde bir girdi yazma örneği verilmiştir:

using System.Diagnostics;  
//...  
TraceSource udpSource = new TraceSource("Microsoft.Samples.Udp");  
//...  
udpsource.TraceInformation("UdpInputChannel received a message");

Önemli

İzleme çıktı okuyucularının çıkışın nereden geldiğini anlamasına yardımcı olmak için özel kanalınıza özel bir izleme kaynağı adı belirtmeniz kesinlikle önerilir.

İzleme Görüntüleyicisi ile entegrasyon

Kanalınız tarafından oluşturulan izlemeler, izleme dinleyicisi olarak kullanıldığında System.Diagnostics.XmlWriterTraceListener tarafından okunabilir bir formatta çıktı olarak verilebilir. Bu, kanal geliştiricisi olarak yapmanız gereken bir şey değildir. Bunun yerine, uygulamanın yapılandırma dosyasında bu izleme dinleyicisini yapılandırması gereken uygulama kullanıcısı (veya uygulamada sorun gideren kişi). Örneğin, aşağıdaki yapılandırma hem System.ServiceModel hem de Microsoft.Samples.Udp adlı TraceEventsFile.e2e dosyasına izleme bilgilerini çıkarmaktadır.

<configuration>  
  <system.diagnostics>  
    <sources>  
      <!-- configure System.ServiceModel trace source -->  
      <source name="System.ServiceModel" switchValue="Verbose"
              propagateActivity="true">  
        <listeners>  
          <add name="e2e" />  
        </listeners>  
      </source>  
      <!-- configure Microsoft.Samples.Udp trace source -->  
      <source name="Microsoft.Samples.Udp" switchValue="Verbose" >  
        <listeners>  
          <add name="e2e" />  
        </listeners>  
      </source>  
    </sources>  
    <!--   
    Define a shared trace listener that outputs to TraceFile.e2e  
    The listener name is e2e   
    -->  
    <sharedListeners>  
      <add name="e2e" type="System.Diagnostics.XmlWriterTraceListener"  
        initializeData=".\TraceFile.e2e"/>  
    </sharedListeners>  
    <trace autoflush="true" />  
  </system.diagnostics>  
</configuration>

Yapılandırılmış Verileri İzleme

System.Diagnostics.TraceSource, izleme girişine dahil edilecek bir veya daha fazla nesneyi kabul eden bir TraceData yöntemine sahiptir. Genel olarak, Object.ToString yöntemi her nesnede çağrılır ve sonuçta elde edilen dize izleme girişinin bir parçası olarak yazılır. izlemeleri çıktı almak için System.Diagnostics.XmlWriterTraceListener kullanıldığında, veri nesnesi olarak System.Xml.XPath.IXPathNavigable öğesini TraceData öğesine geçirebilirsiniz. Sonuçta elde edilen izleme girdisi, System.Xml.XPath.XPathNavigator ile sağlanan XML'yi içerir. XML uygulama verilerini içeren örnek bir giriş aşağıda verilmiştir:

<E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent">  
  <System xmlns="...">  
    <EventID>12</EventID>  
    <Type>3</Type>  
    <SubType Name="Information">0</SubType>  
    <Level>8</Level>  
    <TimeCreated SystemTime="2006-01-13T22:58:03.0654832Z" />  
    <Source Name="Microsoft.ServiceModel.Samples.Udp" />  
    <Correlation ActivityID="{00000000-0000-0000-0000-000000000000}" />  
    <Execution  ProcessName="UdpTestConsole"
                ProcessID="3348" ThreadID="4" />  
    <Channel />  
    <Computer>COMPUTER-LT01</Computer>  
  </System>  
<!-- XML application data -->  
  <ApplicationData>  
  <TraceData>  
   <DataItem>  
   <TraceRecord
     Severity="Information"  
     xmlns="…">  
        <TraceIdentifier>some trace id</TraceIdentifier>  
        <Description>EndReceive called</Description>  
        <AppDomain>UdpTestConsole.exe</AppDomain>  
        <Source>UdpInputChannel</Source>  
      </TraceRecord>  
    </DataItem>  
  </TraceData>  
  </ApplicationData>  
</E2ETraceEvent>

WCF izleme görüntüleyicisi daha önce gösterilen öğenin şemasını TraceRecord anlar ve alt öğelerinden verileri ayıklar ve tablo biçiminde görüntüler. Kanalınız, Svctraceviewer.exe kullanıcıların verileri okumasına yardımcı olmak için yapılandırılmış uygulama verilerini izlerken bu şemayı kullanmalıdır.

  • Last updated on