Newsgroup: it.comp.lang.visual-basic
Titolo: [VB.NET] Problema con settings su Class Library

Ciao
ho un progetto abbastanza grande che è strutturato in questo modo:
 
MioProgetto.exe è l'applicazione WinForm che serve per la gestione
MioProgetto.service.exe è il servizio che si occupa di recuperare i dati 
ad intervalli prestabiliti
MioProgetto.BLL.dll contiene la logica dell'applicazione
MioProgetto.DAL.dll classi di accesso al DB SQL Server
 
Nel progetto del DAL ho messo un file di configurazione con una sola 
proprietà SQLConnString con ambito applicazione.
Il problema è che MioProgetto.DAL.dll vede quella proprietà con la 
stringa impostata in fase di compilazione e sembra ignorare i 
cambiamenti che faccio nel file MioProgetto.DAL.dll.config
 
Se sposto i settings nell'applicazione Windows Form e cambio il relativo 
file MioProgetto.exe.config le modifiche vengono viste dall'applicativo.
 
Ho cercato un pò su Google e mi sembra di aver capito che per ovviare a 
tale problema c'è bisogno di costruirsi un provider personalizzato per 
la gestione dei settings...
 
E' un comportamento normale o mi sono perso qualcosa?
 
Ciao, Vincenzo
 
 

 E' un comportamento normale o mi sono perso qualcosa?
 
E' un comportamento normale: se applichi i metodi standard di lettura dei setting nel codice di librerie (ma anche di exe se vengono caricati dinamicamente da un altro exe) che vengono caricate dal codice di un eseguibile pricipale, questi accedono implicitamente al file .config dell'applicazione host, e quindi nel tuo caso al .exe.config e non al file .dll.config che può anche non esistere (se provi a cancellarlo, vedrai che l'applicazione non da errore)
 
Non hai necessariamente bisogno di definire un tuo provider dei settings, basta usare i metodi per indicare esplicitamente quali file caricare (ad es. OpenExeConfiguration, OpenMappedExeConfiguration ecc...)

 Ciao, Vincenzo
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 Ciao
io ho fatto simile/diverso:
un progetto RisorseIta.dll dove dentro ci sono più file risorse 
compilate e un po di logica per recuperare info.
 
una cosa stupidissima del tipo:
 
    Public Shared Function TrovaStringa(ByVal nomeRisorsaTesto As 
String) As String
        Dim ret As String
        Dim tasm As Assembly
        tasm = Assembly.GetExecutingAssembly
        Dim nomi() As String = tasm.GetManifestResourceNames
        Dim TMan As New 
Resources.ResourceManager("RisorseIta.Elementi", tasm)
        Try
            ret = TryCast(TMan.GetObject(nomeRisorsaTesto), String)
        Catch ex As Exception
            ret = Nothing
        End Try
        Return ret
    End Function
 
l'ho compilato con chiave pubblica identità e tutte le menate 
"dimodochè" anche un progetto 
asp.net
 sotto aruba sia "mangiato" senza 
problemi...
 
Nel progetto principale:
-1) O ti fai una dipendenza esplicita
-2) O te la cerchi con un po di reflection
-3) O ti studi una interfaccia generica con un oggetto terzo che 
gestisca una delle due cose sopra....
 
L'utilità?
Beh alla fine ci sono arrivato anche io.... immensa!....
Stringhe connessione, messaggi errore, grafica, logo cliente, testi 
delle licenze, documenti tipo, setting di default, warning , 
default...etc etc....
Prendo il progetto cambio ricompilo .... nel caso 2) scarico nella 
cartella la nuova dll ...e cambia parecchie cose "visive" nella app 
generale!
 
Non ho la soluzione forse ottimale....ma rispetto a mettere tutti i 
settings in un mdb (cosa anche questa comodissima...almeno sotto vb6) è 
una soluzione tecnologicamente "alla moda" !
 
-- 
----- Italliaaaaa 3227! -----
Guerrieriii....giochiamo a fare la guerraaa!.... 
Guerrieriii....giochiamo a fare la guerraaa!.... 
Guerrieriii....giochiamo a fare la guerraaa!....
 
I guerrieri della notte (1987)
 
 


Buongiorno Mauro,
innanzi tutto grazie per la tua risposta.
Non ho capito bene cosa intendi con "mergiati" all'interno del file 
config dell'applicazione. Potresti gentilmente farmi un esempio pratico?
 
Grazie anticipatamente.
Vincenzo


Dopo averti risposto ho trovato questa discussione:
http://usenet.it.rooar.com/showthread.php?t=488473
 
che è stata illuminante!!!
 
Ho seguito il tuo consiglio copiando i settings del progetto dll in 
quello UI e funziona tutto perfettamente.
 
Ciao, Vincenzo

 dell'applicazione. Potresti gentilmente farmi un esempio pratico?
 
yes :-)
 
il motore di configurazione di .net si basa sul concetto di "section", 
quindi un esempio di file di configurazione di un'applicazione è 
questo:
 
<configuration>
	<configSections>
		<section name="sampleSectionName"
                 type="-- Section handler full type name --" />
	</configSections>
 
    <sampleSectionName />
 
<configuration>
 
cosa vuol dire? che per dichiarare un nodo "sampleSectionName" devi 
prima aver dichiarto chi sarà il suo handler, un handler in soldoni è 
colui il quale è in grado di deserializzare quel nodo, un handler è una 
sorta di settings provider, non lo è veramente i settings provider sono 
un'altra cosa.
 
Ora, quando tu aggiungi dei settings in una dll quello che succede è 
che, se guardi nel file di consifgurazione della dll trovi una cosa 
molto simile a quella sopra, tranne che è racchiusa in un sectionGroup 
(ma poco importa):
 
<sectionGroup name="applicationSettings" 
type="System.Configuration.ApplicationSettingsGroup, System, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
    <section name="nomeDellaDll"
             type="System.Configuration.ClientSettingsSection, System, 
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 
requirePermission="false" />
</sectionGroup>
 
questo ti permette di dichiarare una sezione del tipo, il nome del 
section group è blindato non lo puoi cambiare:
 
<applicationSettings>
   <nomeDellaDll>
      <!-- Visual Studio mette i settings qui -->
   </nomeDellaDll>
</applicationSettings>
 
Ora, se metti tutto nel file di configurazione dell'applicazione il 
tutto funzionerà come ti aspetti, ergo il file di configrazione vince 
su quello della dll.
Quindi basta che dichiari il sectionGroup all'interno della config 
sections:
 
<configuration>
	<configSections>
       <sectionGroup name="applicationSettings" type="...." >
          <section name="nomeDellaDll" type="..." />
       </sectionGroup>
 
<!-- il resto delle zioni qui -->
 
	</configSections>
</configuration>
 
a questo punto puoi incololare ne file di configyurazione 
dell'applicazione la sezione di configurazione della dll.
 
E' un po' contorto all'inizio ma una vlta che hai capito il giochetto 
ti rendi conto che è la via più naturale perchè dal punto di vista del 
codice non ti cambia nulla, anzi fai tutto come se i settings fossero 
quelli giusti.


 quelli giusti.
 
Naturale fino ad un certo punto... se distribuisci un pacchetto in cui hai, per dire, due o tre eseguibili che utilizzano la medesima ClassLibrary, e vuoi che quella libreria segua i *SUOI* settings, indipendentemente dall'applicazione chiamante, ti tocca spargerli in giro per i vari .exe.config, il che non è proprio il massimo.
 
Per quello in quei casi preferisco usare i metodi che aprono un file di configurazione specifico...