perché un'applicazione dovrebbe agire in modo diverso dopo aver collegato il debugger VS?

Question

Esiste un'applicazione desktop scritta in c # che tenta di gestire una connessione socket e fallisce ma ha esito positivo dopo che la stessa applicazione è stata collegata a Visual Studio.

come può essere eseguito il debug?

Answer 1

Questo è un classico esempio di tempismo.

Se funziona nel debugger, significa che è necessario ricodificare un po 'il codice per gestirlo.

Ora, se sei un'app è un socket del server che riceve connessioni dal client e sta provando a generare un thread per ognuna di quelle connessioni, potresti dover considerare di utilizzare select () per gestire le connessioni in un thread.

Answer 2

Direi che anche i problemi di temporizzazione con il debugger collegato rallenteranno leggermente il codice, il che potrebbe significare che non si sta verificando una race condition.

Per eseguire il debug provare ad aggiungere un po 'di codice di registrazione alla tua applicazione, uso personalmente log4net

Non dovresti avere problemi con malloc e simili mentre stai programmando in c #.

se stai eseguendo un'app Web, potrebbe anche esserci una differenza tra il webserver cassini in VS e quello in cui stai distribuendo.

Answer 3

Di solito, problemi di temporizzazione. Ci sono discussioni coinvolte? Se C / C ++, potrebbero esserci molte ragioni a causa del comportamento dei bug di gestione della memoria.

Answer 4

Potresti avere variabili i cui valori predefiniti sono diversi quando si esegue sotto il compilatore rispetto a standalone. Le condizioni di gara potrebbero essere un'altra idea se ci sono discussioni.

Se stai allocando RAM tramite malloc o new, assicurati che la memoria sia inizializzata correttamente prima di usarla.

Answer 5

In realtà abbiamo riscontrato un problema simile. Il tempismo è una parte fondamentale di questo. Oltre a lanciare no-op nel codice (differenza principale con codice di debug).

Con la programmazione dei socket, sembra che il debug con VisualStudio.Net sia come fare ulteriori chiamate Application.DoEvents (). Abbiamo scoperto che abbiamo cose che falliranno (senza debug) a meno che non consentiamo al componente di respirare (ad esempio gestire i propri eventi) chiamando Application.DoEvents ().

Answer 6

Quando Visual Studio si collega all'applicazione, CLR e JIT presentano sottili differenze di runtime per abilitare il debug. La raccolta dei rifiuti, ad esempio, è diversa.

http://stupiddumbguy.blogspot.com /2008/05/net-garbage-collection-behavior-for.html

Answer 7

L'IT potrebbe essere perché stai guardando proprietà con effetti collaterali nel tuo debugger. Sebbene le altre risposte qui siano più probabili ...