ERRORI PIU' FREQUENTI

 

Errore durante la gestione delle form 

Quasi tutte le form di Gea.Net sono ereditate da GestForm.Vb o BaseForm.Vb. Queste due form genitrici sono presenti nella libreria Clsb_BaseForm.dll cioè in un progetto esterno a quello dove solitamente risiedono le form dell’applicazione. Si noti poi che ClsB_BaseForm.dll dipende da ClsB_Base.dll. 

Questo può essere causa di un problema che Visual Studio 2005 non riesce a risolvere la dipendenza ovvero aprendo la form, VS2005 cerca la form padre che risiede su una libreria diversa che può essere stata compilata in tempi precedenti  e non si ha più compatibilità tra gli oggetti. 

  

La documentazione in proposito è piuttosto scarsa anche da ricerche fatte sul sito Microsoft o su comunità di sviluppatori pertanto le successive indicazioni sono frutto di esperienze fatte sul campo piuttosto che informazioni ricavate da documentazioni tecniche. Come tali possono apparire lacunose ma in ogni caso sono risolutive.  

Per risolvere questo problema si deve agire per step successivi fino a fare in modo che la form a cui si desidera apportare modifiche riesca ad agganciare correttamente la form padre. 

  1.  Salvare l’attività e chiudere tutte le form del progetto

  2. Ricompilare nell’ordine ClsB_Base e ClsB_BaseForm

  3. Provare a riaprire la form da gestire. Se ancora compare l’errore, chiudere la form e VS2005m, riaprire VS2005 e riprovare.

  4. Se ancora compare l’errore ripetere il punto 2, chiudere e riaprire VS2005 e riaprire la form.

  5. Se si presenta ancora l’errore è necessario eliminare tutte le dll generate (ClsB_Base*.dll) e sparse in tutte le sottocartelle di ClassNet. Prima di eliminarle potrete notare che hanno data di creazione antecedenti alla data attuale. In pratica, fino ad ora il compilatore ha ignorato le vostre richieste di rigenerare tali librerie perché riconosce come valida e attuale una dll compilata giorni prima perdendo il riferimento con le altre librerie del progetto. Ora che avete eliminato le ClsB_Base*.dll, ricompilando l’intera soluzione costringerete VS2005 a ricrearle finalmente corrette.

In alcuni casi (a meno che non si arrivi all’ultimo punto) il compilatore potrebbe risolvere autonomamente il problema anche se non avete effettuato alcun intervento per risolvere la situazione. Questo si verifica ad esempio in conseguenza di una modifica apportata su una delle librerie in questione.

 

Errore a runtime durante l’apertura di una Window WPF 

Durante la compilazione delle form WPF (Windows Presentation Foundation) viene creato un file con estensione .g.vb  per ogni form e depositato nella cartella \obj come una risorsa dell’applicazione.

Ad esempio per la form Cont02dt.xaml viene generato Cont02dt.g.vb.

Visual Studio 2008 in alcuni casi (ad esempio se sono state manipolate le date di creazione) considera valida la risorsa precedentemente compilata e non provvede a rigenerarla ex novo. Nel caso sia stato modificato l’xaml di origine non vi è più corrispondenza binaria e al momento di creazione della form precedente alla sua visualizzazione (Richiamo a “InitializeComponent” nella funzione New) si verifica il crash di cui sotto. 

 

La soluzione più immediate consiste nel cancellare la cartella \obj , in questo modo obblighiamo Visual Studio a ricompilare tutte le risorse. 

Errori durante la compilazione

Potrebbe capitare che la compilazione di un oggetto non possa avvenire perché lockato dall’esecuzione in corso di un’altra istanza di Gea.Net ma anche da VisualStudio stesso.

Mentre nel primo caso è sufficiente chiudere l’esecuzione aperta con altra istanza, qualora il lock sia eseguito dallo stesso VisualStudio le cose sono più problematiche.

In questo secondo caso può capitare che la prima compilazione avvenga con successo mentre la seconda genera l’errore sotto riportato e non rimane che chiudere e riaprire VisualStudio.

 

 

Errori sugli User Control condivisi

