[WiX-users] [Personal note: goodbye to Wix-Users, and thanks]
I'm changing jobs in two weeks, and with the change in responsibility I'll be leaving the Wix-users community. I subscribed to the list last year and was able to successfully - and relatively painlessly - change our products from InstallShield to Wix. Almost all of that invaluable knowledge came from the 9000 messages (not including spam) from the list in the past year, with assistance from the list archives too. I just wanted to say thanks to the list contributors for all your helpful help on Wix and Windows Installer. Daryn. - 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] Get Target machine name
[EMAIL PROTECTED] wrote: > > For the machine name, use the ComputerName property. Tris Hodges wrote: > I assume you meant like the following.. $(sys.COMPUTERNAME)? I > believe this is set at compilation [ ] No, Calin meant the Windows Installer property ComputerName, see the Windows Installer Property Reference, http://msdn2.microsoft.com/en-us/library/aa370905(VS.85).aspx For domain name, I'm pretty sure it needs a custom action, e.g. your own C++ DLL. Or, a quick search shows that Matthew Rowan posted a simple VBScript custom action to do it to this list previously: http://www.nabble.com/domain-name-to9381200.html#a9381200 ... and InstallSite has a CA DLL that provides it as well: http://www.installsite.org/pages/en/isp_svc.htm Daryn. - 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] SecureCustomProperties from Merge Module
Daryn Mitchell originally wrote: > > ... merge module's ... SecureCustomProperties ... how should the > > merge module get the result of its file search during Vista repair? Bob Arnson wrote: > The only thing I can think of is a custom action that adds your property > to the SecureCustomProperties property. You'd have to play around with > the sequencing to find the right timing. Thanks for the suggestion, Bob. I saw the same suggestion made <http://forum.installsite.net/index.php?showtopic=15935> by Stefan. I wasn't able to get it working, though. I tried using a type 51 custom action during the UI sequence to append the property (the full merge module property name, including the MSM suffix) to SecureCustomProperties. I couldn't find any information on when to schedule it, so I ran it as the first item in the UI sequence. While the MSI's SecureCustomProperties property was correctly updated, it didn't seem to have any effect on the merge module's public property being disallowed. Since it works if the property is added to SecureCustomProperties in the MSI directly (using Orca), I'm assuming that it's too late once the installation has started? Anyway, my conclusion: I couldn't get it to work, so I changed the merge module authoring to remove the FileSearch. Should work fine for our needs, but I'm glad it's nothing more complex, because I think the same issue would affect RegistrySearch, which is pretty essential MSI stuff! Daryn. p.s. For what it's worth, two other points of interest if anyone else looks into this problem: -Running the repair using the original MSI in a different folder causes the UAC prompt, which allows the public properties get passed to the execute sequence. -There's a <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2941031&SiteID=1> discussion on the MDSN forums about trusted repairs/changes -- behaviour that surprised me -- in which one MSFT commenter referred to marking a product ARPSYSTEMCOMPONENT and creating your own custom legacy UNINSTALL key reference that points to your boostrapper (that could require elevation). Too complex a workaround for me, but I thought it was interesting. - 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
[WiX-users] SecureCustomProperties from Merge Module
Hi, Looking for your Windows Installer / WiX knowledge about SecureCustomProperties behaviour with merge modules: Setup: - Wix 2.0.5325 - My WiX product FOO.msi merges in a merge module BAR.msm (using Feature/MergeRef and Directory/Merge). - The BAR.msm has a property BAR_SEARCH_RESULT in its SecureCustomProperties propery - (I am the author of the merge module, so I can fix it, but I can't use WiX fragments because the customers of the MSM aren't all using WiX.)4 Problem: - FOO.msi is not authored with the merged property "BAR_SEARCH_RESULT.ABC132...MSM_GUID" in its own SecureCustomProperties property - Therefore, when a repair is run on Vista with full UI, the merge module's BAR_SEARCH_RESULT property is not passed to the execute sequence (log "Ignoring disallowed property..."), which causes an error with a repair CA. Question: - Should a merge module's Secure Custom Properties be automatically put into the consuming MSI's own SecureCustomProperties automatically when it incorporates the merge module? (i.e. is Wix not doing something it should be doing? Much more likely that I don't know best practices here, but I had to ask.) - If not, how should the merge module get the result of its file search during Vista repair? Thanks, Daryn Mitchell - 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 action sequencing problem
> -Original Message- > From: wix-users On Behalf Of Boris Krivonog ... > Attached is a simple VS 2005 project which locates a process by name and > sends it a WM_CLOSE. That's really generous of you, Boris. Thanks for sharing that with the community. Daryn. - 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] condition expression syntax (ICE79)
> -Original Message- > I have a feature with the ID="SomeFeature". > > $SomeFeature > This throws an ICE79 error. > > However, changing the $ to a ! is fine. $ is for components, & and ! are for features. (Conditional Statement Syntax http://msdn2.microsoft.com/en-us/library/aa368012(VS.85).aspx) Daryn. - 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] Multilingual Support
> -Original Message- > Yes, I know the short answer is 'no' > ... installers that can make a single multilingual install package > ... isn't there some creative work-around for this? "Multi-Language MSI Packages without Setup.exe Launcher" http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm I haven't tried this yet but it sounds ideal. It's undocumented and therefore officially not supported. But if it works, hey, why not? By the way, if you try it, could you post back to the list to let us know if it was successful or not? Thanks. Daryn. - 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 Action Rollback Implementation
> -Original Message- > From: Sneha Gharpure > > the "WriteToRegistry" action is called only during the > installation and therefore the condition " Not Installed". > I am not sure about the condition for "WriteToRegistry_Rollback". > I have tried both- "Installed" and "Not Installed" > > >Not Installed > > >Installed > Richard is right that your primary issue to that your CA has to be deferred if you want your rollback action to get written to the rollback script. I wanted to add that the condition for your rollback action should be the same as the deferred action that you want to roll back. I.e. if WriteToRegistry's condition is 'Not Installed', then you want to use 'Not Installed' for WriteToRegistry_Rollback too. When you get to the action and the condition 'Not Installed' is true, the rollback custom action doesn't fire right away, it gets written to the rollback script. It will then be executed if the install rolls back. For a helpful overview see "Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer" on Stefan Krueger's site. http://www.installsite.org/pages/en/isnews/200108/index.htm Daryn. - 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 started & stoped but Not removed from Servcies.msc
> -Original Message- > I have one service related binary(guardsvc.exe) > > It is started properly while installing and stoped while uninstalling. > > The problem is it is not deleted the corresponding registry > key(HKL\SYSTEM\ControlSet001\Services\guardsvc.exe) and because of > this registry key it is visible in Services.msc It might be something other than a WiX problem. 1) Don't look at ControlSet001, look at CurrentControlSet 2) Is the service marked for deletion? 3) If so, then your service won't be removed until reboot. I've seen that happen recently where QueryServiceStatus was called on a service, but CloseServiceHandle was not subsequently called to release the handle, so the service control manager would only mark the service for deletion, not actually remove it. Daryn. - 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
[WiX-users] Shared components and "?Comp1" Component State condition
I've got a component that's installed by two products, via a merge module. There's also some custom actions, conditioned something like this: Install_Ensure, Condition: $Comp1 = 3 InstallRollback_Remove, Condition: $Comp1=3 AND NOT ?Comp1=3 Uninstall_Remove, Condition: $Comp1 = 2 AND NOT UPGRADINGCODE (UninstallRollback_Ensure) The Product2 uninstall works fine: the log shows that it gets "Installed: Local; Request: Absent; Action: Null", so the shared component is -- correctly -- not removed until Product1 is uninstalled. However, there's a problem with the Product2 install rollback condition. During install the component state shows "Installed: Absent; Request: Local; Action: Local". I was expecting Installed to be Local, not Absent! I thought my "AND NOT ?Comp1=3" condition would mean the rollback remove would only run when the component was not already installed, i.e. not run during Prodcut2 install. But the rollback runs. After searching, I found a confirmation in the docs at the bottom of 'Conditional Statement Syntax' that this behaviour is expected by Windows Installer, "Note that you should not depend upon the condition $Component1=3 to check whether Component1 is locally installed on the computer..." Question: So what is the correct way for the Product2 install to know that the shared component is already installed locally by Prodcut1? Thanks for any suggestions Daryn Mitchell, Software Developer, Faronics Corporation Note: I haven't tried SharedDllRefCount; from my reading of the docs it didn't seem like it would solve this, except if I used it to support a hack like manually checking the refcount in the registry at install time? - 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] Re Post: Msi Logging
> -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > Subject: Re: [WiX-users] Re Post: Msi Logging > I dont have idea about "bootstrapper". > > Could you tell me in detail or send me the url http://www.nabble.com/forum/Search.jtp?forum=4468&local=y&query=bootstrapper - 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] show progress text for custom action
Adam Langley wrote: > ... > the Progress Text in the dialog shows "Removing Backup Files" > during the execution of my slow custom action, it never > renders my text > ... > My guess: You should make your action be deferred instead of commit. a) Wix ProgressText maps to Windows Installer ActionText table (Wix.chm) b) "Action text is only displayed for actions that run within the installation script. Therefore, action text is only displayed for actions that are sequenced between the InstallInitialize and InstallFinalize actions" (Windows Installer docs for ActionText Table) c) Your action is a Commit CA. Commit custom actions run after InstallFinalize is finished. (Windows Installer docs for Commit Custom Actions). Therefore I figure the progress is not showing because you've made it a Commit action. Your symptom may have been useful because it raises the question, why is your CA a commit action, rather than deferred? - "The purpose of commit actions is to remove any backup information that had been created by a custom action." (Installsite, http://www.installsite.org/pages/en/isnews/200108/index.htm) - That's exactly what you saw the WiX UI choose for the progress text during the commit phase, "Removing Backup Files". So... would it be more appropriate for your CA to be a deferred action instead? If so, then you'll have solved your progress text too. Daryn. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action type 1042 and 18
Here's a couple of possibilities: 1) If you've got an existing MSI you're converting to Wix, use the Wix tools (Dark) to decompile it into Wix markup. 2) Very handy Custom Action Type Calculator on the InstallShield web site makes the guess and test go much quicker. (Needs IE, doesn't work in Firefox for me.) http://helpnet.installshield.com/robo/projects/helplibdevstudio9/IHelpDLLFun ctionCalcType.htm 3) The Custom Action Reference on MSDN provides the real info on the flag values. (http://msdn2.microsoft.com/en-us/library/aa368070.aspx) You break your known type into its component pieces. Note that you seem to have to step through a bunch pages to find everything you're looking for (types, scheduling options, etc.) - maybe there's a page somewhere that has them all on one page? Daryn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SaiTeja Sent: Thursday, November 22, 2007 10:14 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Custom Action type 1042 and 18 Now I need Type as "1554". ... Return= ?? Execute="deferred" Impersonate=?? HideTarget=?? ... is there a way to find out the same or it is just trail and error - 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] Problems in running vbscript during install
Your CustomAction needs to be defined differently. Instead of ExeCommand, use VBScriptCall='' (value = blank to just run the script, or put the name of the VBScript function). ExeCommand attribute tries to execute an EXE, not run VBScript. Also I'm pretty sure that deferred custom actions have to be scheduled between InstallInitialize and InstallFinalize, which would mean you need to schedule yours earlier or make it an immediate action. (As found in Deferred CA description, http://msdn2.microsoft.com/en-us/library/aa368268.aspx) Daryn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of chandan Koushik Sent: Friday, November 23, 2007 12:03 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problems in running vbscript during install I am unable to ... call a vbscript file NOT Installed - 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] What do I do with per-user data when I uninstall?
Rob Hamflett wrote: > The general advice is usually to offer the option of deleting > files/settings for the current user. I like this, but as a beginner setup guy I'm unclear on where exactly I'm supposed to offer that option. My natural inclination is to put it in the UI during the uninstall step... but from Add/Remove programs there's only the minimal UI when the user click 'Remove'. If there's a way to change the default UI level then I guess that's the answer I need. Where do you give the user the option to delete? Daryn. - 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] Directory in user profile but not in RemoveFile table
> From: Jeff Hunsaker > Sent: Friday, June 08, 2007 1:55 PM > > I'm adding a program menu which should be created if it's not there. > Other programs install to this menu so I do not want to delete it > at uninstall. My XML looks like this: [...] > error LGHT0204 : ICE64: The directory scmworkbench is in the > user profile but is not listed in the RemoveFile table. I'm doing the same thing right now and I saw this entry when doing my wix-users search. Just for the record (as far as I understand), it's safe to have the RemoveFile for your Program Menu folder that shared with other products, because the action only removes folders that are empty, i.e. when there are no other shortcuts left in it. Daryn. - 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] Problem with registering COM dll
I see that the use of [INSTALLDIR] in the registry entry - perhaps edited by hand? - does not match the the TARGETDIR DirectoryRef. This is not guaranteed to be an error, e.g. if you've ensured that the two properties are equal, but it seems fragile. You can check the installed registry entries to see if they have the full path to WelcomeCOM.dll, or just the filename alone, to know if this is causing an error. Daryn. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ahn Ahn Liu Sent: Monday, August 06, 2007 3:34 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with registering COM dll I'm trying to register a COM component and followed the instruction on the tutorial - running tallow -c WelcomeCOM.dll. However, it does not appear to be successfully registering the object. The tallow outputs: http://schemas.microsoft.com/wix/2006/wi";> ... ... ... Any suggestion? - 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] Problem writing registry values
Anidil, Does it help if you pass Value='1' instead of Value='#0x0001(1)'? Daryn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil [...] Now that i don't get permission denied message after prefexing # for all the DWORD types as follows : http://schemas.microsoft.com/wix/2006/wi"; /> but i see that the registry is getting updated as type REG_SZ... :( - 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] How to call an exe
I found it very easy to debug a DLL CA with the debugger: I figured the DLL in the binary table has to be extracted before the code can be called, right? So the following seemed to work for me to debug an error I was getting while developing the CA: 1) Use a debug version of the DLL 2) Copy the .pdb file to C:\WINDOWS\Installer (hidden/system folder) - since it seems where the DLL gets extracted as a temp file during installation. 3) Attach the debugger to msiexec.exe. When I tried there were three instances running, but since my CA had 'no impersonate' it was easy, I could pick the one running as SYSTEM rather than as the installing user. Daryn _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Stevenson Sent: Tuesday, July 17, 2007 3:58 PM To: srinivas nomu; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to call an exe you can debug MSI DLLs - just not via the debugger (albeit maybe you can, as the links below made mention of info in MSI.chm, but I believe it is meant to be a lot of effort). _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of srinivas nomu Sent: Wednesday, 18 July 2007 7:33 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to call an exe I really fed up working with .dll as there is no debug available. Now I created an .exe with the same code. - 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] Is there a WiX element that will perform a "FindWindow"?
I don't know if there's a better way than this, but you could certainly make
a custom action to do it using WMI. The Win32_Process class lets you see if
there's a process running of a certain name, command line, etc.
('Win32_Product', http://msdn2.microsoft.com/en-us/library/aa394372.aspx)
There's plenty of examples available for VBScript, e.g. Microsoft's
Scripting Guy articles
(http://blogs.msdn.com/gstemp/archive/2004/02/13/72505.aspx).
There's not so many examples for C++ and I found using it for WMI had a fair
learning curve at first, whereas with VBScript it's quite easy. Having
mentioned the VBScript temptation, now would be an appropriate time to
insert a reminder of all the experts' warnings to avoid VBScript and use C++
DLLs for custom actions. ('VBScript (and Jscript) MSI CustomActions suck'
http://blogs.msdn.com/robmen/archive/2004/05/20/136530.aspx)
Daryn
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Daniel Gurney
Sent: Monday, May 21, 2007 2:33 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Is there a WiX element that will perform a
"FindWindow"?
I'd like to find out if an application is running. I don't want to close
the application. This is more of a boolean action that I am looking for.
-
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] Any interest in a beginner's tutorial?
Rennie, I'd be very happy to see a more beginner-oriented tutorial to help with getting started. I'm currently evaluating whether to switch from InstallShield to WiX, and there are still things I have not yet got running/tested in WiX. I'm a software developers who happen to also do setup -- as opposed to a hardcore setup guy. I think people like me who are considering WiX could certainly benefit from a tutorial focused on guiding beginners through a smaller set of tasks that would be found in a typical 'simple' installation. Your mention of dialog boxes and localization touches on the area that is causing my current pause: customizing the UI, which seems to have a steep initial learning curve... to an InstallShield user :) Daryn. -Original Message- From: Rennie Petersen [...] is there really any interest in yet another WiX tutorial? Mine is more introductory than the current "official" one, covers only the basic features in WiX, but does cover a few things like creating your own dialog boxes and localization more comprehensively. - 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] changing setup at runtime
Also for an concise example of using the Automation interface you might find it helpful to look at "WiRunSQL.vbs" in the Installer SDK / Platform SDK. Use of the script is described in "Examples of Database Queries Using SQL and Script" http://msdn2.microsoft.com/en-us/library/aa368562.aspx Daryn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Pavlik [...] look for the MsiSetProperty in the MSDN [...] - 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] Sequence of Install?
Does it fix that if you schedule it after='InstallFiles' instead of CreateFolders? Daryn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JCWrs Sent: Thursday, April 19, 2007 12:39 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Sequence of Install? Julie, thanks! That helped quite a bit. I'm still having one problem, however. When my CA runs it looks to see if the installed files are there by looking at INSTALLDIR. I've run the installer with the CA commented out and the files do get installed correctly. The CA program also works if I manually run it post Install. When I run it all together and schedule the CA for After CreateFolders, however, it errors off and says it cannot find the files. I assume the CA is running before the files are copied over? When is the latest I can call this CA during the install process? - 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] Error in German?
Kevin Burton wrote: > Durint installation I briefly see a German message appear during the "progress: dialog. When there is an error I see an error dialog piop up that is entirely in German. [] > Do you know how to change that? I've been learning WiX this week and I saw the same behaviour after I tested out localization. I had mistakenly left my Product tag with the wrong language attribute. I.e. I had: (German) when it should have been: (English) Daryn. - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wix-users
