Nützliches Tool für die WinDbg Erweiterung SOS: SOS Assist

Kürzlich bin ich auf das Tool SOS Assist aufmerksam geworden, die eine grafische Oberfläche zu WinDbg SOS anbietet:

SOS Assist

Leider wird das Tool (laut ChangeLog) seit 2006 nicht mehr gepflegt. Im praktischen Einsatz konnte es zwar durch die zahlreichen Infofenster punkten, doch in Punkto Stabilität sind noch einige Defizite zu spüren.

Bisher hatte ich mir immer mit ClrDump (http://www.debuginfo.com/tools/clrdump.html) beholfen, welches mir CrashDumps zur Analyse erstellte. Diese konnte ich dann im WinDbg laden und mittels SOS-Erweiterung analysieren.

Screenshots: http://old.thinktecture.com/SOSAssist/Screenshots.htm

Download: http://old.thinktecture.com/SOSAssist/default.html

Übrigens: Zum Thema CrashDump-Analyse zum Aufspüren von Sicherheitslücken hat auch das MSDN-Magazin einen Artikel veröffentlicht: http://msdn.microsoft.com/msdnmag/issues/07/11/ExploitingCrashes/default.aspx?loc=de

Sehr lesenswert!

Kostenloses Trainingsmaterial zu SharePoint 2007

Heute bin ich zufällig über das Blog von Neil Thompson gestoßen. Dort hat er unter dem Titel „Training Material Roadmap“ zahlreiche Trainingsmaterialien zur SharePoint 2007 als Word-Dateien verlinkt.

Zusätzlich gibt es noch Links zu Webcasts und MP3-Podcasts zu dem Thema. Alles frei herunterladbar 🙂

Hier der Link: http://blogs.msdn.com/neilth/pages/office-sharepoint-server-2007-training-material-roadmap.aspx

Ermitteln von Assembly-Dependencies – oder „Wie werde ich diese verd*** FileNotFound-Exception los?“

Ich ärgere mich momentan mit einem Projekt herum, welches ich nicht problemlos deployen kann. Ich verwende dazu Interop-Technologien aus C++/CLI.

Leider läßt sich das Programm nicht auf einem frisch installierten Zielrechner ausführen. Irgendeine Abhängigkeit muss es noch geben, die bei Installer nicht berücksichtigt wurde.

Aus diesem Grund habe ich mich etwas mit Assembly-Abhängigkeiten (bzw. Assembly-Dependencies) beschäftigen müssen. Dabei bin ich über ein nützliches Tool auf CodeProject gestoßen: Assemlby Dependencies von Natty Gur.

Weiterlesen

.NET Applikationen über das Netzwerk starten

Den größten Teil meiner Arbeit beschäftige ich mich mit der Interoperabilität von .NET-Anwendungen mit unmanaged C++-Code (no COM). Dabei kommt es immer häufiger vor, dass Anwendungen vom Netz gestartet werden sollen.

Die CAS (Code Access Security) verhindert dies, indem sie der Anwendung die Rechte für LocalIntranet-Zone zuweist. Wenn man trotzdem die Anwendung vom Netzlaufwerk aus starten möchte, muss man die CAS bemühen, der zu startenden Applikation volle Rechte zu geben (oder zumindest die benötigten Permissions).

Dies geschiet mithilfe des Tools caspol.exe, welches bei jedem .NET Framework mitgeliefert wird. Es befindet sich im Standard-Installationsverzeichnis der jeweiligen .NET Framework-Version:

{Windows-Verzeichnis}Microsoft.NET{.NET-Version}caspol.exe

Nun legen wir eine neue Codegruppe namens „FullTrustFromNetworkShare“ an:

caspol -machine -addgroup All_Code -url \serverpath* FullTrust -n FullTrustFromNetworkShare

In der grafischen .NET Framework 2.0 Configuration sieht das nun wiefolgt aus:

dotnet_20_config_caspol.png

Natürlich sollte man bei solchen Aktionen bedenken, dass man die Code-Zugriffssicherheit für das Verzeichnis quasi aushebelt und Schädlingen, die über das Verzeichnis gestartet werden, alle Rechte gibt 😐

Mehr Infos dazu gibts auf der MSDN-Seite zum CASPOL-Utility:  http://msdn.microsoft.com/library/DEU/cptools/html/cpgrfCodeAccessSecurityPolicyUtilityCaspolexe.asp

Microsoft gibt mit VS2008 den Quellcode für .NET-Klassenbibliotheken frei

Wie ich heute erfahren habe, gibt Microsoft den Quellcode für verschiedene Klassenbibliotheken frei. Bisher war es ja nicht möglich, in die Klassenbibliotheken rein zu debuggen. Das habe ich im Gegensatz zu Java schon sehr vermisst.

Welche Bibliotheken werden dabei sein?

  • Base Class Libraries (mscorlib.dll)
  • ASP.NET (System.Web.dll)
  • Windows Forms (System.Drawing.DLL & System. Windows.Forms.dll)
  • ADO.NET (System.Data.DLL)
  • XML (System.Xml.DLL)
  • WPF (System.Windows.DLL)

Leider wird der Code unter der Microsoft Reference License veröffentlicht. Heißt im Klartext: Gucken, aber nicht anfassen.

Wenn man einen Fehler im .NET Framework entdeckt, dann darf man sich freuen ihn gefunden zu haben – und wenn man ihn meldet, dann wird er  (vielleicht) bald gefixt. (frei nach dem Motto: Wer einen Fehler findet, darf ihn behalten).

Debuggen von Problemen beim Laden von Assemblies

Ich entwickle beruflich u.a. Assemblies mit C++/CLI, die eine Interop-Brücke zwischen den vorhandenen C++-Bibliotheken und unseren .NET-Anwendungen (in C#) darstellen. Hin und wieder (beispielsweise wenn sich eine native C++-DLL geändert hat), bekomme ich Loader Exceptions in Form von System.IO.FileNotFoundException.

Bisher habe ich mir immer Hilfe bei dem Assembly Binding Log Viewer geholt, der mich angezeigt hat, welche Assemblies Probleme machen. Der Assembly Binding Fusion Log Viewer liegt üblicherweise im SDK-Ordner vom .NET Framework (in meinem Fall C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bin) und heißt FUSLOGVW.exe.

Assembly Binding Log Viewer

Danach habe ich mir die Assemblies angeschaut, die Probleme machen und habe somit schnell die fehlenden Abhängigkeiten gefunden.

Weiter Tipps in dieser Richtung habe ich im Blog von Suzsanne Cook gefunden, wie man Probleme beim Laden von Assemblies in den Griff bekommt:

http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx

Managed-Unmanaged InterOp: unmanaged DLLs in Assemblies speichern

Ich habe heute im Blog von Ralf Westphal einen etwas älteren, aber dennoch sehr interessanten Artikel gelesen, der sich damit beschäftigt wie man native C/C++-DLLs in Assemblies unterbringen kann.

Dabei wird zur Compile-Zeit einfach die unmanaged DLL als Ressource in die .NET Assembly eingebettet und dann zur Laufzeit wieder extrahiert und im Dateisystem gespeichert.

Ein einfacher, aber dennoch cooler Trick, der das Deployment (vorzugsweise XCOPY-Deployment) für Interop-Applikationen vereinfacht.

Eine ähnliche Vorgehensweise beschreibt auch Suzanne Cook in ihrem Blog: Sie schlägt vor, die unmanaged DLL als Teil einer Multi-File-Assembly abzulegen. Somit nimmt man den Vorteil der Versionierung von .NET Assemblies mit.

Hier nochmal die Links zu den beiden Beiträgen:

Ralf Westphals Blogeintrag „Single Assembly Deployment of Managed and Unmanaged Code“:
http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx

Suzanne Cock’s Blogeintrag „Versioning/Deploying Unmanaged Files“:
http://blogs.msdn.com/suzcook/archive/2004/10/28/249280.aspx

Vortrag zu JetBrains „ReSharper 3.0“ bei der .NET Developers Group Stuttgart

Am Mittwoch habe ich einen Vortrag über die Features von JetBrains „ReSharper 3.0“ bei der .NET Developers Group Stuttgart gehalten. Das erste Feedback dazu war sehr positiv.

Die konstruktiven Vorschläge und Anfragen habe ich natürlich an JetBrains weitergeleitet.

Hier können nun die Vortragsfolien und Beispielprogramme heruntergeladen werden:

Vortragsfolien (als PDF-Datei):
http://www.minibrain.de/schulung/ReSharper3/Vorstellung_ReSharper_3.pdf

Code der Präsentation (mit Kommentaren):
http://www.minibrain.de/schulung/ReSharper3/Vorstellung_ReSharper_3_CodeDemos.zip

Ready To Take Off: Launch-Veranstaltung der 2008er Produkte von Microsoft

Als ich heute beim Herumstöbern in Blogs auf das neue Event „ready.to.take.off“ von Microsoft aufmerksam wurde, habe ich mich sofort angemeldet. Zum Launchevent von Visual Studio 2005, SQL-Server 2005, BizTalk-Server 2006 hatte ich Glück noch eine Karte zu reservieren. Das Event war sehr schnell ausverkauft.

Dieses Mal gibts neben Visual Studio 2008 auch den SQL-Server 2008, sowie den Windows Server 2008 und den Team Foundation Server als Give-Away!

Der Preis von 500,-€ ohne MwSt. ist für mich privat etwas happig, aber man bekommt auch Software dafür, die einen weitaus größeren Wert hat.

Hier ist der Link zur Anmeldung:

http://www.microsoft.com/germany/aktionen/ready-for-take-off/