VS 2010 Remote Debug

[rpm8200]

Ich nutze derzeit VS2008, VS2010 steht in den Startlöchern.

Da ich keine TeamLizenz habe, kann ich in meinem VS2008 derzeit remote debugging (eigentlich) nicht nutzen. Ein Freiberufler an unserer Firma dagegen hat die TeamLizenz, wollte remote debuggen und musste feststellen, dass es nicht möglich ist, sobald sich der Zielrechner nicht in der selben Domäne befindet (oder wenigstens einmal dort registriert war) wie der PC des Entwicklers (es gibt dazu zahlreiche threads). Darüber hinaus gibt es zahlreiche "Gängeleien", so muss z.B. auf Ziel- und Entwicklungs- PC ein Account des selben Benutzers angelegt sein mit identischem Passwort (ein Unding eigentlich, aber immerhin noch machbar). Wie gesagt, für uns ist das technisch nicht verwendbar, was natürlich zu erheblichen Unannehmlichkeiten führt (Express Editions auf ausgelieferten Maschinen um dort debuggen zu können...!!!).

Dieser Umstand ist MS nicht unbekannt und m.W. gibt es dazu keine Lösung (alles was vorgeschlagen wurde und irgendjemanden auf diesem Erdball bei der Lösung dieses Problems weiter gebracht hat, haben wir versucht).

Daher meine Frage: Weiss irgendwer, ab welcher neuen Version der Remote Debugger mit dabei ist und hat vllt. schon jmd. den RC ausgetestet und dieses Feature benutzt? Ist es vom Look&Feel her derselbe Mist wie in 2008?

Wenn einer was weiss... bitte posten!

[Ectoplasma]

Ich weiss nicht, was du genau suchst oder brauchst, aber Remote Debugging würde ich so betreiben:

Remote Debugging using VMWare (http://www.catch22.net/tuts/vmware)

Mit dem VMWare Converter kannst du aus jedem Zielsystem, eine virtuelle Maschine machen. Das habe ich selber schon gemacht und es klappt hervorragend.

[Gast]

1.) Ein VMWare hilft nur, wenn das ausgelieferte System nicht auf diverse Hardware angewiesen ist z.B. zusätzliche PCI Karten und es sich auch um eine Standalone Anwendung handelt ohne Anbindung ans Netzwerk oder sonstige Hardware.

2.) Es ist schon klar, dass man irgendeine Authentifizierung braucht, um Remote irgendetwas zu tun d.h. man muss in der selben Domäne sein. Einfach fröhlich zusätzliche Admin Accounts mit nicht änderbarem Passwort anzulegen ist eine Praxis, die man sich gar nicht erst anfangen sollte.

3.) Ich bevorzuge die Lösung des Express Editions beim Kunden, wenn wir einen PC liefern oder der PC nur für unsere Anlage verwendet wird. Da wird immer der aktuelle Source auf den Rechner kopiert, compiliert und dann eingspielt. So kann man vor Ort beim Kunden direkt an der Anlage nach Fehlern suchen, was in meinem Fall zu Hause nur sehr schwer notwendig ist. Zusätzlich kann man vor Ort jederzeit eine Softwareänderung durchführen, wenn nötig. Nachdem ich fertig bin, nehme ich mir den Source Code per USB Stick oder Platte mit und kann es daheim wieder auf den Server spielen bzw. auf meinen Entwicklungsrechner (Versionierung und History am Server, aktuelle Version auf meinem PC).
Das funktioniert bei Individualsoftware ganz gut. Problematisch wird es nur, wenn man Software hat, die an mehrere Kunden geht. Da muss man schauen, dass man eine geschlossene Versionierung hat und nicht jeder Kunde seine eigene.

[rpm8200]

Hoioi. Also erst mal Danke für die Beteiligung an diesem trockenen Thema.

Ectoplasma: Also VMWare hilft mir nicht weiter. Wie Gast schon darstellt, geht das nur, wenn man keine zusätzliche Hardware hat. Wir bauen Maschinen für die Halbleiterindustrie (hochgenaue Positionierung, Markierung, bonden, Bidlverarbeitung... dergleichen Gedöns), das sind jede Menge Hardwarekomponenten, die eben das Debuggen beim Kunden vor Ort notwendig machen (weil in der Simulation im Büro z.B. alles locker-flockig läuft aber beim Kunden kackt die Software ab). Die Maschinen sind dann auch noch im Firmennetzwerk des Herstellers (z.B. Infineon oder Osram) und da gibts dann natürlich noch zusätzliche Effekte, die das Debuggen remote auf einer Maschine notwendig machen. Um im Büro zu testen brauche ich keine VMWare. Zuhause habe ich etwas mit VirtualBox experimentiert, zuhause finde ich das auch ganz ok.

