2011-12-22 3 views
5

Uso la versione beta di Wix 3.6 dalla riga di comando, non come progetti VS. Ho un'applicazione web che viene raccolta con calore come directory. Questo funziona. Sto usando le trasformazioni web.config per gestire ciascuno dei file web.config dell'ambiente di destinazione. Questi sono prodotti con msbuild, questo funziona e mantiene le cose visibili in Visual Studio e nel controllo del codice sorgente.Utilizzo di Wix come è possibile distribuire uno dei diversi file web.config durante l'installazione di un'applicazione Web ASP.net

Ho riscontrato un problema durante l'implementazione di uno dei numerosi file web.config che includo manualmente in product.wxs come componenti con condizioni. Mi aspettavo di includere tutti i componenti come funzionalità distribuibili e lasciare che le condizioni selezionassero solo una come attiva. Per esempio:

 <DirectoryRef Id="wwwroot"> 
     <Component Id="setup_a" Guid="some_guid" > 
      <File Source="$(var.ConfigSourceDir)\setup_a\web.config" /> 
      <Condition>ENVIRON = setup_a</Condition> 
     </Component> 

     <Component Id="setup_b" Guid="some_guid" > 
      <File Source="$(var.ConfigSourceDir)\setup_b\web.config" /> 
      <Condition>ENVIRON = setup_b</Condition> 
     </Component> 

Questo non ha creato alcun file di ridenominazione, lo spostamento o l'eliminazione di problemi, ma ha il problema molto fondamentale che più file web.config vengono mappati per la stessa destinazione e questo mi dà un errore di luce "Product.wxs (xxx): errore LGHT0091: trovato il simbolo duplicato 'File: web.config' Ciò significa in genere che un ID è duplicato. Verificare che tutti gli identificatori di un determinato tipo (File, Componente, Caratteristica) sono unici. "

Un approccio alternativo è stato quello di utilizzare diversi file denominati .config e rinominare/spostare uno per essere web.config, quindi qualcosa di simile:

 <DirectoryRef Id="wwwroot"> 
       <Component Id="setup_a" Guid="some_guid" > 
       <File Id="setup_a.config" Source="$(var.ConfigSourceDir)\setup_a.config" /> 
       <CopyFile Id="moveit" SourceDirectory="wwwroot" SourceName="setup_a.config" DestinationDirectory="wwwroot" DestinationName="web.config" /> 
       </Component> 

Questo non genera un errore, il bot CopyFile il comando non fa nulla. Ho appena ottenuto setup_a.config nella cartella wwwroot.

Se nido CopyFile all'interno del file, l'azione di copiatura funziona allora:

 <DirectoryRef Id="wwwroot"> 
       <Component Id="setup_a" Guid="some_guid" > 
       <File Id="setup_a.config" Source="$(var.ConfigSourceDir)\setup_a.config" > 
        <CopyFile Id="moveit" DestinationName="web.config"/> 
       </File> 
       </Component> 

... ma CopyFile nidificato significa che non posso aggiungere (è annullato) l'attributo = Elimina "sì" a creare un'azione "sposta". Invece sono rimasto con setup_a.config e web.config nella cartella wwwroot. In alternativa, se aggiungo un RemoveFile separato all'interno dello stesso elemento costitutivo lo fa anche altro:

<RemoveFile Id="removefile" On="install" Directory="wwwroot" Name="setup_a.config"/> 
</Component> 

Quindi, sto sperando in un esempio funzionante di come gestire più file web.config in una distribuzione condizionale, che non lascia file alle spalle. il nome file di destinazione di web.config viene risolto dal framework e non può essere modificato. Le diverse configurazioni sono anche pre-generate al di fuori di wix usando le trasformazioni di configurazione, anche queste non possono essere modificate ma i nomi dei file generati potrebbero essere qualsiasi cosa.

evviva!

risposta

7

Lo complichi troppo. Questo dovrebbe funzionare:

<Component Id="setup_a" Guid="some_guid" > 
     <File Name="web.config" Id="config_a" Source="$(var.ConfigSourceDir)\setup_a\web.config" /> 
     <Condition>ENVIRON = setup_a</Condition> 
    </Component> 

    <Component Id="setup_b" Guid="some_guid" > 
     <File Name="web.config" Id="config_b" Source="$(var.ConfigSourceDir)\setup_b\web.config" /> 
     <Condition>ENVIRON = setup_b</Condition> 
    </Component> 

prestare attenzione a un paio di cose qui:

  • File/@ nome è lo stesso - questo è il nome del file di destinazione che si desidera avere (web.config)
  • File/@ Id è diverso per ogni file, al fine di evitare l'errore luce che hai menzionato prima
  • File/@ sorgente può essere qualsiasi cosa - descrive proprio quello file da prendere come fonte

In questo esempio la luce si lamenterà ancora con l'avviso LGHT1076, ma questo è solo un avvertimento: si presta attenzione che le condizioni DEVONO essere mutuamente esclusive per evitare problemi.

+0

Ahhhh la mancanza di un attributo di nome stava rovinando i miei elementi di file, facendomi pensare che questo non avrebbe funzionato. Il tuo esempio ha funzionato, grazie Yan. –

+1

Lo faccio un po 'più pulito (evitare gli avvisi di convalida ICE). Autorizzo i componenti/file come web.config-a e web.config e quindi utilizzo un elemento CopyFile per clonarlo su web.config. GHIACCIO bello e pulito. Il rovescio della medaglia è un file extra sulla scatola. Upside è il file che mi dà un indizio visivo su quale scelta sia stata fatta e una copia dei file vergini nel caso qualcuno ritocchi il web.config e io voglio confrontare/ripristinare. –

2

Di solito ho un approccio diverso. Piuttosto, inserendo più file che si escludono a vicenda in un programma di installazione strettamente collegato a istanze specifiche, inserisco un file generico nel programma di installazione e utilizzo le modifiche XML per trasformare l'XML con i dati del punto di variazione come la stringa di connessione e cosa no.

Ciò consente di creare installatori che possono essere distribuiti ovunque in modo silenzioso passando semplicemente alcune proprietà e la riga di comando.