VS2012 Web Deploy Package per creare pool di applicazioni

Question

Ho un progetto di applicazione Web in VS2012 che sto pubblicando utilizzando un "Pacchetto di distribuzione Web". Voglio che questo pacchetto includa le impostazioni dell'app-pool, in particolare creando un pool di app IIS e assegnandogli l'applicazione appena creata.

Ho familiarità con l'opzione "Includi impostazioni del pool di applicazioni utilizzate da questo progetto Web" disponibile quando il progetto è configurato per utilizzare un'istanza IIS (non IIS Express), ma la configurazione di IIS è non parte del progetto file, e quindi non controllato dalla fonte. Cosa succede quando qualcuno crea un pacchetto di distribuzione su una macchina che non ha IIS configurato meticolosamente? Non ideale

In quale altro modo, come posso ottenere le impostazioni di AppPool nel mio pacchetto di distribuzione Web? Capisco che il provider appPoolConfig sia solo IIS7 +, sto bene con quella limitazione. Ho battuto la testa contro questo problema in passato e non ho mai trovato una soluzione. 18 mesi dopo, abbiamo una nuova versione di VisualStudio e una nuova pipeline di pubblicazione web, ci sono nuove opzioni per affrontarlo? O forse qualcosa che mi è mancato quando ho affrontato per la prima volta questo problema?

Modifica

OK, sto vedendo le seguenti opzioni come:

1. configurare il mio progetto per sincronizzare le impostazioni da un'istanza di IIS. Come accennato, non sono un fan di questo dato che mette le impostazioni all'esterno del del progetto, il che significa che l'ambiente deve essere configurato meticolosamente per costruire + pubblicare. Inoltre, trascina altre impostazioni IIS che non desidero includere.
2. Iniettare qualcosa nel web-publishing-pipeline (WPP) per modificare l'archive.xml. Mi sono divertito con questo in passato e ho avuto un successo limitato. Un problema è che la pipeline non è esattamente cooperativa con il lavoro direttamente sul file archive.xml, un altro problema sono alcuni degli attributi più criptici coinvolti, come MSDeploy.MSDeployProviderOptions che sembra avere qualche binario codificato Base64? Non ho idea di cosa mettere lì dentro.
3. Trova un "fornitore" esistente che può fare ciò che voglio. Potrei essere sfortunato, il provider appPoolConfig sembra voler solo leggere/scrivere IIS, non, per esempio, un file XML di impostazioni. Qualcuno sa altrimenti?
4. Scrivere il proprio "provider" per produrre voci di output manifest. Non sono sicuro, è possibile scrivere un fornitore personalizzato che scrive su un manifest usando il nome di un provider esistente? Come in, MyCustomPoolProvider scrive le sezioni appPoolConfig in un manifest? Sembra un esercizio potenzialmente doloroso che può funzionare o meno. Avrei ancora bisogno di capire la codifica di qualsiasi cosa stia andando in MSDeploy.MSDeployProviderOptions?

Ho la sensazione che l'ostacolo fondamentale con Web Deploy per quello che sto cercando di realizzare sia quanto strettamente si appoggi ai "provider". I provider preesistenti sono in gran parte progettati per la sincronizzazione di IIS, non sviluppo primario e pubblicazione. Succede che alcuni di questi provider possono essere relativamente collegati facilmente tramite MSBuild, ma la maggioranza insiste nel prelevare dati da IIS, e questo è quanto.

Answer 1

L'utente ha compreso correttamente il provider appPoolConfig, in quanto può eseguire la sincronizzazione tra i pool di app e non può essere fornito direttamente con la configurazione. Quello che potresti potenzialmente fare è tenere una copia dell'appPool in questione nel modulo package (es.msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) e tenta di dirottare la pipeline in modo che la chiamata MSDeploy aggiunga il contenuto dell'applicazione nel pacchetto, lasciando lì il contenuto esistente.

In alternativa, è possibile mantenere sempre separati i pacchetti e distribuirli con chiamate diverse a MSDeploy.

FYI, MSDeploy.MSDeployProviderOptions è semplicemente una versione codificata dei parametri forniti al provider quando è stato impacchettato. Ad esempio, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip impaccherebbe il valore ignoreErrors.