Gast: Jo. Wie ich in meinem ersten Post versucht habe zu sagen ist es ja genau das Problem, dass um Remote Debugging nutzen zu können im www dererlei Vorschläge gemacht werden mit gleichen Accounts. Das man das "normalerweise" nicht machen will (und auch nicht sollte) versteht sich ja von selbst (und btw: selbstverständlich können wir der Domain unseres Kunden NICHT beitreten (war bsplw. unter VS 6.0 auch überhaupt nicht notwendig) und das wird wohl in unserem Tätigkeitsgebiet kein Kunde jemals erlauben, es ist schon schwer, einen dauerhaft gültigen Zugangsausweis für die Produktionslinie zu bekommen...!). In unserer Verzweiflung hätten wir es dennoch getan, aber selbst das geht ja nicht! Deswegen war ja meine Frage auch, ob sich daran in 2010 VS was ändert/ ob einer weiss, ob man das feature RemoteDebugging dort wieder vernünftig nutzen kann (in VS 6.0 ging es immer!).

Derzeit machen wir es auch mit der ExpressEdition und debuggen im VS direkt auf der Maschine. Zum Einen ist das wenig elegant und zum Zweiten gibt es da Lizenzrechtliche Probleme mit einigen Zusatzbibliotheken, die unsere Software benutzt. Diese müßten wir streng genommen für jede dieser Maschinen auf der wir "entwickeln" (auch wenn wir dann dort eigentlich nur debuggen) auch kaufen. Und hier liegt der Hase im Pfeffer. Das wären für 3 Maschinen weit mehr als 10000 Euro. Mit remote debugging könnte man die Software ohne schlechtes Gewissen debuggen und ohne den Rechner des Kunden vollzumüllen.

Ich habe auch noch ein wenig weiter gesucht und nichts erhellendes finden können. Naja, ich hab ja einen OV MSDN Premium, ich werde es dann wohl selber herausfinden müssen. Für uns wäre momentan ein funzendes RemoteDebugging soziemlich der einzige Grund um auf VS2010 umzusteigen und das Umsteigen auf die neuere Version macht ja auch Arbeit (die wir uns für den Fall das sich am RemoteDebug nix ändert dann warhscheinlich auch gespart hätten und mit VS9 weiter gemacht hätten).

[Gast]

dass es nicht möglich ist, sobald sich der Zielrechner nicht in der selben Domäne befindet (oder wenigstens einmal dort registriert war) wie der PC des Entwicklers (es gibt dazu zahlreiche threads). Darüber hinaus gibt es zahlreiche "Gängeleien", so muss z.B. auf Ziel- und Entwicklungs- PC ein Account des selben Benutzers angelegt sein mit identischem Passwort (ein Unding eigentlich, aber immerhin noch machbar).

Das ist simpelste Windows Security! Es wäre ein Unding, wenn es standardmäßig nicht so wäre. Man braucht auch nicht zwingend einen Domain Controller. Wie du nämlich selbst erkannt hast, muss man dann dasselbe Benutzerkonto auf dem Server haben, weil dann die Authentifizierung über NTLM geht. Du kannst im Remotedebugger auch jedliche Sicherheit runterschrauben und jeden Debuggen lassen. Ob das schlau ist, steht auf einem anderen Blatt.

[rpm8200]

Na jetz aber... :freak: Was hat das mit Security zu tun, wenn Du auf einem Rechner nicht per RemoteDebugging zugreifen kannst, obwohl Du Zugriffsrechte hast -ein Account und ein Passwort?? Das ist keine Security, das ist ein Bug (ich nehme an in der RemoteDebug Server Seite, da der Connect an den RemoteDebug Server im Rechner unseres Kunden noch funktioniert, auch das Anhängen an den Prozess/ die Prozesse, jedoch komen wir nicht mehr zurück). Man kann diesen Bug auch googeln (wie schon gesagt und es gibt diverse (unschöne) Lösungsansätze, die wir alle versucht haben).

[Gast]

Derzeit machen wir es auch mit der ExpressEdition und debuggen im VS direkt auf der Maschine. Zum Einen ist das wenig elegant und zum Zweiten gibt es da Lizenzrechtliche Probleme mit einigen Zusatzbibliotheken, die unsere Software benutzt. Diese müßten wir streng genommen für jede dieser Maschinen auf der wir "entwickeln" (auch wenn wir dann dort eigentlich nur debuggen) auch kaufen. Und hier liegt der Hase im Pfeffer. Das wären für 3 Maschinen weit mehr als 10000 Euro. Mit remote debugging könnte man die Software ohne schlechtes Gewissen debuggen und ohne den Rechner des Kunden vollzumüllen.

