[VB.NET] Installazione SP1 e cambiamento modalità di debug

[simon78_soft]

Ho installato il SP1 per .NET 2005 ed ho riscontrato uno strano comportamento delle mie applicazioni.
Premesso che tutto funzionava correttamente prima di installare il SP, ora succede che se modifico una delle mie dll ed aggiungo ad esempio una variabile pubblica, il debug mi da' errore!!! Dice che e' necessario ricompilare tutto cio' che fa riferimento a tale libreria (anche dopo aver fare un Rebuild All dell'applicazione!!!).
Nell'eseguibile non ci sono segnalazioni pero' non viene considerata la modifica a tale libreria!

Qualcuno sa darmi una spiegazione logica? O meglio una soluzione al problema?
Ho cercato su MSDN ma purtroppo non ho trovato niente a riguardo...

[simon78_soft]

Penso si riproponga di nuovo il problema che c'era su VB 6. Con questa patch diventa nuovamente indispensabile instanziare le librerie con CreateObject... l'associazione diretta, come riferimento, da' gli stessi problemi di VB 6 dovuti ai riferimenti sulla vecchia libreria compilata!!!
Se trovate soluzioni migliori vi prego segnalarle... io per il momento penso di risolvere cosi'!

[alka]

Non vedo alcuna attinenza del tuo problema con quello citato di VB6.

Ci sono due lati oscuri: stai parlando di debugging, quindi suppongo che le modifiche vengano fatte durante l'esecuzione della tua applicazione; inoltre, parli di variabile globale che, in un certo senso, è un termine improprio visto che l'architettura .NET è totalmente orientata agli oggetti.

Ciò che avviene lo ritengo normale e, tutt'al più, era insano che non venisse notificato prima.

Aggiungere o modificare costanti ad ampia visibilità durante il debugging porta inevitabili ripercussioni sulla logica del programma, quindi l'avvertimento di Visual Studio è più che legittimo.

Se le cose non stanno così, spiega meglio la tua situazione.

Ciao!

[simon78_soft]

Originariamente inviato da alka
Non vedo alcuna attinenza del tuo problema con quello citato di VB6.

Ci sono due lati oscuri: stai parlando di debugging, quindi suppongo che le modifiche vengano fatte durante l'esecuzione della tua applicazione; inoltre, parli di variabile globale che, in un certo senso, è un termine improprio visto che l'architettura .NET è totalmente orientata agli oggetti.

Ciò che avviene lo ritengo normale e, tutt'al più, era insano che non venisse notificato prima.

Aggiungere o modificare costanti ad ampia visibilità durante il debugging porta inevitabili ripercussioni sulla logica del programma, quindi l'avvertimento di Visual Studio è più che legittimo.

Se le cose non stanno così, spiega meglio la tua situazione.

Ciao!

Scusa, non parlo di modifica durante il "debugging"... quello sarebbe normale!
Io creo il riferimento ad una dll "globale" (intendo che viene utilizzata in ogni parte del progetto) su ogni exe e dll del mio progetto.
A questo punto aggiungo una variabile "public" nella libreria "globale" e quindi eseguo... crash!!!
Spero di aver chiarito il problema...

[alka]

Originariamente inviato da simon78_soft
A questo punto aggiungo una variabile "public" nella libreria "globale" e quindi eseguo... crash!!!

"Crash" è traducibile con...? C'è un messaggio di errore? Un avvertimento?

[simon78_soft]

In effetti mi sono spiegato abbastanza male... chiedo scusa!

Allora, facciamo un esempio pratico di applicazione:

ho un exe che chaimiamo E.exe e tre dll A.dll B.dll e GLOBAL.dll

GLOBAL.dll e' una libreria che contiene costanti e variabili globali per tutto il progetto!

E.exe - A.dll - B.dll hanno tra i riferimenti GLOBAL.dll

Quindi in E.exe ho questa dichiarazione

