Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik-Blog

Windows.Forms: Was man bei ShowDialog beachten muss


Man kommt meiner Ansicht nach nicht von selbst drauf, und in der Dokumentation wird es (meiner Ansicht nach) auch nicht erwähnt: Wenn man eine Form statt mit Show() [also nicht-modal] mit ShowDialog() [also modal] anzeigt, dann ist man selbst auch dafür verantwortlich, Dispose() für die Form aufzurufen, wenn der Dialog wieder geschlossen wurde. Tut man das nicht, dann hat man potenzielle Speicherlecks rsp. Speicher, der vom Garbage Collector nicht freigegeben werden kann.

Einfach Regel: Bei ShowDialog() hinterher immer auch Dispose() aufrufen, oder das ganze in ein using() verpacken.

 


Der dotTrace 2 Profiler von JetBrains


Seit Jahren suche ich einen Profiler, mit dem es tatsächliche möglich ist, unsere Anwendungen zu untersuchen. Das Problem: Bei allen die ich mir in den letzten Jahren angesehen habe, gab es Ärger. Entweder, das Programm wurde im Profiler derartig langsam, das man schlicht nicht mehr damit arbeiten konnte. Andere Profiler stürzten schon beim laden des Programms ab, oder versagten sonst wie Ihren Dienst. Mit einem Wort: Unsere Anwendungen waren einfach zu groß, als das man sie vernünftig mit einem Profiler unter die Lupe nehmen konnte.

 

Ende letzten Jahres bin ich zufällig über den dotTrace Profiler von JetBrains gestolpert – und war begeistert. Nun arbeite ich seit einigen Wochen regelmäßig damit, und an meiner ursprünglichen Meinung hat sich nichts geändert. Wer einen guten Profiler für .NET Anwendungen sucht, der ist mit dotTrace gut bedient.

 

Der Profiler kommt mit dem .NET Framework 1.1 und 2.0 klar und kann sowohl fürs profilen der Performance, als auch fürs profilen der Speicherverwendung benutzt werden. Das Programm läuft mit normalen Windows Clients, mit ASP.NET Anwendungen und mit Windows Services. (Ich habe bisher nur den Performance und Speicherteil für Windows Clients benutzt.)

 

Das Programm ist extrem einfach zu bedienen: Ich bin damit sofort klargekommen, ohne auch nur eine Zeile Dokumentation zu lesen. Das Performance-Profiling kann man zu einem beliebigen Zeitpunkt starten und beenden: Man lädt also das zu untersuchende Programm in den Profiler, und startet zu einem beliebigen Zeitpunkt die Traces. Zu einem späteren Zeitpunkt hält man die Traces wieder an, und erhält dann einen Snapshot. Dabei kann man pro Programmlauf auch mehrere Snapshots machen, und das Tracing auf Wunsch auch schon beim Programmstart einschalten. Letzteres ist praktisch, wenn man Performance-Probleme beim laden der Anwendung hat.

 

Als Ergebnis bekommt man in einem Snapshot einen Baum, in dem die Zeiten und prozentualen Anteile pro aufgerufener Funktion enthalten sind – und zwar getrennt nach Threads. Zusätzliche gibt es diverse Möglichen die Anzeige zu verbessern – so kann man zum Beispiel Funktionen aus bestimmten Namespaces ausfiltern.

 

Alles in allem ist der dotTrace Profiler für mich ein wirklich gelungenes Werkzeug: Ich kann jedermann nur empfehlen, die eigene Anwendung zumindest einmal durch die Testversion von dotTrace 2 zu jagen.


Ein bisschen Reklame


In der aktuellen dotnetpro gibts einen kleinen Artikel von mir. Thema: Nutzerverwaltung für Websites mit .Net 2. Zum Artikel dazu gibts auch den (C#) Quellcode für eine Userverwaltung, die man selbst einsetzen kann.


Mein kleiner Kampf gegen Spam


Als eMail-Server benutzen wir den MDaemon von Alt-N. Ich bin mit dem Programm sehr zufrieden, und habe erst heute ein neues Update installiert. Der MDaemon hat diverse eingebaute Mechanismen fürs filtern von Viren, Spam- und Phishing-Mails. Eines davon ist die "Spam-Trap". Die Idee dabei ist relativ einfach: Man richtet eine (oder mehrere) eMail-Adressen ein, die ausdrücklich nicht dafür gedacht sind, verwendet zu werden: Es gibt also keine Person und auch keinen Dienst, der zu dieser Adresse gehört.

Dann publiziert man diese Adresse: Zum Beispiel, indem man See auf einer öffentlichen Webseite oder in einer Newsgroup postet. Spammer sammeln an solchen Stellen Adressen ein - jede Mail die an eine solche Adresse geschickt wird, ist also mit absoluter Sicherheit Spam. Geht also eine solche Mail ein, kann man sie zum Beispiel dafür benutzen, den Anti-Spam Engine zu trainieren. Außerdem kann man den absendenden Host zumindest für eine Zeitlang blockieren, also keine weiteren Kontaktaufnahmen mehr zulassen (bzw: in extrem verlangsamter Form zulassen.)

Feine Sache - und ich habe dieses Feature auch schon eine ganze Weile genutzt. Heute ist mir aber eine Nette Idee gekommen: Die Spammer versenden Ihre Mails ja ohnehin an mehr oder minder willkürliche Adressen. Statt also selbst eine oder mehrere Spamtrap-Adressen zu publizieren - warum nicht einach die "falschen" Adressen einsammeln, die die Spammer sowieso verwenden. Daraus resultierte das Programm SpamTrapHarvester: Man kann damit relativ einfach SpamTrap-Adressen einsammeln, indem man mit dem Programm die SMTP-(in) Logfiles des MDaemon auswertet.

spamtrap_harvester.jpg

Wer mag, kann sich das Programm hier runterladen. Im Zip-File befinden sich zwei weitere Zip-Dateien: Die eine enthält den Quellcode (C#, .Net 2.0, VS 2005), die andere das .EXE-File (braucht .Net 2.0).

So ist die Sache zu bedienen:

Nach dem Programmstart bekommt man ein Fenster. Links ist eine leere Listbox, rechts ist eine Textbox. In der Textbox gibt man nun die Namen der Domains ein, die man auf seinem MDaemon-Server betreibt. (Das Programm filtert nur Mail-Adressen heraus, die zu den angegebenen Domains gehören.). Dann lädt man sich eine oder mehrere der SMTP-(in) Logfiles von MDaemon herunter. Die kann man dann hintereinander per Drag&Drop auf das Programmfenster ziehen: Das Programm zeigt dann eine Liste aller Mail-Adressen an, an die es einen Zustellversuch gab. Die Liste ist nach Häufigkeit der Zustellversuche sortieren, die Anzahl der Versuche wird mit ausgegeben.

Mit dieser Liste ausgestattet ist es dann extrem einfach, den MDaemon Pool an SpamTrap - Adressen aufzufüllen.

spamtrap_harvester.zip (27.04 KB)




Baustatik Demoversion ausprobieren »