1.) Ob elegant oder nicht, darüber kann man streiten. Tatsache ist jedoch, dass eine kompilierbarer Code vor Ort im Notfall sehr viel bringt. Es gibt nichts schlimmeres, als wenn irgendein Verweis zu externen Software nicht gefunden werden kann und man kann nicht nachvollziehen warum, vor allem wenn die Produktion des Kunden steht. Ich habe hier mit Access Runtime beim Kunden schon so einige schlechte Erfahrungen gemacht. Zusätzlich ist garantiert, dass der Kunde bei einer Neuinstallation auch wirklich den Letztstand vor Ort hat und nicht mit einer alten Version arbeitet oder mit einer zu neuen, die noch nicht vollständig getestet wurde. Abgesehen davon habe ich auch schon Fälle gehabt, wo sich ein Kunde mit Anleitung selbst eine Änderung durchgeführt hat. Mit einfach so drüber patchen im Laufenden Betrieb ist immer etwas heikel, weil wie gesagt ein Verweis weg und es steht alles.
2.) Was die Lizenzierung angeht, so würde ich hier nachsehen, wie das genau geregelt ist. Nach meinem Verständnis ist eine Express Edition mit Source vor Ort noch kein Entwicklungsrechner, genauso wie wenn man nur debuggt, um den Fehler zu finden, aber das müsste man wie gesagt genau nachlesen.
3.) Ich erspare mir in vielen Fällen das debuggen, indem ich eine ziemlich detaillierte Protokollierung habe, welche Schritte mein Programm gerade durchläuft, die gegebenenfalls auch erweitert werden. Das ganze ist standardmäßig an, kann aber wenn die Datenmengen zu groß werden auch deaktieirt oder reduziert werden. Die Logging Funktionalität zieht sich bei mir quer durch die ganze Bibliothek z.B. habe ich eine Klasse zum Absetzen von SQL Kommandos, die diese gleichzeitig protokolliert, Eine andere Klasse greift auf Variablen einer SPS zu und protokolliert (sofern der Parameter dafür aktiviert wurde). Jeder Eintrag wird mit Datum und Uhrzeit versehen (auf Millisekundenbasis) und enthält auch den Thread, der den Eintrag erzeugt hat.

Ich habe auch noch ein wenig weiter gesucht und nichts erhellendes finden können. Naja, ich hab ja einen OV MSDN Premium, ich werde es dann wohl selber herausfinden müssen. Für uns wäre momentan ein funzendes RemoteDebugging soziemlich der einzige Grund um auf VS2010 umzusteigen und das Umsteigen auf die neuere Version macht ja auch Arbeit (die wir uns für den Fall das sich am RemoteDebug nix ändert dann warhscheinlich auch gespart hätten und mit VS9 weiter gemacht hätten).

Es gibt zwar ein paar nette Features von VS2010, aber der Großteil ist nur verfügbar, wenn man auf .NET 4.0 setzt. Da meine Bibliothek aber auch für Kunden verwendet wird, die nur ein kleines Standalone Tool haben wollen, muss ich hier auf .NET 2.0 setzen, um den Installationsaufwand in Grenzen zu halten. Manche Leute setzen auch noch Windows 2K ein.
Der Nachteil von VS2010 ist jedoch, dass es ganz schön Performance frisst, zumindest auf meinem Testrechner mit Beta 2. Das WPF ist ganz schön zäh. Wenn es da nicht bis zum Release noch massive Verbesserungen gibt, werde ich mir die 2010er Version auch sparen.

[Gast]

Sorry wenn ich mich hier einmische und etwas unqualifiziert rumtröte, aber wo liegt eigentlich das Problem? Jede vernünftige Anwendung prüft Bedingungen und behandelt auftretenden Fehler selbst. Wenn so etwas "remote" überprüft werden soll (so entsteht also Bananensoftware) schreibt man eben einen kleinen Troja.. äh Server, welcher die auftretenden Probleme eben an eine Maschine der Wahl übermittelt und Befehle entgegen nimmt etc.

Da benötigt man weder Lizenzen, Domänen noch hunderte MByte an RTLibs.

Nur etwas Können.

[Ectoplasma]

Sorry wenn ich mich hier einmische und etwas unqualifiziert rumtröte ...

Belass es beim Rumtröten, du hast wirklich scheinbar nicht die geringste Ahnung, worum es hier überhaupt geht, oder? Das mit dem Trojaner lass mal nicht den Kunden merken, dass war dann mal dein Kunde gewesen. Es sei denn er erlaubt so etwas explizit. Und was Fehler in einer Software anbelangt, so lernt man schon im ersten Semester Informatik, dass man mathematisch nicht beweisen kann, dass eine Software fehlerfrei ist. Selbst dann nicht, wenn man sie nach bestem Wissen und Gewissen entwickelt hat.

