We're in the process of migrating an xcopy type deployment to a Wix generated 
msi and I'm very frustrated with the lack of good templates for what I would 
think is a very common deployment scenario.  Any help here would be appreciated.
 
We deploy our service to several controlled environments (Dev, Integration, QA 
and Production).  Each environment needs its own configuration files, registry 
entries, and X-509 certificates installed.  
 
Our existing batch process does the following:Create DirectoriesCopy core 
filesCopy environment filesRegister environment registry entriesCreate virtual 
web directoriesConfigure web application
Register environment certificates 
We currently pass a parameter to the batch file designating the environment.  
Regardless of the environment, the configuration files are always copied into 
the WebServices directory and are always named Web.config, Product.config, and 
WsePolicies.config.  We currently add environment specific registry entries by 
merging the contents of a .reg file and register the X-509 certificates by 
executing another batch file.
 
I've got no problem creating a .wxs that can deploy a single environment 
including creation of the virtual web directories, the registry entries, and 
the certificate registration, although I still need to use a custom action to 
execute a batch file to properly install the certificates.
 
Here's where I need help:
 
o - Is there a tool I can use in an automated build process that will read a 
directory structure and create the appropriate Wix 3.0 fragments to duplicate 
that structure (including files) under the InstallDir?  Nothing fancy here.  
Files are already staged in to the exact same structure as they will be once 
deployed (think xcopy).
 
o - I'm looking for a way to deploy the environment specific stuff based on a 
user selection in a custom dialog UI.  I'd like to avoid creating multiple .msi 
files.  I've tried using Transitive="yes" attributes on each of the specific 
components, but this becomes tedious when we need to support a large number of 
environments. Is it possible to deploy the config files for all environments 
into a separate directory and then execute a custom action to copy the 
appropriate files into the WebServices directory?  If so, is there a way to 
execute a custom action on un-install to remove the config files from 
WebServices?
 
o - We want the root drive for InstallDir to be D: if a physical hard disk 
exists at D:, or C: otherwise.  Is there an easy way to determine whether the 
D: drive is a physical hard disk?
 
o - On occasion we deploy more than one instance of the service on the web 
server using named instances.  The usual service url is like 
http://host/Product/SoapSchemaVersion/WebServices/Service.asmx and the named 
instance url is like 
http://host/Product/InstanceName/SoapSchemaVersion/WebServices/Service.asmx.  
The directory structure naming of the second instance is similar.  Is there a 
way to prompt the user to install either the default instance or a named 
instance similar to the way the SQL Server setup does, and how can I inject the 
named instance during setup so the default instance and the named instance can 
reside side-by-side?
 
o - Here's the typical batch file we execute to install our certificates.  
Can/how do we accomplish the same thing using WiX 3.0?
 
certmgr -add "certname.cer" -r LocalMachine -s My certmgr -add "SAML.cer" -r 
LocalMachine -s Myset WP_ACCOUNT=NETWORK SERVICEwinhttpcertcfg -g -i 
"SampleService.pfx" -c LOCAL_MACHINE\My -a "%WP_ACCOUNT%" -p password
 
Thanks to all in advance
Lee
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to