Re: [WiX-users] Issues with ServiceInstall
Thanks Chad! Taking out the Arguments attribute fixed it, I read the wix.chm again, Arguments is for passing the arguments to run the service not install it. I wonder how Wix/MSI figures out the arguments required to install/uninstall the service, because my services require specific parameters to install and uninstall it. Thanks again! -Sandip On Wed, Jun 4, 2008 at 2:01 PM, Chad Petersen <[EMAIL PROTECTED]> wrote: > Have you tried it without the Arguments="-Install" being part of the > syntax? From what I understand, those arguments are those needed to run > the service, not to install the service. For example, if I want to > install our service smanually, I run -Service as the paramter, but I > sure don't include that in my install as ServiceInstall takes care of it > for me. > > It seemed worth mentioning. > > Chad > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sandip > Ghosh > Sent: Wednesday, June 04, 2008 12:08 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Issues with ServiceInstall > > I have been installing/uninstalling services through Custom Actions > earlier. > I attempted to use ServiceInstall to install the service. The service > installs, but I cannot start it. It appears to be a permissions problem. > I > have read a bunch of posts, and have attempted some of the suggestions, > but > could not get this to work. I have tried to only install the service > through > the MSI and start the service manually, I get the error 1053 - "Service > did > not start in a timely manner". I think I was getting the 1920 error > without > the Account and Password attributes on ServiceInstall. If I attempt to > start > the service, then uninstall fails to remove it, the service goes into a > disabled state and I have to reboot to clear the service registry. I > have > tried deleting registry keys related to the service, but it did not > work. > However if I uninstall without attempting to start the service, then the > service gets correctly removed through the MSI. I could not get anything > useful out of the Event Viewer or MSI logs. This all ofcourse, works > fine if > I attempt to install/start the service through the command line, which > is > what the Custom Action was invoking. > > Here is the code snippet, its pretty similar to what others have posted. > >DiskId="1"> > src="d:\test\atlantis\AtlantisAgent.exe" KeyPath="yes" /> > Name="AtlantisAgentWinService" Arguments="-Install" > DisplayName="AtlantisAgentWinService" Description="Atlantis Agent > Windows > Service" ErrorControl="normal" Start="auto" Type="ownProcess" > Account="[SERVICEACCOUNT]" Password="[SERVICEPASSWORD]"/> > Name="AtlantisAgentWinService" Remove="uninstall" Wait="yes"/> > > > I am using Wix 2.0.4820. > > Thanks, > -Sandip > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Issues with ServiceInstall
I have been installing/uninstalling services through Custom Actions earlier. I attempted to use ServiceInstall to install the service. The service installs, but I cannot start it. It appears to be a permissions problem. I have read a bunch of posts, and have attempted some of the suggestions, but could not get this to work. I have tried to only install the service through the MSI and start the service manually, I get the error 1053 - "Service did not start in a timely manner". I think I was getting the 1920 error without the Account and Password attributes on ServiceInstall. If I attempt to start the service, then uninstall fails to remove it, the service goes into a disabled state and I have to reboot to clear the service registry. I have tried deleting registry keys related to the service, but it did not work. However if I uninstall without attempting to start the service, then the service gets correctly removed through the MSI. I could not get anything useful out of the Event Viewer or MSI logs. This all ofcourse, works fine if I attempt to install/start the service through the command line, which is what the Custom Action was invoking. Here is the code snippet, its pretty similar to what others have posted. I am using Wix 2.0.4820. Thanks, -Sandip - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Interest in a MSI/MSP installer generator based on Wix
We have built and used a tool internally that provides a wrapper over Wix in MSI/MSP generation for over two years. Spikesource is in the business of building and packaging a large number of open source components (in the hundreds) and integrating them into application infrastructure stacks. On windows each of these open source components (e.g. apache, tomcat, jboss, mysql etc) are packaged into MSI files. These components can later be updated through MSP or MSI, so making sure the MSIs are built with component GUID tracking is an important feature in the tool. I wanted to send out a brief description of what the tool does (or intends to do, in some cases) and see if there would be interest in the Wix community for such a tool. We would like to open source our tool, if it would be useful to others. *Goal: * Make it extremely easy to build simple MSI based installers with built-in support for most common installation tasks. Support 80% of the typical installation tasks through a XML configuration file that does not require deep knowledge of windows installer technology. The tool will generate human readable and editable Wix source files, so for those 20% cases that are outside the scope of the tool, there should be enough Wix code generation to be a good starting point for customization. If this sounds interesting, please read on :) *Inputs:* (required ones, there will be a few additional optional ones) 1. Product name 2. Source directories (supports multiple sources) where the deployment files are 3. An XML document that specifies configuration information about MSI installation features. *Outputs: * 1. MSI or MSP (will have a few additional required inputs) 2. GUIDs ini file for tracking Component Rules 3. Wix Source Files that the user can edit for further customizations. *Installation Features Support: * 1. Create basic Windows Installers, with "WixUI_InstallDir" UI, i.e. wizard with Welcome, License Agreement, Installation Directory selection, Install Confirmation, Installation and Finish pages. 2. Branding support for customizing Start/Finish and Header banners. 3. MSP creation support - Pass the source paths to the previous and current versions of the product and in the configuration file identify the upgrade versioning info, the tool will generate temporary MSIs for each version and then merge them into an MSP using MsiMsp.exe 4. Package installation files from source directories with MSI Component GUID tracking support - Component GUID tracking is implemented by creating an entry in the ini file for each subdirectory traversed with a sub-directory path to GUID mapping the first time the tool is run for a product. This ini file should be under source control and subsequent MSI creation for the same product should make this ini file available to the tool. It will generate the MSI reading the GUIDs from the ini file. 5. Common Public MSI Property support - Create MSI properties for common public MSI properties such as ALLUSERS, ARPCOMMENTS, ARPREADME, ARPURLINFOABOUT etc based on configuration info provided. 6. Registry entry creation support - Create registry entries based on configuration info provided. 7. INI/Conf file generation support - Create ini file key-value pairs based on configuration info provided. 8. Shortcut creation support - Create short cuts based on configuration info provided. 9. Service Management support (install/uninstall/start/stop) 10. Custom Action support - callout to user defined executables, bat files etc at configurable points during installation sequence 11. COM DLL Registration support *Long Term:* Support UI code generation, possibly through a visual designer. The Wix source file generation is performed by substituting variables into Wix source templates, the values being extracted from the XML configuration file through XPath. The files source generation is by traversing the specified source directory, similar to tools like Tallow, but with Component GUID tracking. Currently the tool is built around the latest stable Wix 2.x build, this can later be upgraded to work with Wix 3.0 If the question is why another XML Schema to describe installation tasks on top of Wix, I see the Wix Schema as being a wrapper over MSI database tables and operations on them and requires the developer to know and understand the various tables, their columns and what the purpose of each of those are. The Schema in the tool, is more functional in nature, it captures the installation tasks the developer would like to perform through its elements and attributes and does not require the developer to know some of the windows installer complexities for simple installation scenarios. Sorry for the long post, if you have gotten here and feel such a tool would be useful to you, please let me know directly (no need to spam the list). I woul
[WiX-users] Update of Files Modified After Install
For files that have been modified after an MSI installation, if these files are in an update package (MSP) as far as I know there are 2 options available during the MSP installation: REINSTALLMODE=omus : Don't update files modified after installation REINSTALLMODE=amus: Overwrite files modified after installation. We are dealing with installation of software components that have configuration files that WILL be modified after installation. If these files are updated in the MSP package, we need to support the following options: 1. If it is possible to auto merge the changes between the updated file and the installed file then perform the merge. 2. If there are conflicts that need manual intervention, then save the updated file as a new file (with a different extension for e.g. foo.ini.new) Is there any built in facility in MSP to support these requirements, specially #2, this is supported by RPM on Linux. I could not find any information that this is supported by MSP, so assuming the answer is no, the approach I was thinking of was execute a custom action after MSP installation either invoked from within the MSP or by the driver that executes the MSP installation. This custom action would interrogate the MSP for the files it contains and check if any of the files is a "config" file that needs to be either auto-merged or saved as a new file for manual merge. Examining an MSP package in Orca only shows MsiPatchMetaData table and MsiPatchSequence. There is no InstallExecuteSequence table for adding custom actions or File table to get the list of files in the package. At a minimum I would need to know the files within the MSP package. Is there a way to get the list of file in the package ? If so, please advise on how to get this information. Thanks much for your help. -Sandip - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Light Exception with Merge Modules
Thanks Rob for your response.
Your comments about path problems with cygwin, gave me a hint, so I got this
to work on a command prompt, the paths to candle and light had both forward
and back slash in my wix driver app, using back slash consistently fixed the
problem. We do our builds using cygwin and I still have the problem with
getting this to work in cygwin, but I should be able to figure that out, we
have utils to handle the windows and linux path separators.
Another quick question I had was whats the replacement for ?
With 3309, I had this tag within the tag and linked with
wixui_mondo.wixlib, with 4820, I am linking with wixui.wixlib and get the
following error with using the tag.
error LGHT0112 : Unresolved reference to
symbol 'UI:WixUI' in section 'Product:225454C0-F159-491C-8CE7-BC035678C315'.
Thanks,
-Sandip
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Thursday, February 15, 2007 11:53 PM
To: Sandip Ghosh; Wix Users (Wix Users)
Subject: Re: [WiX-users] Light Exception with Merge Modules
I think I remember problems with cygwin bash shell (or something like that)
messing with the load of mergemod.dll. Also, do make sure you have
mergemod.dll next to the rest of the tools. that *should* be that way but
good to check.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sandip Ghosh
Sent: Thursday, February 15, 2007 11:28 PM
To: Wix Users (Wix Users)
Subject: [WiX-users] Light Exception with Merge Modules
I create MSIs through the use of merge modules. I have been using Wix
version 2.0.3309 for a while now and have not had any problems generating
the MSIs, I have tried a few times to upgrade to later versions of Wix. I
have tried 3719 and now 4820. With both the latter versions, The MSM
generation looks fine, but I get the following error during the final light
phase when it attempts to create the MSI from the MSM.
light.exe : error LGHT0001 : Retrieving the COM class factory for component
with
CLSID {F94985D5-29F9-4743-9805-99BC3F35B678} failed due to the following
error:
8007007e.
Exception Type: System.IO.FileNotFoundException
Stack Trace:
at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String
databasePat
h, Output output)
at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output)
at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args)
I think I have seen some prior posts about installing Orca and registering
mergemod.dll to fix this problem. I have done both and I can find the CLSID
above in the registry as a registered COM object. Still get this failure.
What else is needed to get this to work ?
Thanks for your responses,
-Sandip
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Light Exception with Merge Modules
I create MSIs through the use of merge modules. I have been using Wix
version 2.0.3309 for a while now and have not had any problems generating
the MSIs, I have tried a few times to upgrade to later versions of Wix. I
have tried 3719 and now 4820. With both the latter versions, The MSM
generation looks fine, but I get the following error during the final light
phase when it attempts to create the MSI from the MSM.
light.exe : error LGHT0001 : Retrieving the COM class factory for component
with
CLSID {F94985D5-29F9-4743-9805-99BC3F35B678} failed due to the following
error:
8007007e.
Exception Type: System.IO.FileNotFoundException
Stack Trace:
at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String
databasePat
h, Output output)
at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output)
at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args)
I think I have seen some prior posts about installing Orca and registering
mergemod.dll to fix this problem. I have done both and I can find the CLSID
above in the registry as a registered COM object. Still get this failure.
What else is needed to get this to work ?
Thanks for your responses,
-Sandip
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
