2009-05-07 13 views
7

Con piccoli progetti, posso passare alla visualizzazione del progetto quasi istantaneamente (< 1 secondo).Cosa potrebbe causare un rallentamento della vista del progetto?

Ho un progetto di grandi dimensioni che impiega circa 60 secondi per aprire un controllo o un modulo in visualizzazione struttura - solo per la prima volta. Dopo questo ritardo di 60 secondi, posso aprire qualsiasi controllo nel progetto in modalità di visualizzazione quasi istantaneamente, finché non ricompilare il progetto.

Se l'exe creato da questo progetto viene fatto riferimento in un altro (piccolo) progetto, il piccolo progetto diventa istantaneamente lento come il grande progetto. Allo stesso modo, se aggiungo tutti i file dal grande progetto al singolo progetto, il piccolo progetto diventa lento.

Il progetto di grandi dimensioni fa riferimento a un progetto Managed C++ di grandi dimensioni, ma se aggiungo lo stesso riferimento (e richiamo una funzione dal riferimento per assicurarmi che sia caricato) nel piccolo progetto, il piccolo progetto è ancora veloce.

Il mio grande progetto utilizza SandDock. Se il mio piccolo progetto utilizza SandDock, è ancora veloce.

Il mio progetto di grandi dimensioni ha circa 60 controlli utente visualizzati nella casella degli strumenti. Se aggiungo 60 controlli utente al piccolo progetto, il piccolo progetto è ancora veloce.

Se eseguo il controllo utente nascosto dalla casella degli strumenti con [System.ComponentModel.ToolboxItem (false)], il progetto di grandi dimensioni è ancora lento.

Il problema si verifica sia in vs2005 che in vs2008.

Cosa potrebbe rendere il progetto di grandi dimensioni così lento da aprire la vista di progettazione per la prima volta? Qualche altro riferimento? Il gran numero di controlli? Il gran numero di classi? Qualche altra causa?

Una cosa che ho notato (anche se probabilmente un'aringa rossa) è che la cartella ProjectAssemblies (C: \ Documents and Settings \ tim.gradwell \ Impostazioni locali \ Dati applicazioni \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies) è enorme (> 1 GB) e la maggior parte delle cartelle qui presenti hanno una copia della mia DLL gestita per C++! Queste cartelle sembrano essere ricreate ogni volta che la vista del disegno viene riaperta (dopo una ricompilazione). Questo potrebbe avere qualcosa a che fare con il rallentamento?


ulteriori informazioni:

A toolstrip nel controllo utente o forma rende il modulo prendere 60 secondi per caricare. Rimuovendo la barra degli strumenti (ma avendo ancora diversi altri controlli sul modulo) si passa alla vista di progettazione istantanea.

Questo non è tutta la storia anche se ... Un toolstrip in un nuovo progetto non è causa di enorme rallentamento - quindi ci deve essere qualcosa nel mio grande progetto che sta colpendo toolstrips. Inoltre, alcuni altri moduli/controlli che non dispongono di barre su di essi impiegano ancora 60 secondi per visualizzare la vista del progetto, quindi qualunque sia l'effetto sulle strisce di strumenti influisce anche su altri controlli. Continuerò a cercare di inchiodare con precisione quali controlli e forse anche quello che lo sta causando!

+0

Solo per chiarezza: il grande progetto che causa il rallentamento è in C#, corretto? – overslacked

+0

Il progetto è scritto in C# ... fa anche riferimento a un progetto C++ gestito, ma non ho avuto il tempo di provare ad isolare il progetto C++ gestito per vedere se ciò ha fatto la differenza ... –

risposta

0

La stessa cosa simile sta accadendo con il mio 2005 a additon a che il devenv.exe pende in modo casuale

e anche dopo "edificio" a volte i controlli personalizzati tendono a corrompere la principale forma

avete di recente virus scansionato e deframmentato?

+0

Succede su un nuovissimo macchina (come nella nuova installazione di Windows). Su una macchina più vecchia ci vogliono diversi minuti per aprire la vista del disegno. –

7

Anche se hai contrassegnato le classi in modo che non compaiano nella casella degli strumenti, Visual Studio ha ancora bisogno di eseguire la scansione di tutti i tuoi progetti aperti per scoprirlo. Per velocizzare le cose, è necessario disattivare l'impostazione per popolare automaticamente la casella degli strumenti. Può essere un po 'fastidioso se lavori molto con la cassetta degli attrezzi, ma accelera molto le cose.

L'impostazione è in Strumenti -> Opzioni -> Progettazione moduli Windows, impostare "AutoToolboxPopulate" su false.

+0

Grazie per il suggerimento - ma succede ancora, anche se AutoToolboxPopulate è impostato su false :( –

+0

Anche dopo il riavvio e la pulizia, ecc. Questo è fastidioso Abbiamo avuto la stessa identica situazione, e quell'impostazione ha risolto tutto in modo corretto. ! –

2

La prima risposta: "L'impostazione è in Strumenti -> Opzioni -> Progettazione moduli Windows, impostare" AutoToolboxPopulate "su false" ha funzionato per me. Il progettista era solito aspettare almeno un minuto quando cercava di concentrarsi su un controllo su un modulo quando si esaminava un modulo in vista di progettazione. Ora, ci vogliono solo pochi secondi. (Non avevo abbastanza punti reputazione per commentare direttamente quella risposta)

0

Ho riscontrato questo problema in un progetto Win CE 6.0 in Visual Studio 2005. Il progetto utilizza System.Data.SQLite.dll v1.0.65.0 . Ogni volta che ho aperto o ricompilato il progetto, e poi ho provato ad aprire un modulo con una griglia per la progettazione, ci sarebbe stato un ritardo di almeno 12 minuti. Si è scoperto che stava generando 770 cartelle dispari in "Documenti \ Impostazioni locali \ Dati applicazioni \ Microsoft \ Visual Studio \ 8.0 \ Assiemi di progetto", la maggior parte dei quali aveva una copia della sola DLL SQLite.
Il problema sembra essere che ho fatto riferimento a questa DLL nel progetto da una cartella "fratello" al mio progetto. Per fare un esempio:
cartella del progetto: "... Progetti \ ThisAndThat \ projectFolder"
cartella DLL: "... Progetti \ ThisAndThat \ projectFolderBin"
Ci possono essere altri rapporti di cartella che manifestano questo problema, ma l'ho fatto non indagare.
Ho spostato la DLL nella cartella "Programmi \ Microsoft.NET \ SDK \ CompactFramework \ v2.0 \ WindowsCE" e il problema è andato via. Ho un modulo con un controllo struttura a schede che contiene due schede. Ogni scheda contiene un controllo datagrid. Questo modulo ora carica quasi istantaneamente nel designer.
Se qualcuno sa di una soluzione migliore o quale impostazione o comportamento di VS2005 causa questo problema, si prega di aggiungere un commento.

Problemi correlati