2010-04-30 14 views
5

Ho una soluzione .NET con un progetto di installazione che genera un MSI. Uno dei progetti installati da MSI contiene un file App.Config. Sembra che i valori di quel file di configurazione siano incorporati nell'MSI in fase di compilazione. C'è un modo per ignorarli al runtime?Sovrascrivere le impostazioni di app.config incorporate in un MSI?

Ad esempio, l'App.Config con cui sto lavorando imposta l'URL di un servizio Web a cui l'installatore comunica. È possibile sovrascrivere questo URL in fase di runtime, in modo che non debba ricompilare l'MSI se l'URL cambia?

Aggiornamento: Credo che quello che sto chiedendo è, posso copiare un file app.config, con un certo nome, nella mia directory di installazione in modo tale che esso avrà la precedenza, in fase di esecuzione, le impostazioni incorporati nel MSI ?

So che posso ridisegnare il codice per verificare la presenza di sostituzioni in altri luoghi, come il registro o un percorso di file di testo noto, ma la mia necessità immediata è di risolvere questo problema senza una ricompilazione. (Ci sono molti dischi di installazione nelle mani degli utenti)

risposta

1

Abbiamo avuto una simile sfida nello sviluppo dell'applicazione a cui sto attualmente lavorando. Volevamo essere in grado di avviare una nuova installazione la prima volta preconfigurata con le impostazioni trasferite da un'altra macchina o un'utilità di configurazione. Onestamente non so quanto sia buona la nostra soluzione nel grande schema, ma posso dirti cosa abbiamo fatto, che funziona per noi, per ora.

Nel nostro caso, molte di queste impostazioni si trovano nel file app.config, che non è consigliabile provare e manipolare dall'esterno dell'applicazione stessa. Può essere fatto, ma è pericoloso in molti modi sottili. Se così non fosse, l'opzione migliore sarebbe probabilmente quella di aggiungere una "azione personalizzata" per il progetto di installazione che inserisca i dati nel file, nel database o in qualsiasi altra cosa stessimo utilizzando per memorizzare le nostre impostazioni. Un punto di partenza per come farlo può essere trovato in MSDN.

Ma dal momento che non era un'opzione, abbiamo deciso che probabilmente il modo più semplice per ottenere i dati attraverso l'installazione nell'app, senza doverli includere nel pacchetto di installazione, sarebbe utilizzare un file "ride-along". Questo è un file di cui l'installazione è a conoscenza, ma che non è incorporato nel .MSI. Deve semplicemente trovarsi in una posizione nota rispetto a .MSI quando si installa. Dici al progetto di installazione che cos'è quel file, dove dovrebbe essere e dove metterlo. Quindi l'applicazione può verificare la sua esistenza all'avvio e processare qualsiasi cosa trovi lì. Nel tuo caso questo sarebbe un override dell'impostazione dell'URL. Quindi l'app può eliminare il file, quindi non viene caricato ogni volta che viene avviato.

Nel progetto di installazione, il file dovrà disporre di alcune proprietà impostate per garantire che funzioni correttamente con lo stile del pacchetto prodotto da un progetto di installazione VS.Assicurati di averlo impostato oppure potresti ricevere errori o altri comportamenti strani quando il file ride-along viene escluso perché non è necessario.

  • Condizione: Non reinstallare
  • PacakgeAs: vsdpaLoose
  • Vital: False

noi chiamiamo i nostri AutoImport.Settings.xml file. Questo è un file XML personalizzato che memorizza tutti i dati che vogliamo essere in grado di inizializzare la nostra app con quando è installata. Segue lo stesso formato che usiamo quando esportiamo/importiamo manualmente le configurazioni dall'applicazione in fase di esecuzione e utilizza lo stesso meccanismo. Lo fa automaticamente all'avvio, se trova il file lì. Questo ci consente di configurare una macchina "prototipo" con tutte le impostazioni specifiche della rete che vogliamo che siano, esportare tali impostazioni e quindi inviare lungo il file di importazione per il caricamento automatico con qualsiasi altra installazione che facciamo in quell'ambiente di rete.

Come ho detto, sembra che ci dovrebbe essere un modo "migliore". Gli unici a cui potevamo arrivare significava partire dai meccanismi app.config e user.config, che hanno i loro benefici. Quindi alla fine abbiamo deciso che questa era l'alternativa di minor attrito che rispondeva pienamente ai nostri bisogni.

+0

Grazie per i suggerimenti. Questa app è installata tramite CD, quindi aggiungere o modificare il file di guida può essere difficile, quindi penso che una soluzione migliore per le mie esigenze sarebbe quella di modificare il codice di installazione per controllare una chiave di registro nota per un valore predefinito. Il mio obiettivo principale era quello di scoprire se l'MSI avrebbe cercato automaticamente un file di un certo nome di percorso e sembra che tu stia dicendo "No, devi farlo da solo". Non è la risposta che volevo, ma comunque una risposta :) –

0

Se è necessario che l'installatore parli con un servizio Web, dove intendi memorizzare l'URL, se non nell'installer stesso?

Se si dispone di un luogo ben noto in cui cercare l'URL (un URL "costante", database, condivisione file ecc.), È possibile includere il relativo indirizzo nel programma di installazione. Altrimenti non c'è posto per ottenere l'URL da ...

0

Se si espone l'url come proprietà pubblica (cioè qualsiasi proprietà nella tabella Proepritti che è tutto in maiuscolo è considerata pubblica - non so se hai questo livello di controllo in un progetto di installazione in VS), quindi puoi impostarlo dalla riga di comando quando esegui MSI. Questa non è una buona soluzione a lungo termine per il tuo problema particolare - forse un'idea migliore è quella di stabilire una connessione iniziale con un indirizzo conosciuto che non cambierà, e può restituire l'indirizzo corrente del servizio web reale che desideri parlare a.

+0

L'URL in questione _è_ "l'indirizzo conosciuto che non sta per essere modificato", è dove l'installer scarica altri dati di configurazione da. Il problema è che questo URL è cambiato dopotutto :) –

+0

Quindi potresti essere nel punto in cui devi mordere il proiettile e ricostruire l'MSI (supponendo che sia impossibile eseguire qualsiasi tipo di reindirizzamento automatico sul server di hosting di il servizio web originale). – slugster

Problemi correlati