2013-04-25 18 views
7

Ho scaricato SlowCheetah in una vecchia applicazione Web .Net 3.5 per aggiungere trasformazioni a web.config.Utilizzo di SlowCheetah Config Trasforma su Web.config in un'app di Web Forms 3.5

Ho usato SlowCheetah con i servizi di Windows e le applicazioni della console per trasformare app.config con successo in passato. In questi casi, la configurazione viene trasformata e collocata nel cestino come ApplicationName.exe.config.

Tuttavia, con questa applicazione di moduli Web, il file di configurazione non finisce mai nel cestino, poiché i siti Web con moduli vengono creati con solo .dll nel cestino e IIS punta alla directory root per eseguire il sito. Quindi, anziché il web.config che viene incluso nel processo di compilazione e impacchettato nel cestino, viene lasciato solo nella posizione di root.

Nessuna trasformazione viene applicata a web.config nella directory principale, il che è una buona cosa, poiché il web.config nella directory root è nel controllo del codice sorgente ed è il file su cui viene eseguita la trasformazione.

Sarei felice di includere il web.config nella build in modo che slowCheetah lo trasformi e lo faccia cadere nel cestino. Dovremmo quindi estrarlo manualmente dal cestino e rimetterlo a livello di root sui nostri server, ma varrebbe la pena avere le trasformazioni.

Qualcuno sa come far funzionare le trasformazioni contro il mio web.config o farlo includere nel processo di compilazione in modo lentoCheetah può funzionare la sua magia?

Grazie!

Aggiornamento

ho modificato le proprietà del web.config ed è ora incluso nella build, però, le trasformazioni non sono ancora applicate ad esso.

Corporatura Azione: Risorsa incorporata

Copia Direttore di uscita: Copia sempre

risposta

5

Soluzione

ho rinominato il web.config nel nostro controllo di origine per Web.template.config e aggiunte trasformazioni Web.template.Debug.config e Web.template.Release.config

Quindi, scaricare il file di progetto e modificare il file .csproj xml aggiungendo i seguenti elementi

Ciò crea un nuovo file Web.config nella directory principale. Woot!

<PropertyGroup> 
    <PrepareForRunDependsOn> 
    $(PrepareForRunDependsOn); 
    WebConfigTransform; 
    </PrepareForRunDependsOn> 
</PropertyGroup> 
<Target Name="WebConfigTransform"> 
    <Message Text="Configuration: $(Configuration): Web.template.$(Configuration).config" /> 
    <TransformXml Source="Web.template.config" 
       Transform="Web.template.$(Configuration).config" 
       Destination="Web.config" /> 
</Target> 
1

trovato una soluzione migliore - uno senza rinominare i file di .template.config.

Incollare quanto segue nel file .csproj di Web Form.

<Target Name="BeforeBuild"> 
    <Delete Files="$(TEMP)\Web.TEMP.config" /> 
    <Copy SourceFiles="Web.config" DestinationFiles="$(TEMP)\Web.TEMP.config" /> 
    <TransformXml 
     Source="$(TEMP)\Web.TEMP.config" 
     Transform="Web.$(Configuration).config" 
     Destination="Web.config" /> 
    </Target> 
+0

Il problema qui è che si crea un riferimento circolare. Supponi di avere una trasformazione che inserisce elementi. La prima volta che viene eseguito, prende ciò che c'è in web.config e inserisce nuovi elementi, quindi la seconda volta che esegui la trasformazione inserirai elementi duplicati. Inoltre, tieni presente che se web.config è nel controllo del codice sorgente, vuoi che cambi tutto il tempo? – Michael

+0

Accetto per circolare problema. Anche se usiamo la trasformazione "SetAttribute" solo così funziona alla grande per noi. –

+0

Avere Web.config sotto il controllo del codice sorgente è importante per noi. Quindi la soluzione. Ma sono d'accordo che la tua soluzione sia preferibile. –