Nie jestem fanem nowego dodatku do Visual Studio 2010 zwanego IntelliTrace, jakoś do tej pory nie mogłem znaleźć dla niego zastosowania, dodatkowo działał on jedynie dla aplikacji 32 bitowych.

Wszystko się zmieniło kiedy wyszedł SP1 do Visual Studio. Teraz IntelliTrace nie tylko wspiera architekturę 64 bitową, ale także debugowanie Farm w SharePoint.

Postanowiłem to przetestować na bardzo popularnym błędzie FileNotFoundException w SharePoint i sprawdzić czy jestem wstanie uzyskać szybciej i sprawniej informacje o błędzie niż ostatni mój proces który dokładnie prześledził wszystko to co się dzieje i dlaczego dostajemy FileNotFoundException (ale o tym kiedy indziej). Mnie zajęło to około 2h (chodzi o zrozumienie a nie znalezienie przyczyny – linii kodu gdzie), z wykorzystaniem IntelliTrace – 15 minut. Muszę powiedzieć, że jestem pod wrażeniem. Kod testowy:

using System;
using Microsoft.SharePoint;

namespace ServerObjectModel
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Program p = new Program();
            p.SitePortalNameSom();
            Console.ReadLine();
        }

        public const string SiteUrl = "http://www.wssdemo.com";
        
        public void SitePortalNameSom()
        {
            using(SPSite site = new SPSite(SiteUrl))
            {
                Console.WriteLine(site.PortalName);
            }
        }
    }
}

I screen pokazujący dlaczego błąd został zwrócony – ogólnie procedura sprawdza czy istnieje wpis host dla podanego url w bazie danych i jeżeli tak to zwraca ID obiektu strony (dla maniaków site collection). Oczywiście takie strony nie posiadam, więc stąd wyjątek w tym konkretnym przypadku:

IntelliTrace

Mogę więc zrozumieć do czego to można wykorzystać. Tak jak dla swojego kodu raczej bym nie włączył IntelliTrace, tak jak już występuje problem z aplikacją lub biblioteką której autorem nie jestem informacje w IntelliTrace mogą bardzo szybko podać przyczynę wystąpienia błędu. Jeżeli IntelliTrace nie jest wstanie podać nam dlaczego wyjątek/problem wystąpił nic nie tracimy – w końcu do tej pory robiliśmy to ręcznie :) jednak tym razem mamy wsparcie.

Jestem ciekaw jak to się rozwinie a wraz z opcją Resharpera z dekompilacją kodu, może to być naprawdę niesamowite narzędzie. Dla przykładu, nie opuszczając Visual Studio, dokładnie prześledziłem kod aż do momentu wywołania Stored Procedure z odpowiednim parametrem:

Callstack

Step1

Step2

Step3

Screeny podane jako przykłady: 1: CallStack pokazujący metody; 2: Inicjalizacja obiektu SPSite – wywołuje metodę w screen 4; 3: próba pobrania informacji na temat ID strony wykonana 3 linijki wyżej niż zaznaczony tekst w screen 4; 4: wyjątek zwrócony użytkownikowi, koniec wykonywania programu. To nie są wszystkie metody, ale pokazuje to mniej więcej jak łatwo jest teraz dostać informację która nas interesuje.

Niestety proces ten wciąż jest trochę „manualny”, to znaczy, bezpośrednio z Call Stack nie mogę przejść do kodu, zaś jestem wstanie wykorzystując Resharpera przejść do ostatniej publicznej metody

(CTRL+T typ.metoda) a następnie F12 aż do źródła. Trzeba jednak pamiętać iż Resharper jest w wersji EAP 6 więc pewne rzeczy nie koniecznie muszą płynnie chodzić.

A czy wy korzystaliście już z IntelliTrace? Jeżeli tak to gdzie i czy wam pomógł? Szukam innych scenariuszy w których to narzędzie może być przydatne.

1 KOMENTARZ

  1. Ciekawy post. Ja Intelitrace używam, jak już moje "stare" metody znalezienia co-sie-stało-sie nie pomagaja – często właśnie wtedy IT oszczędza mi wachlowania po stack trace.

Comments are closed.