Hallo,
(s. Anhang)
kann mir bitte jemand erklären, was hier los ist?!
Irgendwie habe ich keine Nerven für solche Späße am Fr. Nachmittag.
Danke.
BTW:
VS2010 habe ich schon neu gestartet.
Die { } nach if habe auch schon gesetzt.
if (true == this.IsFielMoved) auch schon probiert.
BTW2:
public bool IsFileMoved { get; private set; }
Ciao:
GG 😉
Hallo,
ich hab sowas schon mal gesehen, wenn sich Visual Studio verschluckt hat (ist aber schon lang her). Bereinige mal die Solution und lass ihn ganz neu bauen.
Gruß, MarsSTein
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
So Leute,
(s. Anhang)
das ist mir zu hart für ein Freitag Abend.
Ich mach' jetzt Feuerabend (und denke über ein Alternativ-Beruf nach.
Schafe züchten auf Sardinien, das wäre was Entspanntes.
Ciao:
GG 😉
Hast du die Variable schon mal auf der Console ausgeben lassen?
Wenn VS bei mir misst baut schließe ich die Solution und lösche sowohl jeden bin, als auch obj Ordner. Dann neu öffnen und neu kompilieren. Meist stellt sich zwar dan nraus, dass VS alles richtig gemacht hat, und das Problem ca 20cm vor dem Rechner saß, aber manchmal hilft es. Solange nicht noch irgendwelche Fremddaten im bin Ordner liegen, die nicht durch VS automatisch reinkopiert werden kann man das problemlos machen. Die Ordner werden automatisch wieder erstellt
Hallo zusammen,
ich tippe mal stark auf ein Multithreading-Problem.
hast du dir mal die CurrentThreadId ausgeben lassen?
Gruss
coffeebean
=== EDIT:
Egal wie die Lösung aussah...sie interessiert mich 😃
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Hallo Leute,
vielen Dank, dass so viele von Euch versuchen zu helfen.
Status:
obj\bin Ordner wurden schon mehrmals komplett gelöscht, reboot VS bzw. PC haben auch nicht geholfen.
Was ich aber gefunden habe, und da wären wir bei Multithreading, mit lock geht's richtig:
(s. Anhang)
Wer? Wo? Was hat an meinem Instanz herumzufummeln?!
Wie kann ich das überwachen?
Ciao:
GG 😉
Hallo GG71,
erstmal kannst du dir die ThreadID ausgeben lassen. Dann siehst du welcher Thread hier überhaupt rumwerkelt.
Weiter ist glaube ich lock(this) nicht so gern gesehen (steht auch hier im Forum glaube ich). Mach dir lieber ein Object als Klassenvariable und lock darauf.
Gruss
Coffeebean
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Im Forum steht allerdings auch das Gegenteil, nämlich eine Begründung, warum lock(this) der bessere Weg ist und die Empfehlung von Microsoft, lock(syncObject) zu verwenden, nicht so sinnvoll ist. Das Thema wurde ausführlich in Sollte man lock this vermeiden? und und in Entwurfsmuster Singleton und Schlüsselwort synchronized [und sollte lock(this) verwendet werden?] (und folgende Beiträge) diskutiert.
Weiter ist glaube ich lock(this) nicht so gern gesehen (steht auch hier im Forum glaube ich). Mach dir lieber ein Object als Klassenvariable und lock
siehe MS-Doku: lock-Anweisung
Wie kann ich das überwachen?
z.B.
edit:
Ist das Property IsFileMoved öffentlich oder privat?
Hallo,
lock auf das eigene Objekt ist halt problematisch da es leicht zu Deadlocks kommen kann.
Aber ganz ehrlich, du greifst ohne Synchronisierung von mehreren Threads auf die gleiche Variable zu und wunderst dich dass es Seiteneffekte gibt? Da gehören eindeutig die Multithreading Grundlagen nochmal aufgefrischt.
PS: Scheint ja nun doch kein VS Problem zu sein, daher ab in Basistechnologien
Baka wa shinanakya naoranai.
Mein XING Profil.
Ergänzung zu lock(this): Das Argument zieht insofern nicht uneingeschränkt, als dass es auch bei lock(syncObject) Deadlocks geben kann, wenn EventHandler ins Spiel kommen. Man muss also so oder so aufpassen. Auf der anderen Seite wird dem Benutzer der Klasse eine erweitertes Synchronisieren durch ein privates syncObject unnötig erschwert. Alles weitere in den oben genannten Links.
Aber ganz ehrlich, du greifst ohne Synchronisierung von mehreren Threads auf die gleiche Variable zu und wunderst dich dass es Seiteneffekte gibt? Da gehören eindeutig die Multithreading Grundlagen nochmal aufgefrischt.
Leider schweigt hierzu der Themenersteller. Von mehreren Thread's ist bis jetzt keine Information durchgedrungen.
@MarsStein
Hallo Leute,
ich habe kein Multithread, sonst hätte ich es schon geschrieben bzw. schon länger in diese Richtung gesucht. Es ist eine Consolenanwendung ohne GUI-Thread.
Und die Sache ist noch bunter:
Der Debugger geht in die if-Bedingung, zeigt die throw Zeile als aktiv an, es wirft aber kein Exception bzw. wirft es erst weiter unten in der Methode. Ich habe mich die ganze Zeit durch die Darstellung vera****en lassen, weil ich den Fehler gesucht habe und meinte, es sieht wirklich so aus, gefunden zu haben.
Also die Erklärung ist, das "nur" die optische Darstellung im Codeeditor falsch ist, die if-Bedingung wird korrekt verarbeitet (auch ohne lock).
Sorry, dass ich Euch irregeführt habe, war kein Absicht.
Ciao:
GG AKA Georg 😉
Ciao:
GG 😉
Hallo GG71,
kannst du mir mal deine Solution/Klasse/ dein Projekt hochladen (oder Link per PM schicken)?
Ich würde mir das gerne mal anschauen zuhause.
Gruss
coffeebean
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Okay, ich hatte
...Was ich aber gefunden habe, und da wären wir bei Multithreading, mit lock geht's richtig... so verstanden das er es verwendet.
Was meinst du mit
bzw. wirft es erst weiter unten in der Methode. Wo unten? An was für einer Stelle?
Baka wa shinanakya naoranai.
Mein XING Profil.
ich habe kein Multithread
Du kopierst immer synchron auf einen FTP-Server? Wie denn genau?
Es ist eine Consolenanwendung ohne GUI-Thread.
Das schließt Multithreading nicht aus.
Benutze doch auch mal Logging (Debug.WriteLine, Console.WriteLine) anstatt der Haltepunkte. Echtzeitverhalten kann man so besser analysieren.
Also die Erklärung ist, das "nur" die optische Darstellung im Codeeditor falsch ist, die if-Bedingung wird korrekt verarbeitet (auch ohne lock). Ich vermute mal ganz stark, das die Sourcedatei nicht zu der DLL passt, die gedebuggt wird. Überprüfe deine Debugging optionen!
Hi,
@talla:
die Code-Blöcke "Step 1: Bla-Bla", "Step 2: Bla-Bla" habe ich immer zusammengeklappt im Screenshot gehabt, war die Meinung, dass es nichts mit der Exception zu tun hat. Im Block 2 bricht die Anwendung bei der Ausführung in der Wirklichkeit ab, nicht so wie es mir der Debugger vorgaugelt.
BTW. Multithreading:
lock war nur ein Verzweiflungsschritt.
Es ist eine Consolenanwendung ohne GUI-Thread.
Das schließt Multithreading nicht aus.
Ja, damit meinte ich: Ich mache kein 2. Thread auf, WPF auch nicht.
Also die Erklärung ist, das "nur" die optische Darstellung im Codeeditor falsch ist, die if-Bedingung wird korrekt verarbeitet (auch ohne lock).
Ich vermute mal ganz stark, das die Sourcedatei nicht zu der DLL passt, die gedebuggt wird. Überprüfe deine Debugging optionen!
Habe bisher keine entsprechende "Abweichungen" in der Darstellung festgestellt, welche Einstellungen sollen hier Auswirkungen haben?
Ciao:
GG 😉
Hallo,
und was steht im FTP Upload Block?
Ich mache kein 2. Thread auf, WPF auch nicht.
Wo kommt WPF jetzt auf einmal her? Dachte du hast ne Konsolenanwendung?
Baka wa shinanakya naoranai.
Mein XING Profil.
So wie ich den Screenshot weiter oben sehe, ist wirklich entweder Multithreading am Werk oder aber die Sourcen passen nicht zur den Binaries.
Allmählich wird es hier im Thread auch etwas zu Bunt... Bitte schreib eindeutig, was du hast und was du einsetzt.
Welche Einstellung du in den Optionen überprüfen sollst, wirst du ganz schnell erkennen, wenn du dir den letzten Teil meines ersten Satzes in diesem Post durchließt.
Ansonsten hilft dir nur noch das Threading Fenster. Auch zu finden unter Debug->Windows->Threads
Dort kannst du sehen, wie viele Threads am laufen sind und in welchem du auf einmal bist.
Sollte das kein fruchtbares Ergebnis liefern, baust du dir am besten ein kleines Beispielprojekt, um den Fehler zu reproduzieren.
Ja, damit meinte ich: Ich mache kein 2. Thread auf, WPF auch nicht.
WPF? Ansonsten kann aber natürlich eine FTP-Komponente bzw. -Bibliothek mit mehreren Threads arbeiten (was sie im Normalfall auch tun wird). Leider hast Du die entsprechende(n) Frage(n) nicht beantwortet.
Hallo Leute,
vergisst es mal mit Multithread, das versuche ich schon von Anfang an zu erklären. Es gibt weder ein GUI- oder FTP-, geschweige ein von mir selbst eröffnete 2nd Thread.
Die Erklärung war:
Der Debugger zeigt Müll an, obwohl bin\obj Ordner schon mehrmals gelöscht wurden.
Siehe Screenshots oben:
Die gelbe Aktiv-Zeile beim Step by Step (F11) Durchlaufen der Source geht jedes mal in if-Bedingung, obwohl die abgefragte Property false ist. Es springt sogar auf die throw Zeile und suggeriert damit, dass die von mir gesuchte Exception von dieser Stelle stammen würde. Da ich deshalb jedes mal gestoppt habe, um zu überprüfen, warum ich trotz nicht erfüllte Bedingung im if gelandet bin, habe ich erst später gemerkt, dass throw in der Wirklichkeit, egal was der Debugger anzeigt, hier nicht ausgeführt wird, sonder in der gleiche Methode aber weiter unten.
Ich hoffe, ich konnte jetzt die Angelegenheit klären.
Danke nochmal für die Hilfe,
Ciao:
GG AKA Georg 😉
Ciao:
GG 😉
Hallo zusammen,
in Fällen, denen man den Verdacht hat, dass der Debugger falsch arbeitet bzw. falsch anzeigt, sollte man versuchen, sich mit Logging- bzw. Tracing-Ausgaben Klarheit zu verschaffen, was wirklich passiert.
herbivore
Hallo,
Die Erklärung war:
Der Debugger zeigt Müll an
Sorry, aber das ist doch keine Erklärung. Sicherlich ist keine Software vor Fehlern gefeit, aber so ein Fehler im VS Debugger wäre schon längst bekannt. Daher tippe ist immer noch, dass der Code dieses Verhalten auslöst. Was in den zugeklappten Codeblöcken steht und wie du deine MoveToFTP aufrufst, hast du ja immer noch nicht gezeigt. F11 springt auch nur in Code rein der auch ausgeführt wird.
Baka wa shinanakya naoranai.
Mein XING Profil.
Hallo,
ich verwende zum Beispiel Code Contracts. Die kompilierten Assemblies werden dabei umgeschrieben was dazu führt, dass die angezeigten Zeilen mit den tatsächlichen manchmal nicht übereinstimmen.
Vielleicht ist es in deinem Fall ähnlich?
spooky
Hallo Spook,
die CodeContracts und der Debugger vertragen sich sehr gut, die angezeigten Zeilen stimmen mit den tatsächlichen überein.
Die Zeilen können nicht übereinstimmen wenn ein Release-Build gedebuggt wird und die *.pdb nicht korrekt geladen wird. Aber auf diesen Punkt (die *.pdb) wurde ja schon mehrmals hingewiesen in diesem Thread (z.B. von Jack30Lena).
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Die Zeilen können nicht übereinstimmen wenn ein Release-Build gedebuggt wird und die *.pdb nicht korrekt geladen wird
Eine etwas "merkwürdige" bzw. "ungewöhnliche" Abfolge im Debugger könnte beim Debuggen eines Release-Builds auch durch die Optimierungen entstehen.
Auch aus diesem Grunde wurde schon ein paar Mal auf das Logging verwiesen.
Hallo,
aber so ein Fehler im VS Debugger wäre schon längst bekannt.
habe die entsprechende Stelle als Projekt extrahiert (s. Anhang).
Bin mal gespannt, wie es sich bei Euch beim Debuggen verhält.
Ciao:
GG 😉
Ciao:
GG 😉
Hallo GG71,
Bin mal gespannt, wie es sich bei Euch beim Debuggen verhält.
Auch ohne Debugger sehe ich, dass das klar in die Exception läuft da FileType null ist.
Es wäre besser wenn du mal wirklich Tracing einbaust um schauen wann und wo (Stacktrace) der Eigenschaftswert geändert wird. Darauf wurdest du schon mehrfach hingewiesen.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Habs grad mal bei mir getestet, :::
mfg seraph
Ich beschütze das was am Wichtigsten ist!
Moin,
Auch ohne Debugger sehe ich, dass das klar in die Exception läuft da FileType null ist.
ja, jetzt in der abgespeckte Version, hat aber nichts mit der Problematik zu tun.
Wenn ich Console.Writeline oder was auch immer einfüge geht der Debugger nicht mehr in die if-Schleife. Ich könnte es höchsten mit der Handy abfilmen, habe jetzt aber nicht wirklich Zeit für sowas.
Edit:
Ich habe jetzt doch ein Screen-Video vom Ablauf im Debugger erstellt.
Ciao:
GG 😉
Ciao:
GG 😉
Hallo GG71,
nicht mehr in die if-Schleife
Siehe http://www.if-schleife.de/
habe jetzt aber nicht wirklich Zeit für sowas.
Aha, darum sollen wir für dich die Ursache finden...
Hast du das Video mit der oben angehängten Klasse erstellt? Da ist das Verhalten eindeutig nicht so.
Und bau endlich mal im Setter von IsFileMoved Tracing ein - sonst bringt das gar nix. Bitte beachte [Hinweis] Wie poste ich richtig? Punkt 8.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"