Ibland så måste man felsöka i program. felsöker man i Visual Studio på sin utvecklingsdator så kör man oftast med breakpoints i kombination med att man skriver ut debuggdata till output-fönstret. Jag har sett att loggning ute hos kund är en sån sak som de flesta programmerare bygger egna lösningar för, loggning mot fil, Eventlog osv som står och fyller upp loggar 99% till ingen nytta, även om man ser flertalet som i alla fall lägger in flaggor för om det ska vara på eller avslaget.
Något vi använder oss av i stort sett dagligen (i alla fall jag) är Debug.Print() vilket skriver ut debugdata till Outputfönstret (eller motsvarande konfigurerbar eventlyssnare) i Visual Studio.
Låt oss säga att vi har ett program där man har en knapp och en listbox:
På olika ställen i programkoden så lägger vi in debug.print () som talar om vad som sker:
- Public Class Form1
- Private Sub Form1_Activated(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Activated
- Debug.Print("Activated")
- End Sub
-
- Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
- Debug.Print("Loading")
- End Sub
-
-
- Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
- Debug.Print("Button_click Start")
- '---some code
- For p As Integer = 0 To 10
- ListBox1.Items.Add(p.ToString)
- Debug.Print("Adding Listboxitems:" & p.ToString)
- Next
- Debug.Print("Button_click End")
- End Sub
- End Class
När vi kör programmet och klickar på knappen så får vi i Output-fönstret se att allt går rätt till:
DebugView
Om du har problem på en kunddator så vill du inte installera hela visual studio för att få fram den här informationen och det behöver du inte heller, ladda bara ner programmet DebugView från Sysinternals så hookar den in och lyssnar på debug-event från alla applikationer.
På det sättet kan du köra programmet live hos kund och ändå se debug-datat, självklart så krävs det att du har en version av programmet som är kompilerat i Debug-mode. Kunden kör ju antagligen applikationen i Release-mode så du får se till att kompilera programmet i debugmode och ta med och köra på targetmaskinen.
Ovanstående debuggdata ser ut så här när jag kör programmet på samma sätt med Debugview:
Man kan välja att logga till fil, vilket är väldigt smidigt om man vill logga programmet under en hel dag medan kunden använder det. Man kan även logga via nätverket, så du kan köra DebugView på en klient och sen starta DebugView på en server och connecta till klienten och få upp debuggdatat där. Du kan skapa include och exclude-filter som highlightar vissa meddelanden eller filtrerar bort vissa meddelanden osv.
Detta är ett mycket värdefullt program när man vill samla debuggdata ute hos kund.
Men Releasemode då???
Av prestandaskäl så tas alla debug.print-anrop bort när man kompilerar programmet i releasemode. Vill man ändå kunna få sådan information via DebugView när man har programmet i releasemode så är det bara att ändra debug.Print() till Trace.WriteLine(), då kommer du att få dessa meddelanden oavsett om det är i debug eller releaseläge på programmet.
Av prestandaskäl kan det vara bra att inte peppra programmet med tusentals Trace.WriteLine, men har man problem med ett program så kan det verkligen vara värt att lägga in dessa rader på ställen man misstänker att det finns problem.
Det är ju smidigt att bara starta DebugView, köra programmet och i DebugView få ut interna data som programmet använder sig av för att se varför man får t.ex. diffar eller error.
Over and out / Stefan