-------------------
Dim VariabiliGlobali as new GLOBAL.dll (ovviamente avro' la classe global.variabili per esempio)
-------------------

in A.dll e B.dll ho questa dichiarazione

-------------------
PUBLIC VariabiliGlobali as GLOBAL.dll (anche qui avro' la classe global.variabili per esempio)
-------------------

Quando io richiamo A.dll o B.dll da E.exe ho questa dichiarazione

-------------------
dim dll as new A.dll (anche qui dichiaro la classe A.form per esempio)

dll.VariabiliGlobali = VariabiliGlobali
-------------------

fin qui funziona tutto correttamente...

Se io a questo punto nell classe "Variabili" della libreria "GLOBAL.dll" aggiungo una variabile per esempio

-----------------
PUBLIC NuovaVariabile as String
-----------------


quindi cerco di utilizzarla sull'exe o una dll esempio:

-----------------
dim StringaVar as String
StringaVar=VariabiliGlobali.NuovaVariabile
-----------------


appena eseguo il debug ed arriva all'istruzione ho questo messaggio (con tanto di indicazione di MSDN...):

---------------------------------------
Public member 'NuovaVariabile' on type 'Variabili' not found.

If a member in a class library has been removed or renamed, recompile any assemblies that reference that library.
This exception is typically thrown when a field or method is deleted or renamed in one assembly, and the change is not reflected in a second assembly that is trying to access the missing member.

If you are attempting to access members on a late-bound object variable, make sure it is declared Public.
Protected, Friend, and Private variables cannot be late-bound in Visual Basic.
---------------------------------------

Avete una soluzione? Credo ora sia facilmente riproducibile, purtroppo non capisco come possa essere risolto... senza SP utilizzavo le stesse identiche librerie e aggiungo e modifico spesso variabili globali...
Ovviamente ho provato il "Rebuild All" il "Clear Solution" ma niente, stesso problema... non vorrei essere costretto a disinstallare il SP...

[mardok30]

Premetto che non conosco la soluzione... vorrei solo spiegare, a parole mie la questione:
Da una parte c'è l'applicazione e dall'altra un progetto che crea una DLL, se io creo la DLL e la referenzio nell'applicazione tutto funziona ma, nel momento in cui io faccio una qualsiasi modifica alla DLL, la ricompilo e la sostituisco(p.es. facendo un copia e incolla, taglia...) con quella "vecchia" che ho referenziato nell'applicazione, le modifiche apportate nella nuova DLL non sono visibili dall'EXE se non si elimina la referenza alla vecchia DLL e si crea una nuova referenza alla "nuova" DLL(tutto questo nel Progetto dell'applicazione tramite IDE di Visual Studio). Spero di aver dato una chiara spiegazione del problema sperando che qualcuno conosca la soluzione... in mancanza di tale soluzione il metodo di eliminare la referenza alla vecchia DLL e riferenziare la nuova DLL è sempre valido(sicuramente non è il massimo, però...)
Ciao

[alka]

Originariamente inviato da simon78_soft
Avete una soluzione? Credo ora sia facilmente riproducibile, purtroppo non capisco come possa essere risolto... senza SP utilizzavo le stesse identiche librerie e aggiungo e modifico spesso variabili globali...

Diciamo che i nomi attribuiti nell'esempio alle classi prelevate dalle librerie esterne sono un po' fuorviante, ad ogni modo, se ho capito bene, tu sei nella condizione in cui:

a)
hai una DLL di base contenente classi e tipi di dato eventuali;

b)
hai più DLL che referenziano la DLL di base per accedere ai tipi in essa contenuti e ai rispettivi membri;

c)
hai un eseguibile che accede alle DLL e a quella di base comportandosi analogamente al punto b).

Se la situazione è questa, l'unico suggerimento che posso darti è ricontrollare i riferimenti di ciascun progetto relativamente alle altre librerie: è possibile che vi sia un aggiornamento o una copia in locale mancante che fa sì che una delle librerie o l'eseguibile facciano riferimento alla vecchia versione della DLL di base.

Modifica eventualmente le versioni associate alle librerie, e controlla di non averne in GAC (non si sa mai) e solo in seguito ad un accurato controllo esegui un "Build All".