Re: [WiX-users] How to reference a disk root from Directory table?
Yan Sklyarenko wrote: > Hello WiX community, > > This is a pure MSI question. > I'd like to insert a row into the Directory table, which corresponds to > the root of disk drive, for instance, D:\. But, neither "D:\", nor "D:" > works in DefaultDir column... > > Is this at all possible? If so, then how? > > I need this because my application requires certain security rights to > be set for all ancestors of the installation directory up to the disk > drive root inclusive. And I wish to use SecureObjects for this, > populating necessary information with a custom action. That's probably not a good idea! What about if the application is installed on a remote server? What about if the D:\ is a mapping of a remote directory? What about if the installation directory is a mount point of a different drive so "parent" drive is not installation drive? I have no problems with applications setting special permissions for their own directory. It is not uncommon for something like a database service. But you generally do not want to ever change permissions of parent paths from the installation directory. I would argue the application needs revision because as-is, it's broken. - Adam -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge module question
Anidil wrote: > Can't we author all the setup components inside an msm?Do we really need wix > then?What all are the advantages of going for wix instead of deploying an > application using merge modules? By extension, we do not need tools like WiX as we don't need tools like compilers. We can all hack binary codes directly to the processor and be done with it. BTW, .msm is like a .o to a .c - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing .NET 3.5 redist?
Christopher Painter wrote: > The WiX `philosophy` seems to be don't add .NET dependencies to your > install and don't redist the framework.Just do an AppSearch/Launch > Condition and tell the user to go do it on their own. Personally > this conflicts with my needs and results in one of the many reasons why > I can't use WiX even though I'd like to. The limitation is with Windows Installer, *not* WiX. The correct way of doing this is either, 1. a bootstrapper that will check for MSI and install it if needed, or 2. just ship your MSI with the requirement condition and let the destination deal with installing .NET 3.5. For corporate deployments, #2 is probably best while option #1 is better for the home user. MSI is just a single-transaction-at-a-time installer. It is not like Debian's APT that can install dozens if not more dependencies for you at the same time as it installs or upgrades hundreds of other applications. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Starting & stopping program during install & uninstall
Chris Mumford wrote: > During install I need to start a program that I've just installed, and I > also need to kill it during uninstall/upgrade. > > I believe that I can just add a custom action to start it, but what > about to stop it? Is there a non CA solution to this problem? Wouldn't such a program be then called a "service"? And if yes, then couldn't you just use the service tables for that? Finally, your scenario will not work if your program has any dependencies installed by the MSI, like the C library for example. These are not available until *after* MSI has completed (after custom actions executed). Though XCopy install type would work. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DigitalCertificate Element
Albert Shamsiyan wrote: > Wix help regarding DigitalCertificate Element, states that the > SourceFile is The path to the certificate file. Is it possible to > extract it from already signed file? If so how? Can I just use a signed > file or I must use the certificate file? Err, no. Digital certificates do not work that way. Unless MSI works in some non-standard way, in a signed message you have, 1. digital signature element - this is kind of like a hash of the MSI unique to the certificate. The certificate ID is generally in the signature. BUT, you need to locate the certificate. Since certificates for MSI files are not exactly public info, you need, 2. digital certificate element - the *public* part of the certificate. You can use this to verify that the signature is correct. You will also have a *private* part of the certificate that is used to generate the digital certificate in the first place. If this part is even disclosed or even not 100% secured, the signature cannot be trusted and certificate must be revoked. Finally, each digital *public* part of the certificate is signed by a trusted 3rd party, be it your company or another public source. I hope this overview clarifies the confusion for people that never deal with certificates or know how this stuff works. A signature is not the public part of certificate which is not a private part of certificate (never disclose the private part to ANYONE you do not implicitly trust). - Adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence for Sql Actions
Chris Eldredge wrote: > I'm trying to create an MSI that installs a .NET assembly and registers > it for use in SQL Server 2005. > > The problem is that the SQL I'm executing inside a SqlString is telling > SQL Server to load the assembly, but when I install the MSI it seems > that the assembly hasn't been copied to its final destination when the > SQL action executes. > > My question: is it possible to change the order that the actions execute > in such that the assembly will be where it is supposed to be by the time > the SQL commands start executing? No. GAC is updated after MSI install is finalized. Wix has no control over this. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Leaving a file on uninstall
Karthik Krishnan wrote: > You can set the File's parent Component's "Permanent" attribute to > "yes", which I think accomplishes what you are trying to do. This generally should only apply to system files. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Leaving a file on uninstall
RW wrote: > > > As it changes and will contain important data, I don't want the uninstaller > to actually remove it. Generally, this is not the correct way of doing things. The idea is to, 1. install MyConfig.XML with default data in program directory 2. your application opens MyConfig.XML in Application Data folder unique to each user, OR 3. if #2 not available, opens MyConfig.XML data in Application Data folder for All Users, OR 4. if #3 not avaiable, open the default settings from installation directory. Steps 2-4 apply per settings file or per setting, your choice. Then to save the settings, it should write, 1. to user's Application Data folder 2. to All User's Application Data folder if it has write permissions for that location. This way your application is not only correctly installed, it will work in cases where system administrator may have reconfigured your application for your computer or site install. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Service is not started in Vista, working fine in xp
SaiTeja wrote: > Continuation for the previous mail. > > When I start service manually from services.msc, I got error message as > "Windows Couldnot start Service on Local Computer - Error 1067: The process > terminated unexpectedly" Try to run it directly from installation location. What error do you get then? The service control errors are not exactly that helpful. You have to look for the errors from your service not the service control. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
Richard wrote: > There are times when I think the "unzip files" approach is legitimate. > > For instance, suppose you have a bunch of data files that represent a > snapshot in time for a dynamically updating service. Install the initial snapshot as a zip file. The service or custom action will then unpack these files into a *temporary location* (ie. NOT under Program Files). The zip file is tracked and removed. Dumping stuff into Program Files is not the right thing to do. Furthermore, since in your scenario the service will fetch updates from a network resource, why not just have it fetch the initial snapshot in the first place? If it is too big, then it is still valid to store the zip file instead of unpacking it. If the customer wants to completely reset the service, they can just delete all dynamic data in a database, and the service can then repopulate the database as if it were an initial snapshot. No reinstall needed. The *only* place to dump files is in a temporary directory or application's data directory (it is NOT under Program Files). The original post alluded towards dumping files in the installation directory. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
[EMAIL PROTECTED] wrote: > It's a slightly unusual option, but if I was in your shoes I might > consider supplying the application packaged as a wixlib (containing the > main application installation), together with a utility which allows the > reseller to select their "template" folder. After verifying that the You are making it too complicated. Wix is a great toolkit as it allows the generation of the installer files directly from the command line. To me at least, the obvious solution to create *many* semi-customized MSI files and to be sane is automation. For example, create a small web application where resellers can add their own logos, text options, etc. The web application then stores the stuff in some database. You then write a script that takes the data from the database and creates a file that will be included in the main wix file. Then you run make. Put the resulting MSI in the database (or reference in database) allowing each reseller to get their customized MSI directly from you. If they need changes like logo, they can just change it via the web app. So, you still end up with 40 MSI builds, but it becomes automated. I was going to write this is suitable for small and medium sized MSI files, but I think it would work with DVD sized ones as well. Disk space is cheap. CPU power is cheap. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
Xin Liu (Intl Vendor) wrote: > In our msi there is a .zip file needed to be unzipped to target folder > during installation. Does Wix directly support this kind of action? Why? Isn't the MSI file like a zip file? Anyway, your solution is really nasty. As far as I know, it will prevent the content of the zip file from being tracked by Windows Installer. Removing the installation will leave rogue files behind. Just specify the content of the zip file in the source schema as one of the components that is to be installed. The result will be the same as with zipfile, but at least the files will be tracked inherently by the installer. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom actions working fine in xp - failing in Vista
SaiTeja wrote: > I have created a WIX installer that works perfectly on XP. > > But When I try in Vista Business, my custom actions are failing > > Below is the custom action > > ExeCommand="UninstallLogonHandler" FileKey="xyz.exe"> > Let me quess, the xyz.exe depends on the C runtime? And you are installing the C runtime in the installer via merge module? If yes, that is the problem. In Vista the runtime will NOT be accessible to xyz.exe until *after* the installer completes installation. The only way to correct this is to either link statically, or distribute the runtime just as you would in the "copy method". Clearly, the preferred way is to use the merge module and just statically link the custom action. Pre-Vista OSes acted differently with respect to SxS DLLs hence your action worked. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Service Control & Install
SaiTeja wrote: > ((NOT VersionNT=500) AND (VersionNT64)) This is just a side note, but you should almost never use something like (NOT Version=500). Maybe you are looking for something like (VersionNT>500)? If you do not want to use CDATA section, you probably can just type (VersionNT > 500 ) The reason for this is what will happen if someone wants to install this on NT 4 for some reason? Cheers, Adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help on Service
Anidil wrote: > > I see that the service.exe has been copied and registered under windows > service console.but it doesn't start automatically.I get the following > message when tried starting manually."Windows could not start the service on > Local Computer. Error 1053: The service did not respond to the start or > control request in a timely fashion." I don't know if this is the same problem as in my case, but if your service uses some runtime that is also installed by the MSI (eg. C runtime), it CANNOT be started until MSI finalizes installation. The C runtime will not be available and will fail to start. This is assuming you are installing on Vista. - Adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Re Post: Msi Logging
SaiTeja wrote: > Hi, > > Thanks for Info. > > Can you suggest for Msi Logging for XP or 2000 > >>> -> >>> -> C:\Install.txt I'm not using this, but my suggestion would be to, 1. DO NOT use C:\ for cruft like log files. Put them in User's Directory like User's Application Data similar. Or temporary folder. 2. For logging on XP or 2000 you need to use a command line switch /log with msiexec to get logging. msiexec /log install_logfile.txt install.msi You can do that with a batch file or from command line. - Adam - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] May I have your attention, please :D
Szentpali Janos wrote: > I am glad to see I am not alone out there :). Sadly nobody else seems to > care :(. I would prefer that people actually replied in text only while also removing unnecessary cruft from the quoted bits before replying. What is the point of replying at bottom of email if one has to continuously scroll down to see the response? Anyway, I gave up that most people actually have any email etiquette these days. It makes it harder to actually read all of the information in email (eg. from archive) A more troubling trend is emerging in email. People are too lazy to actually create a new message these days. Instead they just reply to a completely unrelated one just because it contains the necessary From: data. This breaks threading and makes searching mailing list archives a chore to say the least. But I guess 2 clicks are so much more trouble than one click and put your new mail at top without even bothering to remove the old cruft. If this continues to degenerate, email may stop to be an effective way to communicate. - Adam - SF.Net email is sponsored by: 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
Re: [WiX-users] Calling embedded binaries with dependencies in WIX
Jose Sanchez Saldana (Excell Data Corporation) wrote: > I’m attempting to call sed.exe as an embedded binary from an MSI – > however, it has three dependencies: cygiconv2.dll, cygintl2.dll, and > cygwin1.dll. Does wix have any mechanism, through custom actions, that > would allow sed.exe to be called from within the MSI - through the > tag – without having to actually install the various > dependencies? Thanks. No. From my experience, I would only recommend static binaries for custom actions (ie. do not rely on C runtime either). Just as a side note, cygwin and sed (what you seem to be using) are both licensed under GPL license hence you are required to provide source code access to all customers using the software (installer is also software), including any modifications. Furthermore, the installer would need to be rebuildable with the modified sed files (if customers wants to do that for whatever reason) so source code/object code of the wix would need to be provided as well. If you are using this for excel installation or something like that, I would urge you not to use GPLed code or binaries - they are *not* freeware. Instead, please use BSD licensed software or similar software that may be considered "freeware" for binary only distributions. I think there are BSD implementations of sed (though less feature packed than GNU GPL version) - Adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows XP is Installed - Launch condition
Adrian Alonso wrote: > Hi! I need to add a launch condition to my product installer to > determine if the OS is Windows XP. My product can be only installed on > WinXP. Do you know which registry entry should I take or if I should use > another kind of launch condition? What I'm looking for is an "Official > answer from MS" or "The correct way to achieve this" (to avoid testing See VersionNT property value. http://msdn2.microsoft.com/en-us/library/aa372495.aspx - Adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting a shortcut workingdirectory in Vista
robert marshall wrote: > When creating shortcuts for our wix installer we've previously set the > Workingdirectory for the shortcut to be the root directory for the app > in C:/Program Files. Vista complains about users saving stuff there - > which happens when they do a save as and don't change the location, and Fix it in application not installer. What happens if the user starts the application directly from the install directory? Or makes their own shortcut there? If you want to be really correct, the correct place to save user documents is in their documents folder. - Adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Service Control and Service Install
SaiTeja wrote: > Hi, > > Can any review the wix code for the following and give example for last one > > Description="This will install only on Windows XP or later" > > NOT VersionNT = 500 Err, this is NOT VersionNT = 500 which means it will not install only on one version of Windows. What you are looking for is probably VesionNT > 500 But since this is XML and it doesn't like > and <, you can escape it as VersionNT > 500 or maybe Alternatively, you may want to use VersionNT >= 501 so it is self explanatory. - Adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Services + Vista + GAC
Richard wrote: > In article <[EMAIL PROTECTED]>, > Adam Majer <[EMAIL PROTECTED]> writes: > >> Regarding the service now, I think the problem has a lot to do with the >> installation of stuff into the GAC (the recommended way of doing things >> after all). All that the service needs is the C runtime, nothing special >> here. But that is not available. > > As Phil mentioned, an easy solution to this is to link to the C > runtime staticly and then *poof*, the problem goes away. Actually, that is not the 'easy' solution! There are other dependencies (not assembies, just regular DLLs) and those would have to reconfigurured and rebuilt. > ServiceControl does more than *start* services. Plenty of times you > need to stop services before you upgrade or install things, otherwise > the service process keeps it loaded in memory and you can't update it > without rebooting. IIS can hold onto your vdir, for instance. For > your own services, you need to stop them before you can update them. > I've used ServiceControl to start services I've installed plenty of > times, but in this particular case (changes you need aren't done until > InstallFinalize or later), it isn't working, so I was saying why not > investigate if you can live without starting the service after you've > installed it. Its a workaround. I know this. My question was why have the start attribute of the ServiceControl tag? Maybe a good feature for future release of WiX may be a delayed start of services. That is, the service is started after installation finalizes? - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Services + Vista + GAC
Richard wrote: > The problem isn't anything to do with Vista, its because your service > has a dependency on something in the GAC and the files don't really > appear in the GAC until after the Commit phase of the install. > > Just mark your service as starting automaticly and you shouldn't have > any problem. Then Windows will start the service when its needed. > Why do you think that you must start your service before the install > finishes? First a general comment - thanks for all the replies! Regarding the service now, I think the problem has a lot to do with the installation of stuff into the GAC (the recommended way of doing things after all). All that the service needs is the C runtime, nothing special here. But that is not available. Now, wix has so, why have that? Coincidently, it works on *every* release of windows, but not Vista because of Vista's new way of handing assemblies. Therefore the bug is either in WiX, Windows Installer or Vista. By my understanding of how things work, GAC refresh/update/install/committing/whatever you want to call it, should just be an API call within Windows Installer so the installation sequence can be, .. install stuff (including to GAC) .. refresh GAC -- maybe this could be a custom step that doesn't run unless needed, like when starting services before installation is done. .. start services. Then if start services fails, you roll back by uninstalling the stuff from the GAC, (refreshing it again, if you have done it before) and rolling back the rest of the installation. Finally, the application here is installed as a service because it is not a user intractable application and it is the easiest way of doing things. But yes, there may be another way of running it... messy, but possible. But for general case, does windows have triggers that allow a service to be started automatically when someone tried to connect to UDP port 123 (example) or a named pipe? If yes, then I guess ServiceControl's start attribute can be removed? - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Services + Vista + GAC
Hi, I have a service I want to install and automatically start with an installer. Now, the runtime for the service is not available until after installer completed because the runtime goes into the GAC (it is just the VS2005 SP1 C runtime). One solution is to deploy the files locally (as in a per-user install), but that doesn't work because the service uses a plugin that is in a subdirectory of the installation. The location of the plugin is not easy to change. Another solution that was suggested here was to use a deferred custom action to start the service. But that also doesn't seem to work. Using WiX 2.x branch and it results in a runtime error. The custom action works OK if run outside of the MSI. The error returned is "Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize." Currently I have it as, Any ideas? This problem will definitely keep surfacing regarding Vista and services. Is there something being done either in the Windows Installer or WiX to address this issue and allow services to start after GAC is updated? Or update the GAC, start services then commit installation?? Or is there a way to force GAC refresh (or whatever it is called) as an installation sequence? The current situation is a giant PITA. - Adam PS. I guess an alternative would be not to start the service on Vista and ask user either to start it manually or restart the machine. Not a good improvement from XP or 2003! - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cannot install VC80 Runtime from VS2005 SP1 on Vista and Vista only
Wilson, Phil wrote: > If you were in fact installing the base VS 2005 merge modules on Vista > instead of the SP1 versions, this might be the Orca issue with dates - > if you open a merge module with Orca it will unconditionally change the > modify date. If you did that to the original VS 2005 merge modules then > SP1 won't update them because that's the MSI update rule - they look > like they've been modified. You'd still have the base VS 2005 versions. Sorry for the lateness of the reply, but I think you are correct. I noticed recently that even if you just open the files with Orca, DO NOT save anything or modify anything, the modification date on the files is updated. This Orca bug is probably what caused the problem in the first place. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] enabling a control with a radiobutton in the same dialog
Richard wrote: > In article <[EMAIL PROTECTED]>, > Rob Hamflett <[EMAIL PROTECTED]> writes: > >> > > Do you really need this business? CDATA sections is not needed in XML. It is only used if you don't want to escape special characters like > and/or want to preserve whitespace. Regular XML does not preserve whitespace. Of course, there is still the problem with ]] in your text! Though I'm not sure many people use that. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall removing edited files
Richard wrote: > In article <[EMAIL PROTECTED]>, > Craig0ss <[EMAIL PROTECTED]> writes: > >> Basically my installer installs certain standard letters for use with the >> software, if i change the standard letter to incorperate client specific >> details and then uninstall the product the modified file is removed, is >> there a way to check if the file has been modified and do not delete it on >> uninstall? > > The way I've dealt with this was to run a custom action that copies > the files to a backup before the upgrade install transaction begins, > i.e. the CA was immediate and sequenced before InstallInitialize. > > Its kinda hacky; I'd rather that Windows Installer not remove modified > files during an upgrade, but I can see how that would be problematic > to get right in all circumstances. Huh? Hacky is allowing files to be modified in install locations. I'm mostly from Linux distributions when it comes to this but, 1. installer must never install in user modifiable folders for system wide installs 2. installer must not modify user settings - only system settings (unless user install, of course). 3. software must store modifications in user folders and in user accessible locations (registry), unless it is some system software that stores global changes, then it must not just overwrite the default, install data. 4. install locations should not be overwritten by user actions from within the program no matter if installed as system or user. There are other areas too, like not removing user configurations when uninstalling software. Most Windows installation people would do users a favour by following rules that are common in UNIX world. I think Vista is starts to enforce this more than older versions of Windows - finally Windows version that makes sense in terms of user/system/install defaults. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] example Wix project
hina1703 wrote: > Hello Richard, > > I am still trying to find out some information as subtle advantages of WIX > over InstallShield & looking for a demo project. Do you have any other > example project which you can share with me? > Also are there any power point slides or any info available? The following reasons are my reason: * It is free * It is open-source so if there is a big problem that I need fixed NOW I can invest the time/money to fix it * It is being used by Microsoft's largest products => well tested * It is just a bunch of command line tools => much nicer build process. I'm not on the inside (of Microsoft) but from my understanding Microsoft Office and Visual Studio are both using WiX for installers (someone correct me if I'm wrong here!). If that is correct, those are good "demos projects" I guess! - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
Wilson, Phil wrote: > That's correct, Vista uses the same SxS model with Fusion to install the > C++ runtimes as GAC installation, so the runtimes aren't available until > after InstallFinalize. Solution: * Install merge module if (VersionNT < 600) OR Version9X . In other words, install the merge module on pre-Vista systems and the service will use the merge module files. * On Vista and newer machines (VersionNT >= 600), install the runtime as a local assembly in the destination folder of your service. This makes the MSI file larger, but at least it works the Right Way. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
Rob Mensching wrote: > schema is all documented. The command-lines and the tools to use are > documented.” I’m happy for people to say, “Hey, such-and-such isn’t > documented… can I expect it to remain constant supported and all that > good stuff?” I’ll then go into the tools and see if it is a purposeful > feature or a side-effect that might change in the future. The former is > something I should document. The latter is something you should not use. I'll bite on that and point you to light.exe command line options. light.exe 3.0.2925.0 [snip] -xo output xml instead of MSI format [snip] So either xml is not xml or -xo file format changed but documentation has not. Maybe it should say "output internal WiX format instead of MSI format". Plain XML is still nicer regardless if it will result in something 1.35 times bigger (if binary part is base64 encoded). But then I don't really have anything invested in -xo output format so it doesn't really matter to me. - Adam PS. Another way would be to have a -xo for plain XML and -xb for the new binary format. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
Richard wrote: > In article <[EMAIL PROTECTED]>, > Adam Majer <[EMAIL PROTECTED]> writes: > >> How can I structure this such that the merge module is installed >> completely prior to installing the component? > > In addition to what Bob Arnson said, check your install execute > sequence and look at the relative ordering of the standard actions > that manipulate services and those that install the files. > > The canonical sequence has the sequence of: stop services, install > files, start services, so you should be OK. > > How did you determine that your service didn't start because of > missing runtime files? Vista says that SxS (Visual C runtime 8.0 from VS 2005 SP1) is not available. Starting a configuration utility that depends on the same SxS indicated that there is a SxS installation error. If I do not attempt to start the service in the installer, I can run the configuration utility or the service after installation is complete. While searching the archives, I came across a response by Rob Mensching that appears to address the same problem. "Usually, this means your service has some dependency that hasn’t been completely installed by the time StartServices is called. A favorite way to hit this is to have a managed code service that depends on an assembly that is being installed to the GAC. Because assemblies aren’t committed to the GAC until InstallFinalize, the assembly won’t be found in the GAC until the install is complete." Moving the StartService after InstallFinalize didn't work - got an error that didn't even rollback :) Kind of expected. I'll try to install as a local assembly in addition to the merge module and see what happens. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
Bob Arnson wrote: > Adam Majer wrote: >> How can I structure this such that the merge module is installed >> completely prior to installing the component? >> > > That's not how Windows Installer works: Merge modules lose their > identity when merged, so they're just a bunch of components in the .msi. > Then, each resource of each component is installed, via standard > actions. (InstallFiles, for example, installs all the files in all > components before WriteRegistryValues writes all the registry values for > all components.) > > If you need tighter control than that, you need to use separate packages > and a chainer. > Are you saying that it is impossible to install a service that depends on a MSVC runtime and start it in the same installer? Surely, that can't be true. The installation keeps bombing that SxS install is not correct. Now, if I do not attempt to start the service, installation completes and I can start the service manually, through reboot or use a program that uses the same runtime SxS. It is as though SxS is not installed until after the installer is done making it unavailable to anything (including custom actions) called by the installer. The structure of the installer is very simple. Therefore, to start services that need the SxS module installed by the same MSI, * reboot like in old days to start, * start manually, or * ??? - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installation order for Service Installs
Hi all, I want to install a service, but the service needs a runtime installed first to be able to run. More importantly, the C runtime. My current setup is, This results in the component installed prior to the runtime or at least the runtime being unavailable before the component is installed and an attempt to start the service is executed. How can I structure this such that the merge module is installed completely prior to installing the component? Thanks, - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
Peter Marcu wrote: > The wixout is not a pure xml file in WiX 3.0. It has a cab at the > beginning of it that contains embedded binary files. Wouldn't it be possible to fix this such that it is a proper XML file? The cab could be embedded in the XML (eg. base64) and the entire thing would be much better, though not exactly perfect. At least it would work with XML parsers. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cannot install VC80 Runtime from VS2005 SP1 on Vista and Vista only
Jeff Bean wrote: > > > Adam Majer-2 wrote: >> Installing the runtime from VS2005 SP1 using the merge module (yes, >> correct version) does NOT work on Vista while it works *perfectly* on >> 2003 server - both clean installs of the respective OS. Both OSes need >> the runtime installed for the program to run. >> >> The install log on Vista indicates that the merge module dlls are being >> installed into a null directory. >> > > Try moving the MERGE element down two lines so that it is just inside the > outermost DIRECTORY element. That is where I put my MERGE element and it > works for me on Vista. Also I used Language="1033" instead of Language ="0". I "fixed" the problem. Solution: Reinstall MS VS 2005 SP1 Lesson Learned: After installing service pack or even original VS, *always* copy the merge modules to a safe place before they get clobbered by some other SDK or "security patch". I still have no idea why it worked on 2003 (2003 gives SxS not found errors if SxS assembly not found) and it did not work on Vista. But it was not a WiX problem. Same problem with VS Setup project. - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Cannot install VC80 Runtime from VS2005 SP1 on Vista and Vista only
Hi all, Installing the runtime from VS2005 SP1 using the merge module (yes, correct version) does NOT work on Vista while it works *perfectly* on 2003 server - both clean installs of the respective OS. Both OSes need the runtime installed for the program to run. The install log on Vista indicates that the merge module dlls are being installed into a null directory. It just says that the dlls are installed in Directory: , Then trying to start the application produces an error that the runtime is not available. The Directory is listed using the same MSI file on 2003 server installation. Tried WiX 2.x and 3.x and same results. Used WiX binary distribution. I have created a very small program (one line command line) that shows this problem. You may download it temporarily from: http://www.zombino.com/temp/source.zip There is also an MSI of the binaries also available (2.2M) http://www.zombino.com/temp/test.msi If you cannot be troubled to extract the 1K source.zip, the files to the sources code in the zip file are: http://www.zombino.com/temp/source/main.cpp http://www.zombino.com/temp/source/main.wxs http://www.zombino.com/temp/source/Makefile You may need to adjust your paths to compile the example. The test is installed under Test of Program Files. Any ideas why Vista install is crapping out? - Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