Alcuni oggetti e soprattutto i controlli utente, sono distribuiti su più progetti della solution Gea.Net. Capita che nel caso di modifica di uno di questi oggetti condivisi, Visual Studio non sia in grado di riconoscere la modifica sullo stesso oggetto linkato da un altro progetto.

Gli errori sono generati anche in casi di ricompilazione e lo stesso oggetto non può essere aperto da due progetti diversi.

Al momento l’unica soluzione è fare il refresh dell’intera solution o al più riaprire Visual Studio.

 

Errori su Zip.vb di Cls_Sistema

Il file zip.vb viene utilizzato per compattare/scompattare e si avvale dei servizi di ICSharpCode.SharpZipLib.dll.

Questo file è aggiunto ai references del progetto tuttavia viene linkato dalla cartella di deposito degli oggetti compilati (\bin). In alcuni casi, durante la compilazione, questa dll viene rimossa dal compilatore di Visual Studio e di conseguenza viene a mancare il link con la dll indicata.

La soluzione è ricopiare nuovamente la libreria nella sede originale e riassociare la referenza. Per avere una soluzione definitiva può essere copiata la libreria nella cartella dei sorgenti ed eseguire il link ai references da tale posizione.

 

Problemi durante il porting a Visual Studio 2010

Il porting a Visual Studio 2010 sostituisce automaticamente l’uso del Framework 3.5 con il 4.0 in sede di compilazione. Possiamo rinunciare a questa conversione semplicemente andando nelle proprietà di ogni progetto, scegliendo la Tab “Compilazione” quindi “Opzioni di compilazione avanzate” scegliendo “Framework 3.5” nel campo “Framework di destinazione”, tuttavia se decidiamo di utilizzare la versione più evoluta dobbiamo ricordarci alcuni punti : 

1) System.XAML

Alcuni assembly sono stati riorganizzati pertanto se il nostro progetto usa Wpf  dobbiamo inserire nei progetti il riferimento a System.XAML . Questa informazione ci viene evidenziata anche nella lista di errori. 

2) System.Reflection.Assembly.UnsafeLoadFrom

Il framework 4.0, al contrario delle versioni precedenti, di default considera non sicuri gli assembly che risiedono sulla rete anche se posizionati all’interno di una cartella con diritti fulltrust. Questo comporta che utilizzando la reflection per accedere ad un assembly durante il caricamento per mezzo del metodo LoadFrom potremmo ricevere l’ errore : 

{"Could not load file or assembly 'file:///[nome_assembly]' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)":"file:///[nome_assembly]"} 

Per fare funzionare il tutto come nella versione precedente occorre sostituire il comando :

System.Reflection.Assembly.LoadFrom

Con  il comando :

System.Reflection.Assembly.UnsafeLoadFrom

3) Riferimenti non disponibili

Il nuovo ambiente è più “permaloso” e non ci consente di compilare un assembly se al suo interno ci sono riferimenti ad assembly non presenti sul PC. Questa nuova caratteristica lascia spiazzati in quanto non viene data nessuna segnalazione. Semplicemente non viene compilato, e quindi distribuito, l’assembly.

Per evitarci qualche mal di testa è fondamentale togliere tutti i riferimenti che non sono disponibili sul nostro PC. Per quanto riguarda Gea.Net, questo problema potrebbe essere causato da ClsB_Office che ha il referimento a Microsoft.Office.Core, MSProject, MSPWIFLib, Excel, ecc.

La cosa è particolarmente noiosa se ci capita di cambiare spesso ambiente o postazione di lavoro. Attenzione quindi a non esagerare. Non togliere riferimenti che vengono usati dal progetto solo perchè inavvertitamente è stata cancellata l’assembly o perchè si è su un PC non di sviluppo. 

4) Ricompilare la soluzione

L’ultimo è il consiglio della mamma per evitare di perdersi in un bicchiere d’acqua. Se sono state eseguite alcune modifiche ad assembly agganciati a progetto principale è bene ricompilare ogni singolo progetto modificato oppure fare un "Ricompila Soluzione". Se siamo intervenuti agganciando o sganciando riferimenti ma non abbiamo apportato modifiche ai file del progetto, VS2010 non ricompila di sua iniziativa.