Ho bisogno di avere una DLL di .NET 3.5 con il proprio file di configurazione. Questa DLL potrebbe essere chiamata da molte app diverse, quindi le informazioni (come le stringhe di connessione) memorizzate nel file di configurazione dovevano essere conservate in un file di configurazione a cui la DLL può fare riferimento. Quello che voglio è quando viene usata la DLL, ho bisogno di "cambiare" il file di configurazione che viene utilizzato per fare riferimento alle informazioni per essere il file di configurazione delle DLL. Quindi quando la DLL ha finito con l'utilizzo delle informazioni di configurazione, lo switch viene ripristinato a quello predefinito. La DLL è scritta utilizzando .NET 3.5. Ho cercato come fare questo e quello che continuo a trovare è come unire le informazioni con il file app.config di un exe. Nel mio caso, non so come verrà usata questa DLL per modificare i file app.config di exe. Questa soluzione deve essere indipendente. Tuttavia, le mie classi base utilizzate per creare la DLL (che contengono oggetti business) si aspettano di cercare la stringa di connessione e altre informazioni in un file di configurazione, ecco perché ho bisogno di "passare" al mio file di configurazione DLL nel momento in cui esso si accede e quindi si passa indietro in modo da non rovinare l'app exe che ha chiamato la DLL.. NET 3.5 DLL che utilizza il proprio file di configurazione
risposta
Il sistema di configurazione .NET 2.0 e up offre funzionalità, ad es. caricare un file di configurazione specifico su richiesta. È un po 'più di lavoro, ma funziona.
Avresti per fare qualcosa di simile:
// set up a exe configuration map - specify the file name of the DLL's config file
ExeConfigurationFileMap map = new ExeConfigurationFileMap();
map.ExeConfigFilename = "ConfigLibrary.config";
// now grab the configuration from the ConfigManager
Configuration cfg = ConfigurationManager
.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
// now grab the section you're interested in from the opened config -
// as a sample, I'm grabbing the <appSettings> section
AppSettingsSection section = (cfg.GetSection("appSettings") as AppSettingsSection);
// check for null to be safe, and then get settings from the section
if(section != null)
{
string value = section.Settings["Test"].Value;
}
È inoltre necessario assicurarsi che la configurazione per la DLL libreria di classi è in costruzione e copiato in una posizione in cui si può arrivare a questo. Nel peggiore dei casi è necessario specificare un file di configurazione specifico e assicurarsi che venga copiato nella directory di output impostando la proprietà "Copia nella directory di output" nella finestra delle proprietà di Visual Studio.
Si dovrebbe anche controllare serie in tre parti di Jon Rista su .NET 2.0 di configurazione su CodeProject.
- Unraveling the mysteries of .NET 2.0 configuration
- Decoding the mysteries of .NET 2.0 configuration
- Cracking the mysteries of .NET 2.0 configuration
Altamente raccomandato, ben scritto e estremamente disponibile!
Marc
La risposta più semplice sarebbe inserire i valori in machine.config. In questo modo tutte le app che usano la dll potranno accedere alle informazioni attraverso le classi di configurazione dell'app .net. In questo modo, se è assolutamente necessario sovrascrivere un valore per una determinata applicazione, è possibile sovrascriverlo nel file app.config dell'applicazione principale.
Per questo scopo non è possibile utilizzare il sistema di configurazione .Net integrato. È progettato (come dovrebbe essere) per configurare i processi dell'applicazione, non le DLL individuali. Il modo corretto per fare questo è aggiungere le impostazioni di configurazione per la DLL nel sistema app.config per ogni applicazione eseguibile che "utilizza" (ha un riferimento a) quella dll. (O nel machine.config)
- semplicemente facendo le impostazioni accessibili a TUTTE applictions che uset ha dll può essere realizzato da loro mettendo in Machine.config (in C: \ WINDOWS \ Microsoft. NET \ Framework \ v2.0.50727 \ CONFIG per .Net2.0
Se non si vuole fare in questo modo, allora si dovrà scrivere il proprio codice per aprire, leggere e scrivere frm un file Xml personalizzato, (o qualsiasi formato tu decida di utilizzare) per sottrarre queste impostazioni.
ah, è possibile - è un po 'di lavoro, e non è così grande e senza soluzione di continuità, come la storia app.config - ma funziona. E il più delle volte, sono d'accordo - l'app host dovrebbe fornire la configurazione. Vedo casi anche se una config specifica di libreria separata può avere molto senso. –
Generalmente quando si hanno impostazioni a livello di applicazione, è necessario generare tali impostazioni a livello di applicazione e quindi filtrarle attraverso le librerie. Aggiunge alcune altre righe di codice all'inizializzazione per iniettare le dipendenze, ma in sostanza si sta tentando di farlo comunque.
Ti imbatterai in più problemi del suo valore se proverai a includere un file di configurazione per la sola dll affianco ad ogni distribuzione della tua libreria, e non ha molto senso semanticamente .
Prendere System.Data ad esempio ... quando si crea una connessione, si specifica la stringa di connessione, non si crea un file di configurazione separato solo per la stringa di connessione da distribuire fianco a fianco con la libreria System.Data. [e ciò causerebbe un sacco di problemi poiché probabilmente risiede nel GAC sul sistema in ogni caso]
So che questo post è un po 'vecchio, ma ho voluto buttare i miei 2 centesimi. Mentre in casi può, mi sarebbe d'accordo che l'applicazione deve fornire le impostazioni, non la DLL. Ho trovato una situazione in cui le configurazioni specifiche di dll sembrano essere più desiderabili.
Usiamo la programmazione/compito applicaiton Quartz.NET. Abbiamo sviluppato un'interfaccia per creare e monitorare i lavori contro il server Quartz. Una delle grandi cose su Quartz.NET è che si creano i programmi di "lavoro" e compilarli in DLL e poi semplicemente li cadere nella cartella del server Quartz.NET e attraverso la riflessione e tale, quarzo è in grado di iniziare a utilizzare la nuova DLL senza ulteriori modifiche al server Quartz ... se non ci sono informazioni che devono essere conservate nei file di configurazione.
Con server di quarzo se si dispone di tutte le informazioni di configurazione specifica che dovrebbe essere tenuto in un file di configurazione, bisogna mettere nel file di configurazione Quartz.NET. Abbiamo creato diverse applicazioni "di lavoro", ognuna con i propri bit di informazioni di configurazione, quindi ora il nostro file di configurazione Quartz.NET è pieno di tutte queste impostazioni non correlate. Avere un file di configurazione specifico dll ridurrebbe di molto la confusione del server Quartz.NET. L'unica altra opzione che vedo è aggiungere tutte queste impostazioni individuali in una tabella DB delle impostazioni, ma per il consolidamento e la manutenzione del codice, per i nostri scopi, sono preferibili i singoli file di configurazione.
Basta gettare che là fuori a cui pensare.
Hmm .... Questa non è davvero una risposta, ma lo trovo un commento perspicace ... – nalply
Sembra promettente usare questo approccio. Ho una domanda però, non devo "annullare" questo? La mia configurazione DLL sarà la configurazione "predefinita" per la ricerca? – user31673
No: è necessario richiedere esplicitamente un oggetto "Configurazione" dal ConfigurationManager e solo se si lavora su questo oggetto separato si otterranno quelle impostazioni separate. –