Ricerca 
it-ITen-US
Registrazione
Accedi
In-Vesti Dotnetwork
IN-VESTI DNW!!!
Sono finalmente arrivate le nuovissime T-Shirt di DotNetWork!!! Con soli 15,00 € ci sosterrai nelle spese di gestione della Community e ti invieremo a casa una splendida maglietta.
Se vuoi contribuire al mantenimento di DotNetWork.it Vai sulla pagina Iscrizioni
Effettua il pagamento usando IWBank
Click per andare alla pagina di Iscrizione
Oppure un Bonifico bancario (le coordinate sono sulla pagina Iscrizioni), inviaci una mail a support@dotnetwork.it indicandoci la tua taglia e l'indirizzo di spedizione.  Non appena verificata la ricezione del pagamento provvederemo a spedirti la tua T-Shirt.  Le magliette sono disponibili nelle taglie S-M-L-XL-XXL (in caso di esaurimento di una delle taglie, indica quella di "Backup"). Grazie per IN-VESTIRTI con NOI!!!
.:DotNetWork Founders:.
    Stampa     


DotNetWork Forums
eseguire debug di un progetto che non è il primario
Ultimo Post 27 nov 2009 08.36 by Rudy (DNW TEAM). 4 Risposte.
Stampa immediata
Ordina:
PrevPrev ProssimoProssimo
Non sei autorizzato ad inviare una risposta.
Autore Messaggi

Posts:537

--
27 nov 2009 07.19  
Buongiorno a tutti.

ho una soluzione con X progetti.

in un progetto ho un metodo in una Form dove devo fare il Debug e ci metto un BreakPoint.
Compilo il progetto ed eseguo. Non ho capito come mai le modifiche a quel progetto me le ritrovo solo alla seconda esecuzione del debug ma questo non è un problema (avvio - chiudo - avvio il debug). nel momento in cui vado su quel metodo, il break point non funziona. Non so come mai a volte funziona e a volte no..
Qual'è il modo giusto per debuggare un metodo di un progetto che non sia il primario della soluzione?

Dato che sto scrivendo di debug, è possibile evitare di riavviare due volte il debug per testare altri progetti di una soluzione?

Grazie.

Posts:657

--
27 nov 2009 08.15  

Di solito questo succede se tu imposti le reference alle dll compilate invece che ai progetti. Prova a verificare!

Rudy Azzan

Posts:537

--
27 nov 2009 08.22  
si. giusto.
Quando compilo una dll, viene copiata in una cartella predefinita e caricata in GAC.

Quindi mi conviene comunque caricare in GAC la DLL ma referenziare il progetto invece della DLL.

A questo punto non conviene caricare in GAC la DLL.

Grazie.

Posts:537

--
27 nov 2009 08.23  
Scusa. Il bello è che a volte il break point funziona..e quello che mi fa pensare che sicruamente un sistema c'è.
Magari riavviare il debug si risolve referenziando il progetto...ma il debug?

Posts:657

--
27 nov 2009 08.36  

Si referenzia il progetto. Quando poi lo distribuisci lo puoi mettere in GAC, altrimenti ti succedono quelle cose li

Rudy Azzan
Non sei autorizzato ad inviare una risposta.

Active Forums 4.1
       
Articoli
Iniziare da zero con Visual Studio
Introduzione a .NET e Visual Studio
2007/07/29 | Autore: Sabrina Cosolo
Lavorare con gli Array
Il problema dello zaino
2007/07/29 | Autore: Alberto De Luca
Memorizzare immagini in SQL Server
un'immagine per la memorizzazione su un campo Image di SQL Server e viceversa
2007/09/04 | Autore: Sabrina Cosolo
Fritto Misto - Classi di uso comune (parte 5)
Helper: Eccezioni personalizzate e Messaggi compositi
2007/10/27 | Autore: Sabrina Cosolo
Introduzione a Windows Presentation Foundation (parte1)
La prima di una serie di traduzioni da articoli di MSDN o altre fonti che offrono un punto di partenza per iniziare a capire il WPF.
2007/07/29 | Autore: Patrizia Cosolo
Fritto Misto - Classi di uso comune(parte 3)
Helper: Due interfacce per implementare classi Entity
2007/10/22 | Autore: Sabrina Cosolo
Miniguida alla OOP con il .NET Framework- Parte II
Le Classi e l'Incapsulamento.
2008/10/09 | Autore: Alberto De Luca 
Copiare dati fra Database con ADO.Net
Da Qui a Li e da Li a Qui usando OleDb e Access
2009/02/14 | Autore: Sabrina Cosolo
    Stampa     
Home|Forums|Blogs|Mappa del sito
© 2007-2012 by DotNetWork  .:.  Condizioni d'uso  .:.  Privacy  .:.  Accedi  .:.