@Gast1 und rpm8200, ja stimmt, eine VM ist nur bedingt einsetzbar, was die Hardware Umgebung anbelangt. Da habe ich etwas zu schnell gepostet.

[Coda]

so lernt man schon im ersten Semester Informatik, dass man mathematisch nicht beweisen kann, dass eine Software fehlerfrei ist.
Das ist sehr wohl möglich. Und es wird auch gemacht.

Das Halteproblem besagt nur, dass es keinen Algorithmus gibt um automatisch zu bestimmen ob ein Programm hält oder nicht. Ein Mensch kann aber sehr wohl die formale Korrektheit eines Programms beweisen.

Zum Beispiel wurde das für den kompletten L4-Microkernel mit Hilfe von Isabelle (http://www.cl.cam.ac.uk/research/hvg/Isabelle/) durchgeführt.

[Gast]

Jetzt kommen wieder die Theorien von fehlerfreier Software und der unfehlbaren Programmierer.

Wenn es um Standardsoftware geht, die 100 Mio. Mal verkauft wird, dann mag das bei gewissen Teilen wirklich zutreffen, aber in der Entwicklung von Individualsoftware für die Industrie schaut das eben komplett anders aus. Da hat man nicht die Zeit bzw. das Budget, dass man Software 3 Jahre lang testet auf alle eventuellen Gegebenheiten. Zusätzlich setzt man nicht auf gut dokumentierte, garantiert fehlerlose Produkte auf. Da kann es gut sein, dass eine Bibliothek sich von Zeit zu Zeit aufhängt, ein Ausgang eines Geräts einen Wert in einer Situation annimmt, der anders in der Dokumentation steht, falls überhaupt eine Dokumentation vorhanden ist und man die Signale, die man bekommt, nicht durch Versuch und Irrtum ermitteln muss. Ich habe schon Fälle gehabt, da war der einzige Weg eine Datei zu schließen, den COM Server mit Process.Kill abzuschießen. Ein anderes Mal habe ich es mit einem ActiveX Control zu tun, das mir abschmiert und ohne eine Exception zu werfen den ganzen Prozess mitnimmt, weil der Hersteller diesen Einsatzzweck nie getestet hat. Da habe ich ein Tool schreiben dürfen, das nichts anderes macht, als zu schauen, ob der Prozess nocht läuft, ob der Hauptthread noch reagiert (blockierende Aufrufe, die in einer Endlosschleife hängen bleiben) und bei Bedarf den Prozess abwürgt und neu startet. Ein anderes Mal crasht ein simpler Befehl, der nur eine Datei lädt von Zeit zu Zeit einfach (einmal alle 100 Zugriffe) und ein erneuter Versuch ist erfolgreich. Ein anderes Mal gibt es an der Hardware irgendwo eine statische Aufladung und ein Eingang fängt auf einmal an zu spinnen.
Da können so viele theoretische Fehlerquellen auftreten, dass es unmöglich ist, alle Fehler im Vorhinein zu erahnen und abzufangen. Meine umfangreiche Protokollierung hat mir da schon sehr oft geholfen. Die klassische Methode, die man in der Schule bei einem C Einführungskurs lernt, dass man alle IO Zugriffe nachher extra auf alle Fehlercodes überprüft, ist hier unbrauchbar. Erstens kann man hier jede Zweile ca. 30 Zeilen Code für die Fehlerbehandlung opfern, wodurch die Software unwartbar wird, da keiner mehr die Kernkomponenten ermitteln kann. Zweitens bekommt man in vielen Fällen einfach nur ein falsches Ergebnis zurück, statt einem Fehler und drittens ist nur in den allerseltensten Fällen eine Dokumentation vorhanden, welche Fehler überhaupt auftreten können. Hier ist die einzige Möglichkeit über alles ein Try Catch zu stopfen, die Exception zu loggen und wenn der Kunde anruft versuchen um die ganze Geschichte herum zu programmieren.
Mit der typischen Einstellung "ich fange sowieso alle möglichen Fehler ab" kommt man meistens nur bis zum ersten Firmware Bug, den man bisher nicht gekannt hatte und dann ruft der Kunde an, das die Software 3 Mal am Tag abstürzt und die einzige Fehlermeldung, die man bekommt ist ein schönes "Diese Anwendung funktioniert nicht mehr". Wenn man beim Kunden 2 Arbeiter fragt, wann das Problem genau auftritt, dann bekommt man 3 verschiedene sich ausschließende Varianten erzählt, die alle miteinander nicht stimmen und man kann sich nur mehr in die Ecke setzen und heulen, während beim Kunden 20 Leute bei der Produktion in die Luft schauen, während alles steht.