[VB.NET] La Soluzione è diventata lenta in avvio

[Rickycast]

Grazie, era banale ma non scontato.
Quindi io opero comunque e solo su un Progetto (uno alla volta se ce ne sono più di uno)?
E ancora quindi, eseguire "Ricompila soluzione" ricompila TUTTI i Progetti in essa compresi, mentre "Ricompila Progetto" ricompila solo quel progetto?

[djciko]

Puoi operare anche su un solo progetto.

Ti faccio un esempio, nel nostro team c'e' una Solution su cui lavoriamo (con SVN naturalmente) in 8 persone.

La solution contiene:

- 4 progetti class library
- 1 progetto class library usato per i test
- 3 progetti per tre WebServices
- 4 progetti per tre WebServices Mock (cioe' simulatori, con risposte finte per ora)
- 1 progetto per una console application
- 1 progetto per un website
- 1 progetto per un windows service

Attualmente io sto lavorando sulla console application.


Si, quando ricompili la soluzione ricompila tutti i progetti in essa contenuti.
"Ricompila progetto" invece ricompila solo quel progetto su cui hai fatto click.

[djciko]

Inoltre, puoi mettere fra i riferimenti di un progetto un altro progetto della solution.

Cio' implica che l'ultima versione della DLL sara' usata dall'altro progetto che lo referenzia.

Da questo, non puoi creare un riferimento a quello che lo referenzia perche' Visual Studio ti dice che si sta creando un "riferimento circolare". Ovvio.

Tutto questo discorso dei riferimenti, riguardo i dettagli, include anche i modificatori ovviamente (public / private etc).

[Rickycast]

Ancora grazie. Saranno ovvietà ma senza chiarezza di idee rischierei di fare cose inutili e/o superflue che per finire complicano inutilmente il lavoro.

[djciko]

stavo per suggerirti di controllare quale provider (namespace) usi per connetterti al DB...

che significa "ho chiesto al sistema di aprire..." ?

che connectionstring stai usando ed inoltre che significa "tabelle che istanzio all'occorrenza" ?

[Rickycast]

stavo per suggerirti di controllare quale provider (namespace) usi per connetterti al DB...

che significa "ho chiesto al sistema di aprire..." ?

che connectionstring stai usando ed inoltre che significa "tabelle che istanzio all'occorrenza" ?

Chedo scusa fin da ora per le improprietà di linguaggio.
" ho chiesto di aprire..." nell'elenco dei moduli e delle Form del progetto trovo anche "ArcSisVBNetServerDataSet.xsd" che non mi ricordo di avere in serito e che non so cosa sia. So solo che il mio DB si chiama "ArcSisVBNetServer". Potrebbe essere una causa?

Utilizzo la seguente Connection string: "Provider=Microsoft.ACE.OLEDB.12.0;Persist Security Info=False;Data Source=" con la quale mi connetto a "S:\ArcSisVBNet\ArcSisVBNetServer.accdb" ma anche a "C:\SisVBNet\ArchSis.accdb"

Ho scelto perché mi sembrava più logico provenendo io da Access 2000, di utilizzare soprattutto le Query e quindi utilizzo quanto in esempio:

            sSQLAccess = "DELETE Prodotti.* FROM Prodotti"
            rsProdotti.Open(sSQLAccess, CnDBServer, ADODB.CursorTypeEnum.adOpenStatic, ADODB.LockTypeEnum.adLockOptimistic)

A questo mi riferivo quando ho scritto "tabelle che istanzio all'occorrenza". Scusatemi,...
In fondo a tutto, però il mio progetto funziona e fa esattamente quello che mi serve, solo ci mette molto ad avviarsi ed i miei utilizzatori non hanno pazienza, accidenti a loro!!!

[djciko]

se le performance sono cambiate senza fare nulla, potrebbero anche essere i windows update che hanno cambiato qualcosa, la butto li'...

per il resto in Visual Studio, in debug (avanzando con F11, non con F10), puoi aprire la finestra "Strumenti di diagnostica". Ci arrivi anche cliccando sul tempo di esecuzione che vedi a fianco ad ogni istruzione.

Cosi' puoi vedere quale istruzione impiega piu' tempo per risolversi...


"xsd" è uno schema xml comunque

[Rickycast]

Grazie djciko, provo a fare come suggerisci. Se trovo le ragioni, posterò.

[Rickycast]

....
per il resto in Visual Studio, in debug (avanzando con F11, non con F10), puoi aprire la finestra "Strumenti di diagnostica". Ci arrivi anche cliccando sul tempo di esecuzione che vedi a fianco ad ogni istruzione.

Cosi' puoi vedere quale istruzione impiega piu' tempo per risolversi...

Io sapevo solo mettere i punti di interruzione e poi avanzare con F8: grazie per le preziose informazioni.
Così facendo ho visto che i tempi sono "lunghi" quando accedo al DB e devo presumere che questo avvenga perché il DB nel tempo è diventato sempre più pesante (21MB dopo compattazione) oppure, magari, perché in qualche modo si è deteriorato. Ribadisco comunque che, se chiedo l'Avvio in Debug e per errore ho lasciato il DB aperto, il sistema segnala un errore; si avvia egualmente ma con tempi assolutamente rapidissimi.
Adesso, se non hai altri suggerimenti, penso che farò due o tre cose:
1 - svuoterò dopo l'utilizzo tutte le Tabelle del DB che utilizzo solo in modo transitorio
2 - aprirò un nuovo DB nel quale copiare tutte le tabelle per vedere se il sistema si velocizza
3 - altrimenti creo un nuovo DB e riscrivo le Tabelle ad una ad una, magari riducendo le dimensioni dei campi testo al minimo logico
Resto in attesa di commenti.
Grazie

[Rickycast]

....

per il resto in Visual Studio, in debug (avanzando con F11, non con F10), puoi aprire la finestra "Strumenti di diagnostica". Ci arrivi anche cliccando sul tempo di esecuzione che vedi a fianco ad ogni istruzione.

Cosi' puoi vedere quale istruzione impiega piu' tempo per risolversi...

Molte grazie djciko, io usavo solo i punti di interruzione avanzando con F8; non sapevo si potessero usare anche F10 e F11.

In questo modo ho visto che i tempi erano particolarmene lunghi quando il processo copiava il DB dal Server al Client e questo era dovuto specialmente ad una istruzione "Sleep" aggiunta per evitare che si manifatassero errori. Per adesso ho tolto questa istruzione salvo ripristinarla riducendola al minimo se necessario.
Adesso l'avvio si verifica in tempi decisamente ragionevoli.
Ancora grazie