Newsgroup: it.comp.programmare.win32
Titolo: Disperazione per la lentezza di .NET!!!

Mi scuso in anticipo se vi disturbo per quella che potrebbe sembrare una
banalità, ma veramente ho superato il limite di sopportazione.
Sto' sviluppando in ufficio una applicazione C# che comprende circa 20
progetti separati [cioe' sviluppati da diversi gruppi di lavoro], il
problema e' che C# non permette le modifiche in debugging e ad ogni piccolo
errore si deve riavviare l'applicazione! Ad ogni riavvio la suite ricompila
l' *INTERO* gruppo di progetti, bloccando praticamente la macchina e facendo
perdere tempo a non finire.
Visto che lavoriamo su PC pentium 4 da 1.4ghz con 256MB di ram, e che questi
non possono [almeno per ora] essere potenziati, cosa si puo' fare per
ovviare il problema?
possibile che non esiste nessuna impostazione per dire alla suite di
ri-compilare solo i progetti modificati, e non tutto il gruppo come invece
accade?
grazie a tutti in anticipo!
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 errore si deve riavviare l'applicazione!
Lavori male se devi spesso mettere a posto "piccoli errori" a run-time, 
IMHO. 
-- 
Luc

 IMHO.
Quando fai test di interfaccia e di layout c'e' poco da lavorare male!


 Quando fai test di interfaccia e di layout c'e' poco da lavorare male!
Che significa? 
Ad ogni modo.. una maniera di decrementare il numero degli errori e`
fare testing...
-- 
Lawrence

In data Wed, 28 Jan 2004 18:47:14 GMT, PG ha scritto:
[cut]
E' interessante notare le dinamiche di una discussione: tu hai fatto una
domanda, non ti e' stata data risposta ma in compenso hai ricevuto critiche
sul tuo modo di programmare...
Per tornare al merito della domanda io in 
vb.net
 (che condivide lo stesso
IDE del C#) ho nel menu Build le voci che mi permettono di ricompilare
l'intera solution o solo il nodo attivo in quel momento.
E' chiaro che se la tua soluzione comprende files comuni a diversi progetti
ogni singola modifica a questi file implica la ricompilazione dell'intera
soluzione.
Purtroppo in .Net si è persa la comodita' presente in VB6 di poter
debuggure in runtime (con i suoi pro e contro che non sono oggetto del tuo
post), in .Net si dovra' aspettare la prossima versione di Visual Studio.
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 sul tuo modo di programmare...
La risposta se l'era già data da solo, io ho aggiunto qualcosa in più 
alla discussione, opinabile magari, ma non censurabile... ;) 
-- 
Luc

 post), in .Net si dovra' aspettare la prossima versione di Visual Studio.
    Scusate l'ignoranza. Mi illuminate sui contro di effettuare un debug a
Runtime? E perchè secondo voi PG programma male? Quale sarebbe la via
giusta? :|


 giusta? :|
Mmm io non la vedo una grande perdita quella dell'edit and continue anche
perche` sono sempre sopravvissuto senza. Ad ogni modo... l'edit and
continue e` una tecnica che ti permette di modificare le istruzioni
durante il debug e fare in modo che il debugger si accorga di tali
modifiche senza dover ripartire da capo. Utile ma in taluni casi
pericoloso. Ad ogni modo sembra che in .NET tornera` solo per i
programmatori VB che a quanto pare non possono vivere senza ;-)
ciao!
-- 
Lawrence

 programmatori VB che a quanto pare non possono vivere senza ;-)
ROTFL! E il cerchio si chiude..... 
-- 
Luc

 ROTFL! E il cerchio si chiude..... 
Scusa ma mi sono appena svegliato... che intendi :) ?
-- 
Lawrence

 Scusa ma mi sono appena svegliato... che intendi :) ?
Chi programma in VB... Ne ha bisogno... ;-P
-- 
Luc

 ha scritto nel messaggio
news:MPG.1a884458c...@tornado.fastwebnet.it...

Ah, ho capito. Si ma chi se ne frega di questo tipo di debug! Avevo capito
tutt'altro. Sinceramente preferisco il debug completo e non ste cose al volo
per cui non mi peserebbe la mancanza in .NET
Grazie per l'illuminazione
Adriano C.