Re: [WiX-users] msi Log when called from setup.exe
Balakrishna.BK wrote:
> Hi All,
>When I click on msi to install, I get an error message to
> install the software using setup.exe only. How can I bypass
> this and install from msi directly. Basically I need to
> create install log file.
>
> msiexec /i file.msi /l*v file.log
>
> I am expecting workarounds or suggestions to get install
> logging, which I am not able to get using setup.exe
1) Sometimes some setup.exe program allow to pass on msiexec
options from its own commandline. This is the clean way,
but possibly not available in your particular setup.exe.
2) Most likely your .msi checks for some kind of property
on startup and refuses to work if this property is not present.
Try to examine your .msi with Orca and look for a suspicious
properties ('INSTALLME', 'DIRECTINSTALL' or similar).
If you found something 'interesting', use
msiexec /i file.msi /l*v file.log DIRECTINSTALL=1
or similar to fool the .msi into thinking it was launched
from its setup.exe.
Andre'
-
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
Re: [WiX-users] Patching
I wrote: > Hi all. > > Is there a method to create a patch that is able to > update all stages of a given product? > > Say I have a product A.B.0 containing a certain exe. > This exe is changed in each patch, i.e. in 0->1, 1->2 > etc. > > I want a patch that's able to upgrade A.B.2 as well > as A.B.4 to, say, A.B.7. > > > http://www.nabble.com/Re:-Patches,-Versions,-Daily-builds,-and > -the-fire-tha-t-forges-us.-t1619603.html > > which indicates that I can just stick them together > and only the appropriate ones will be used. This works > indeed, I just tried it. > > However, a 'cumulative incremental' patch contains several > incarnations of the .exe and only the final one is really needed. > > Is there a way to create a patch containing only that > final version but which is still able to patch all > versions? Is multiple TargetImage entries the way to go? What is 'ReplacePatch' about? Andre' - 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] Patching
Hi all. Is there a method to create a patch that is able to update all stages of a given product? Say I have a product A.B.0 containing a certain exe. This exe is changed in each patch, i.e. in 0->1, 1->2 etc. I want a patch that's able to upgrade A.B.2 as well as A.B.4 to, say, A.B.7. http://www.nabble.com/Re:-Patches,-Versions,-Daily-builds,-and-the-fire-tha-t-forges-us.-t1619603.html which indicates that I can just stick them together and only the appropriate ones will be used. This works indeed, I just tried it. However, a 'cumulative incremental' patch contains several incarnations of the .exe and only the final one is really needed. Is there a way to create a patch containing only that final version but which is still able to patch all versions? Andre' -- André Pönitz, Software Developer WASY GmbH, Institute for Water Resources Planning and System Research, Waltersdorfer Straße 105, 12526 Berlin, Germany Register Court: Amtsgericht Charlottenburg, HRB 36263 Management: H.-J. G. Diersch, S. Kaden, I. Michels Phone: +49 30 67 99 98-0; Fax: +49 30 67 99 98-99 Web: www.wasy.de, E-Mail: [EMAIL PROTECTED] - 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
Re: [WiX-users] Extract properties from .msi?
Rob Mensching wrote: > MSI SDK ships with a VBScript that allows you to execute SQL > statements against an MSI. I think it is called WiSql.vbs or > WiRunSql.vbs or something like that. WiRunSQL.vbs, indeed. I'll havbe a look. Thanks, Andre' - 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
Re: [WiX-users] Extract properties from .msi?
Matthew Janulewicz wrote: > It also comes with a utility called 'Orca' which allows you > to open the tables in an MSI. I have used Orca pretty extensively, however there seems to be no scripting capabilities. > Also, in a pinch, you can run the msi with full logging on > and all the properties should be dumped at the end of the log: > > Msiexec /I mymsi.msi /l* out.txt This is actually a pretty good idea. Since I build the patches from administrative installations I have the installation logs already lying around anyway. Thanks for that hint. Andre' - 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] Extract properties from .msi?
Hi all. Is there a simple way to extract a propety from an .msi on the commandline? I seem to need the ProductCode of the UpgradeImage in the TargetProductCode item when creating a patch. [Is that true btw?] Andre' [Sorry for the extensive signature. New rules...] -- André Pönitz, Software Developer WASY GmbH, Institute for Water Resources Planning and System Research, Waltersdorfer Straße 105, 12526 Berlin, Germany Register Court: Amtsgericht Charlottenburg, HRB 36263 Management: H.-J. G. Diersch, S. Kaden, I. Michels Phone: +49 30 67 99 98-0; Fax: +49 30 67 99 98-99 Web: www.wasy.de, E-Mail: [EMAIL PROTECTED] - 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
Re: [WiX-users] Shortcuts in wix 3.0
Very Secret wrote: > I solved the problem by adding >Directory="ProgramMenuDir" On="uninstall" /> > > as suggested in another mail in this archive. > > However, my shortcuts does not become executable: > > > > > WorkingDirectory="INSTALLDIR" > Icon="myExe.exe" /> > > > > > Any ideas why? I still don't know what the canonical way to deine shortcuts in Wix 3 is, however, the following put in parallel (i.e. not nested in the ) works for me Andre' - 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
Re: [WiX-users] uninstall shortcut...
Alex Henderson wrote: > Sent: Sunday, February 18, 2007 10:44 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] uninstall shortcut... > > Right, so I added the dummy KeyPath registry entry, like so: > > Guid="0454D0FC-190C-42c9-9506-DBA17DECBCB2"> >Key="Software\ScreenArchitect\Uninstaller"> > > >Name="Uninstall" > Description="Uninstall Application" Directory="ProgramMenuDir" /> > > > And I built my MSI successfully, however during installation it fails to > create the shortcut, complaining that it can't find or write to the > destination directory - I have other shortcuts (for executable files) which > are being created just fine in the same location (but they're advertised > shortcuts)... am I missing something vital here? What's in the log file? Andre' - 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
Re: [WiX-users] Example Patch required
dave_c wrote: > For clarity. > > I should have added that when I ran evertyhing. I installed Error.msp which > laid down my foobar file. > When I applied the patch there were no updates to the Control Panel > Add/Remove programs but the updated foobar file was installed. In this control panel, do you have that 'show updates' (or similar) checkbox near the top checked? Andre' - 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
Re: [WiX-users] Example Patch required
dave_c wrote: > I'm on the lookout for a simple example that illustrates > patching using WIX. > > The functionality requried is > > Step 1. Apply original application and associated code. > Step 2. Apply a patch to some of the files from step 1 > Step 3. Have ability to remove the patch software, leaving > the original behind so system operates as previously expected. > > I was trying to follow the foobar example in the tutorial but it didn't seem > to do anything for me so was hoping someone could send me/direct me/create > and send something that includes the above functionality It sort of worked for me after fixing some warnings I got with Wix v3. What exactly did not work? Andre' - 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
Re: [WiX-users] Nested folders
Ricardo Lopes wrote: > I don't know why it install one component and not the other > (at least i can't find it) if they belong to the same feature > (and only one). You could have a look at the installation log (i.e. the file log.txt produced by running 'msiexec /l*v log.txt /i .msi' Andre' - 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
Re: [WiX-users] Patching
Me, myself and I wrote: > Simon Topley wrote: > > I'm not sure how much use this will be to you, but I ran into > > a large number of issues with patching, I haven't touched it > > in a while as we are now thinking a full re-release is going > > to be cleaner. I created a self extracting exe file using > > iexpress.exe (standard part of windows) and the command I > > used to launch my patch was not /p but /update... I can't > > rememeber why this is the case now but I do know it did work.. > > > > msiexec /update patch.msp /l*v log.log > > Thanks for that hint, but I get the same crash. Just for the record: The crash does not happen if source and target packages are administrative installs of the product (instead of uninstalled .msi). So I have a workaround now. Andre' - 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
Re: [WiX-users] Patching
Simon Topley wrote: > I'm not sure how much use this will be to you, but I ran into > a large number of issues with patching, I haven't touched it > in a while as we are now thinking a full re-release is going > to be cleaner. I created a self extracting exe file using > iexpress.exe (standard part of windows) and the command I > used to launch my patch was not /p but /update... I can't > rememeber why this is the case now but I do know it did work.. > > msiexec /update patch.msp /l*v log.log Thanks for that hint, but I get the same crash. Andre' - 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] Patching
Hi all. I am curently trying to create a working .msp with Wix v3 So far I followed the Wix v2 tutorial and created a .msp that is supposed to replace in file 'a.txt' the contents 'old stuff' by 'new stuff'. When I run msiexec '/l*v' PatchLog.txt /p patch.msp REINSTALL=ALL REINSTALLMODE=omus the client runs until it shows 'copying a.txt' and than stops responding. Hitting the Cancel button in the installer gui has no visible effect. After killing msiexec in the taskmanager the log file looks like: [] MSI (s) (8C:64) [12:04:22:101]: Executing op: ChangeMedia(,MediaPrompt=Please insert the disk: ,,BytesPerTick=32768,CopierType=0,,IsFirstPhysicalMedia=1)^M MSI (s) (8C:64) [12:04:22:101]: Executing op: ChangeMedia(,MediaPrompt=Please insert the disk: ,MediaCabinet=PCW_CAB_Patch101,BytesPerTick=32768,CopierType=2,ModuleFileName=C:\WINDOWS\Installer\1fb8cd19.msp,I MSI (s) (8C:64) [12:04:22:101]: Executing op: CacheBaselineFile(Baseline=0,FileKey=a.txt,FilePath=C:\Programme\WASY\TEST 1.1\a.txt,,Existing=1)^M MSI (s) (8C:64) [12:04:22:101]: Note: 1: 2318 2: C:\WINDOWS\Installer\$PatchCache$\Managed\CFF474C703D9DCED0B68B007801601F8\1.1.8\a.txt ^M MSI (s) (8C:64) [12:04:22:117]: Executing op: FileCopy(SourceName=a.txt,SourceCabKey=a.txt,DestName=a.txt,Attributes=4096,FileSize=11,PerTick=32768,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions MSI (s) (8C:64) [12:04:22:117]: File: C:\Programme\WASY\TEST 1.1\a.txt; Overwrite; Won't patch; Existing file is unversioned and unmodified - hash doesn't match source file^M MSI (s) (8C:64) [12:04:22:117]: Source for file 'a.txt' is compressed^M InstallFiles: File: a.txt, Size: 11'>^M MSI (s) (8C:64) [12:04:22:117]: Re-applying security from existing file.^M MSI (s) (8C:64) [12:04:22:148]: Verifying accessibility of file: a.txt^M MSI (s) (8C:64) [12:04:22:179]: SOFTWARE RESTRICTION POLICY: Verifying object --> 'C:\WINDOWS\Installer\1fb8cd19.msp' against software restriction policy^M MSI (s) (8C:64) [12:04:22:179]: Note: 1: 2262 2: ^EDigitalSignature 3: -2147287038 ^M MSI (s) (8C:64) [12:04:22:179]: SOFTWARE RESTRICTION POLICY: C:\WINDOWS\Installer\1fb8cd19.msp is not digitally signed^M MSI (s) (8C:64) [12:04:22:179]: SOFTWARE RESTRICTION POLICY: C:\WINDOWS\Installer\1fb8cd19.msp is permitted to run at the 'unrestricted' authorization level.^M MSI (s) (8C:64) [12:04:22:179]: Note: 1: 2318 2: C:\Programme\WASY\TEST 1.1\a.txt ^M MSI (s) (8C:84) [12:04:22:179]: Internal Exception during install operation: 0xc005 at 0x750D5A0E.^M MSI (s) (8C:84) [12:04:22:195]: WER crash report failed (4).^M MSI (s) (8C:64) [12:04:22:195]: Note: 1: 2350 ^M DEBUG: Error 2350: FDI Server Error^M The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2350. The arguments are: , , So this somehow looks like the server process crashed and the client is still waiting for some kind of notification. Now, assuming the crash is not supposed to happen, what could I do to prevent it? Has anybody else seen such behaviour? Regards, Andre' - 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
Re: [WiX-users] uninstall shortcut...
Alex Henderson wrote: > My client wants his installer to have an "uninstall" shortcut, but I can't > seem to quite get it right... after reading some posts I ended up with this: > > > > And also... > > Guid="F72CE94D-8E6E-4b9e-95BC-7DC80C3641B6"> > Name="Uninstall" > Description="Uninstall My Application" Directory="ProgramMenuDir" /> > > > However when I compile I get these errors (below)... what's > the right way to do it? I think the right way would be to get the validation rules fixed, but I guess that's not anption for mere mortals like us ;-) My personal workaround is to add a dummy registry entry under HKCU as keypath for the component as in ... This 'works' but obviously has the potential to leave rubbish in the registry. Andre' - 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] CostFinalize
Hi all. My boss is currently very disappointed with the startup times of my latest installers. It seems to spend a lot of time in the CostFinalize action [His machine is not much slower than mine, however the harddisk is nearly full, maybe that's an issue] Is there something I can do about it? On a related issue: I noticed that switching from Media/@EmbedCab='yes' to 'no' sped up things already enormously. I wonder whether there are similar 'tricks' wrt Costing... Regards, Andre' - 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
Re: [WiX-users] Specifying Backup location
Bob Arnson wrote: > [...] MSI doesn't let you configure rollback storage except to > disable it entirely. Can this be done from inside Wix? If so, how? Andre' - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in dark
Rob MacFadyen wrote: > To deal with dark crashes what I've done in the past is some creative > "editing" using Orcas. Usually this means removing any offending entries and > or tables that dark is having trouble with. From the error message it looks > like dark doesn't like the value in a column named "KeyColumn". Searching > the MSI docs for "KeyColumn" shows that this field only appears in the > _Validation table. What I recommend is deleting all the rows from the > _Validation table (or any where KeyColumn <= 0). Thanks for that hint, it helped indeed. The offending stuff was InstallShield related and this is to be removed anyway. Regards, Andre' - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Crash in dark
I get an unexpect result when running dark (Version 3.0.2211.0) on one of our old .msi files created by InstallShield. > dark -nologo -x data ../"GeoDAta eXchange.msi" geodax.wxs GeoDAta eXchange.msi dark.exe : error DARK0001 : Cannot set column 'KeyColumn' with value 0 because it is less than the minimum allowed value for this column, 1. Exception Type: System.InvalidOperationException Stack Trace: bei Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) bei Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindDatabase(String databaseFile, Database database, OutputType outputType, String exportBasePath) bei Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindDatabase(String databaseFile, OutputType outputType, String exportBasePath) bei Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file, OutputType outputType, String exportBasePath) bei Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args) When I run all ICEs on the .msi in Orca, I get about 50 warnings but no hard error. What could I do to get a skeleton .wxs for the .msi nevertheless? Andre' - 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
Re: [WiX-users] Set firewall exception
> David Thielen > It's all peer to peer, no server. So each AddIn listens for the UDP > broadcasts and replies to the broadcaster saying they exist. > > The broadcast occurs at startup and if the number of replies is greater > than the license allows that AddIn is disabled. So the first N can run, > the rest cannot. I can imagine a couple of scenarios - intentional and less intentional - where the answer won't reach the sender and so the sender would startup no matter how many instances of the plugin are already running. It's much harder to imagine how reliable licence management is supposed to work under such circumstances... Andre' PS: A bit more on topic: I also think that such configuration is not the business of the installer as it is very likely to fail and rollback will be messy. - 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
Re: [WiX-users] Setting all components to 64-bit by default...
Ravikumar Gopinath wrote: > Hi, > By default, WIX treats all components as 32-bit. Our > installation package will install either 32 bits or 64-bits > binaries and we don't have any mixed files going into > separate directories. Is it possible to mark all components > as 64-bit? Not as far as I know (which doesn't mean much, though...) > Without this, I would have to go to each > individual component and set its Win64 value to yes or no > based on whether it is being compiled for amd64 or x86 > platform. If I can mark all components as either 32 bit or > 64-bit at compile time globally, it would be great.I am > working with existing project which already has lots of > components. I want to avoid adding a variable/parameter to > each component if possible. I have Win64='$(var.Win64)' in all my components and run candle with '-DWin64=yes' and '-DWin64=no', respectively. Getting the Win64='$(var.Win64)' into all components initially was as simple as running perl -pi -e 's: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
Re: [WiX-users] Problem with nested install of SQL Express 2005inmy installer
Rob Mensching wrote: > There are many threads about the work going on in WiX v3 to > create a chainer. In fact, it's already there (even though > it needs a lot more work). There is also a chainer that > ships with VS (that is freely available, I think). > > Is this the ideal? No, but we (i.e. people who work on WiX) > are trying to address it by volunteering our time and > development expertise. I wasn't questioning the way Wix works but rather the general design of the Microsoft Installer system as far as I understand it right now (and I readily admit that my understanding might be completely wrong). MSI seems to focus on installing a single package. It is not geared towards higher level package management. Andre' - 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
Re: [WiX-users] light bogging down my machine
Rob Mensching wrote: > That is helpful. So, here's a bit more of breakdown: > > 1. 8 seconds, actual WiX processing (linking) > 2. 3 minutes 30 seconds, calculating file hashes and > assembly information > 3. 5 minutes, compressing files > 4. < 20 seconds, actual WiX processing to create MSI > 5. 2 minutes, 30 seconds, ICE validation > 6. 1 minute, 30 seconds, move files to the appropriate location > > Total: ~13 minutes > > It looks like 8+ minutes of your 13 minute build time is > spent in disk IO. How many files are in your setup? 5472 right now. > I've also seen virus checkers completely > annihilate build performance. If you can disable your virus > checker from scanning your build directories and TEMP drive > (or move to %WIXTEMP%), I've seen that help a lot. Direct hit. New numbers: 1. 9 seconds, actual WiX processing (linking) 2. 25 seconds (!!!), calculating file hashes and assembly information 3. 3 minutes 10 seconds (!), compressing files 4. < 20 seconds, actual WiX processing to create MSI 5. 2 minutes, 0 seconds (!), ICE validation 6. 7 seconds (!!!) move files to the appropriate location Total: ~6 minutes So step two was sped up by a factor of eight, and step 6 almost vanished. > Another 2 minutes appears to be spent in ICE validation. ICE > validation can be processor intensive and can take a while. > Unfrotunately, the Windows Installer team is the only one > that can improve the perf of that. You can turn off > validation but you'll miss the things it catches. I had to for a while because of the ICE 38/47/53 'errors' as I added the workaround with the dummy registry key only recently. > Finally, about 2 minutes is spent creating the MSI and move > all of the built files into a single release location. That > seems to be a bit long so it really makes me wonder if you > have a virus checker working hard. That was it. [Now my problem is that I am officially not allowed to turn it off but I guess that's off-topic here...] Thank you very much for your assistance. It is really appreciated. Regards, Andre' - 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
Re: [WiX-users] light bogging down my machine
Rob Mensching wrote: > What version of the WiX toolset are you using? [EMAIL PROTECTED]:~ > light Microsoft (R) Windows Installer Xml Linker version 3.0.2211.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. > That sounds like an unexpected performance problem. Glad to hear that it is unexpected ;-) > It would > be awesome if you wanted to do a little profiling to see if > there is one particular part of the processing that takes > longer than others. Just tell me what to do. > The verbose switch *might* give you enough info to track > down when light goes into "hog your machine mode". I just recorded the wall clock time for several stages. Maybe this helps in any way.. 09:06:11 [Start] 09:06:17 Updating file information. 09:09:49 Creating cabinet files. [Write 14 .cabs of varying size] 09:14:41 Generating database 09:14:xx start ICEs 09:16:37 Laying out media 09:17:09 [Done] There is sufficient space on all partitions. All NTFS on WinXP Pro. All from a plain cmd.exe. Regards, Andre' - 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 bogging down my machine
Hi all. I have the problem that longer runs of 'light' make my desktop machine basically unusable for any other task in that time (unless one counts the display of partially updated windows as 'task'...) I do not really understand the reason for that. Windows thinks my desktop machine has two CPUs with the consequence that other CPU intensive applications usually use only 50% of the 'full power' - at least when I restrict them to use only one processor in the task manager. 'light' differs and seemingly ignores that setting. They only way I can use my machine during the time light runs is to reduce the priority of the light task to the minimum - which otoh means it does not make any visible progress anymore. I could imagine that this is some consequence of the CLR implementation running in 'kernel mode'. Is that possible? If so, how could I restrict it to use one CPU only? Andre' PS: Is it common that 'light' needs _8 minutes_ to create a 200MB setup with 5500 components? It's hard to imagine that writing a few(?) table entries and a 200MB file needs _that_ long (this is without validation btw). Writing a file of that size filled with random numbers (including creating them) takes about 17 seconds so it does not seem to be a disk issue. - 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
Re: [WiX-users] Shortcuts and ICE
Tony Hoyle wrote: > André Pönitz wrote: > > One is not allowed to ignore ICE57 errors for Windows Vista > > logo certification (even if everybody agrees that the errors > > themselves are bogus and should be ignored ...) > > I'd try to talk them into changing that.. I am not sure this is worth trying. My experiences with Microsoft Support are rather frustrating. The best I got so far was the acknowledgment of an obvious bug including the statement that they don't see any reason to act on it... > Presumably they allow some ICE errors since some are inevitable due to > the design of MSI (case in point for our installer is an executable that > can run on the client or as a service.. it gives an ICE because it's in > two components, even though they're mutually exclusive conditionss). I certainly see a technical reason for not considering properties: They are highly dynamic and ICEs (can) do only statical analysis. So "it won't really work". However, it does not really "work" the way it is either because statical analysis means that the ICEs check things that are never relevant (annoying, but not necessarily bad) _and_ they do not check things that are relevant. This is not only also annoying but gives a false impression of security, too. Andre' - 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
Re: [WiX-users] Problem with nested install of SQL Express 2005inmy installer
Stefan Krueger [MVP] wrote: > A bootstrapper is the officially recommended method to chain > two msi setups. And what is the officially recommended method for creating chainers? "Everybody rolls his own from scratch"? It's hard to believe that such a basic functionality as chaining two installations has no canonical solution and a functionality like nesting two installations is considered 'deprecated'. Andre' - 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
Re: [WiX-users] Shortcuts and ICE
Johan Appelgren wrote: > On 1/8/07, André Pönitz <[EMAIL PROTECTED]> wrote: > > Johan Appelgren wrote: > > > So the answer to the initial question is that windows installer is > > > broken, and I should just ignore the ICE57 error? > > > > I think 'yes, and not necessarily'. Have a look at hack I just > > posted in the 'Solution for StartMenuFolder < x < StartupFolder ?' > > thread today. > > Okey, but wouldn't it work better if you use HKMU and ignore the ICE57 > error for the registry value that is key path for the component that > contains the unadvertised shortcut? One is not allowed to ignore ICE57 errors for Windows Vista logo certification (even if everybody agrees that the errors themselves are bogus and should be ignored ...) > I can't figure out what issues I might run into that the ICE57 > error is there to help me avoid. Me neither, at least not in this particular incarnation. But there seems to be a requirement that any non-empty set of requirements sufficiently close to the topic of Windows installations must contain at least one completely braindead rule. > I need to support both per-user and per-machine installs. For me pre-machine would alreeady be sufficient, but even that seems not be possible. Andre' - 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
Re: [WiX-users] Shouldn't WiX be Production/Stable instead of Beta?
I wrote: > Scott Palmer wrote: > > I don't know if it is possible, but I would love to see some > > sort of simple auto-layout for UI components > > I guess it should be only a few hours work to take any > graphical GUI creation tool with human readable form > files and convert its output to something able > in WiX. Qt 4's designer comes to mind. It stores the > forms in XML files and comes (also) for free (speech+beer). ... whcih, of course, won't help with the problem of worss of different size, yet help with the general problem of quickly designing a custom dialog. Andre' - 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
Re: [WiX-users] Shouldn't WiX be Production/Stable instead of Beta?
Scott Palmer wrote: > I don't know if it is possible, but I would love to see some > sort of simple auto-layout for UI components I guess it should be only a few hours work to take any graphical GUI creation tool with human readable form files and convert its output to something able in WiX. Qt 4's designer comes to mind. It stores the forms in XML files and comes (also) for free (speech+beer). Andre' - 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
Re: [WiX-users] Shortcuts and ICE
Johan Appelgren wrote: > So the answer to the initial question is that windows installer is > broken, and I should just ignore the ICE57 error? I think 'yes, and not necessarily'. Have a look at hack I just posted in the 'Solution for StartMenuFolder < x < StartupFolder ?' thread today. > I'm trying to use unadvertised shortcuts and haven't been able to find > out the recommended way to create them. So far I believe there is no clean solution. In fact, I am more than happy to have found something seemingly 'working'... Andre' - 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
Re: [WiX-users] Solution for StartMenuFolder < x < StartupFolder ?
Tony Hoyle wrote: > André Pönitz wrote: > > > > Tony Hoyle wrote: > >>> Simply using [StartupFolder]\Programme does not cut it as the 'Programme' > >>> part is language-dependend. > >> ProgramMenuFolder > > > > But with ALLUSERS=0 [ProgramMenuFolder] is in the user's hierarchy > > whereas StartupFolder and StartmenuFolder are under 'All Users' > > > > I basically want access to 'All Users\Program Files' > > [if that make sense...] > > > > If ALLUSERS=0 then you're installing for the local user only > - modifying > the global program files menu in this case would be an error. Well, my people will always run the installer with ALLUSERS=1. However the thing needs to pass validation and the ICEs do not seem to resolve properties. So it does not need to actually work with ALLUSERS=0, it should just look to the ICEs like it would. I just found a pretty ugly hack to get rid of the (bogus IMO...) ICE 38/43/57 errors: The problem is that the ICEs think that ProgramMenuDir is a per-user setting (which it is for ALLUSERS=0, but not in the scenario my users will see) and so it requires a registry value in HKCU as keypath. So I just give them one, even if this is never used. Does anybody see anything wrong (apart from being a horrible hack...) with this approach? Andre' PS: Anyone out there who's already build a Vista-Logo-Program 'compatible' Wix v3 installer with start menu entries? - 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
Re: [WiX-users] Solution for StartMenuFolder < x < StartupFolder ?
Tony Hoyle wrote: > > Simply using [StartupFolder]\Programme does not cut it as the 'Programme' > > part is language-dependend. > > ProgramMenuFolder But with ALLUSERS=0 [ProgramMenuFolder] is in the user's hierarchy whereas StartupFolder and StartmenuFolder are under 'All Users' I basically want access to 'All Users\Program Files' [if that make sense...] Andre' - 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] Solution for StartMenuFolder < x < StartupFolder ?
Hi all. There seems to be 'automatic' properties StartupFolder (here locally: C:\Dokumente und Einstellungen\All Users\Startmenü\Programme\Autostart) and StartMenuFolder (here locally: C:\Dokumente und Einstellungen\All Users\Startmenü) However, I'd like to access the level inbetween, i.e. C:\Dokumente und Einstellungen\All Users\Startmenü\Programme Simply using [StartupFolder]\Programme does not cut it as the 'Programme' part is language-dependend. Is there a method to get what I want (short of running a CA of my own)? Andre' - 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
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
Arnette, Bill wrote: > Non-Windows Installer installers use the SharedDlls registry > key to refcount the usage of common/shared dlls. By default > Windows Installer will only increment that refcount if it > already exists so that the other installer will track the > refcount properly if a WI installer installs the same file. > Windows Installer also maintains its own refcount for > components it tracks elsewhere. You can force Windows > Installer to create a SharedDLLs entry if it doesn't already > exist with the msidbComponentAttributesSharedDllRefCount > attribute on a component. So this is what the SharedDllRefCount='yes' attribute means... Let me try to get the consequences for me straight: if I have an old installer using the SharedDll mechanism and new installers are msi based (and will stay so for the forseeable future) I would not have to explicitly use SharedDllRefCount='yes' and it'd still work if I install my newer version in parallel (yes, we do that...) to the older version and I could deinstall in arbitrary order. It would not work, however, if I installed the new version first and than the older one in parallel. But as that's not a scenario I need to support, I'd be ok without using the SharedDllRefCount='yes' attribute. Did I get that right? > So what that log indicates is that a non-WI installer > installed that file before your product was installed and > that since the SharedDlls refcount will not go to 0 after > your product is uninstalled, the file will not be removed so > that the other product is not broken. Ok, that's probably exactly what happens as I have an older version installed (or at least not fully uninstalled) Thanks for the explanation, Andre' - 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
Re: [WiX-users] Creating features with lots of components
Matthew Janulewicz wrote:
> I don't think there is an elegant way to do this, as the Wix
> tools (or any other tools for that matter) can't predict what
> ComponentRef's you want under which features.
Everything under a certain directory put in one feature seems
to be a fairly good first approximation. If you need more
features, put the sources into different trees and run the script
twice.
I have a ~70 line perl script for doing exactly that and it
was all I needed so far. I am willing to share that... Urm...
I suppose it is ok to simply attach it here although it looks
a bit underdocumented for the non-initiated ;-{
Have fun.
Andre'
list_dir.pl
Description: list_dir.pl
-
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
Re: [WiX-users] Trouble with Shortcuts...
Mike Dimmick wrote: > If you don't think you need install-on-demand, > repair-on-launch, or the ability for domain administrators to > advertise software through Group Policy, by all means use > non-advertised shortcuts. Which, unfortunately, does not seem to work with Wix v3 and validation. At leat not with a Shortcut element. That's where we started off IIRC. Regards, Andre' PS: I've already seen quite a few cases of software that try to go through repair on each and every attempt to use the shortcut. Adding to that the overhead of anything .msi related basically rules out the use of these shortcuts... - 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
Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> André Pönitz
> Sent: Wednesday, December 20, 2006 12:34 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Installed: Local; Request: Absent; Action: Null ?
>
>
>
> Can anybody explain me why I get the 'Action: Null'
> "decision" in some cases, but not in all?
>
> MSI (s) (68:C0) [12:28:49:678]: Component: Hasp_52;
> Installed: Local; Request: Absent; Action: Absent
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenu;
> Installed: Local; Request: Absent; Action: Absent
> MSI (s) (68:C0) [12:28:49:678]: Component:
> NetlmProgramMenuWasyTools; Installed: Local; Request:
> Absent; Action: Absent
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_1;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_2;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_3;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientHelp;
> Installed: Local; Request: Absent; Action: Null
> MSI (s) (68:C0) [12:28:49:678]: Component:
> NetlmClientProgramMenu; Installed: Local; Request: Absent;
> Action: Absent
>
> A difference is that the 'Client' is in an Fragment, the rest
> is in the main body of the installer.
Some more information from the log:
MSI (s) (68:E4) [12:40:17:485]: Executing op:
ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137EAABD18C},,BinaryType=0,)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{E88B9844-688B-40FA-8BD3-E137EAABD18C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137EAABD1DA},,BinaryType=0,)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{E88B9844-688B-40FA-8BD3-E137EAABD1DA}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3131390C},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{F0A3B0D2-F9C6-C00F-8817-DAAC3131390C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3231390C},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{F0A3B0D2-F9C6-C00F-8817-DAAC3231390C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3331390C},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{F0A3B0D2-F9C6-C00F-8817-DAAC3331390C}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC31313AAA},,BinaryType=0,PreviouslyPinned=1)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{f0a3B0D2-F9C6-C00F-8817-DAAC31313AAA}
MSI (s) (68:E4) [12:40:17:501]: Executing op:
ComponentUnregister(ComponentId={E88B9844-688B-C00F-8BD3-E137EAA1D18C},,BinaryType=0,)
1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2:
{E88B9844-688B-C00F-8BD3-E137EAA1D18C}
The not-removed componets are the ones that have the
'PreviouslyPinned=1' part which a Google Search turns into
entries in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
Now the question: By what installer mechanism do entries turn up in this
location and under which circumstances are they useful?
Andre'
-
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] Installed: Local; Request: Absent; Action: Null ?
Can anybody explain me why I get the 'Action: Null' "decision" in some cases, but not in all? MSI (s) (68:C0) [12:28:49:678]: Component: Hasp_52; Installed: Local; Request: Absent; Action: Absent MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenu; Installed: Local; Request: Absent; Action: Absent MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenuWasyTools; Installed: Local; Request: Absent; Action: Absent MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_1; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_2; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_3; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientHelp; Installed: Local; Request: Absent; Action: Null MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientProgramMenu; Installed: Local; Request: Absent; Action: Absent A difference is that the 'Client' is in an Fragment, the rest is in the main body of the installer. Andre' - 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
Re: [WiX-users] zip program for bootstrapper & msi
David Thielen wrote: > I took a look at 7Z but according to it's docs it doesn't > even have self-extracting zips. So either you haven't looked hard enough (which I don't want to imply) or docs are wanting nowadays in general... I have the following snippet in my Makefile for creating a self-extracting archive containing a 'foreign' .msi and a custom transform: $(Prefix)/$(SetupExe): $(Source)/$(Product).7z Makefile ( \ cat 7z/7zS.sfx ; \ echo ';[EMAIL PROTECTED]@!UTF-8!' ; \ echo 'ExtractTitle="Extracting $(Product) installation data..."' ; \ echo 'RunProgram="hidcon.exe msiexec /i $(Msi) /qr TRANSFORMS=Trans.MST"' ; \ echo ';[EMAIL PROTECTED]@!' ; \ cat $(Source)/$(Product).7z \ ) > $@ chmod a+x $@ $(call Cert,$(Description),`cygpath -m [EMAIL PROTECTED]) It works rather nicely. Andre' - 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
Re: [WiX-users] zip program for bootstrapper & msi
> Can anyone suggest one to use to unzip the 2 files and then > launch the bootstrapper? I'd try 7z. Andre' - 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
Re: [WiX-users] Trouble with Shortcuts...
Bob Arnson wrote: > Scott Palmer wrote: > > Then I get the following error: > > Error LGHT0204: ICE43: Component thing1 has non-advertised shortcuts. > > It should use a registry key under HKCU as its Error LGHT0204: ICE57: > > Component 'thing1 ' has both per-user and per-machine data with a > > per-machine KeyPath. > > > > To which I say "Huh?" The ALLUSERS property is set to "1" so I don't > > understand why it claims that there is per-user data. > > Because properties can be changed at install time, the ICEs don't > discriminate. The current behaviour certainly makes sense from a purely technical point of view. However, in practise one seemingly has to disable (some) ICEs just to get some of the most common features compiled. So the 'default' ICEing is far less useful than it might be. > > But the "new" ways don't have an attribute to set the registry key as > > the KeyPath for the component. [blood pressure rising...] > > Um, RegistryValue/@KeyPath? May I ask you (please, please, with extra sugar ;-)) to write down a (semi-)complete piece of Wix v3 code that installs a shortcut in HKLM and compiles without disabling any ICEs? While it may be completely obvious to you it is far from obvious for people that do not do installations as full-time job. Andre' - 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
Re: [WiX-users] Conditional Install
Jonas Abrams wrote: > Hey everyone, Hi. > I am trying to base the installation of a feature in my > install on a property that gets set through a custom action > and have been unable to get it to work correctly. These are > the steps that I am following: > > > > I first set up my property: > > > > > > Now I have my feature information (I have tried with and > without the '[]' around the property): > > Description='The Feature' Level="1" > ConfigurableDirectory='INSTALLDIR'> > > [PREREQ] != > "1" > > > > > > > > > > I have my custom action set up like this within the > InstallUISequence element: > > > > > > Does this look correct? Is there something I'm missing? I am not sure it can work this way. I use in a similar situation 'Remove' and 'AddLocal' in the 'Next' button 'handlers' of the dialog leading the the customization page, i.e. something like "Yes" LICENSEMODE = "demo" LICENSEMODE = "client" LICENSEMODE = "network" This selects/deselects an item in the feature tree. Andre' - 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
Re: [WiX-users] Trouble with Shortcuts...
Scott Palmer wrote:
> I'm using WiX3.
> I am trying to make a shortcut as part of installing a
> component. The shortcut is to a launcher application that is
> installed in another component with a command-line argument
> that has the path to a file in the component that contains
> the shortcut.
>
> [...]
>
> Is it just me or does everyone else find working with MSI
> infuriating ? I'm worried that I will be driven to do
> something violent... ;-)
It's not just you. A huge time sink, unfortunately the
other options to create Windows installers seem even worse...
And no, I haven't found a non-complaining way to install
shortcuts with Wix v3 either.
In my little world there's now a big sign saying 'It doesn't
work in Wix v3 at all'. I don't care too much whether this
is true or not, but it helps keeping the bloodpressure low.
Btw, just ignoring the warning works. Right now I have those
parts of the installer code that can't be validated in
[Shortcut stuff]
blocks and pass -DValidation={0,1} on the commandline.
This way at least partial validation is possible.
Andre'
-
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
Re: [WiX-users] logging of RemoveExistingProducts
Dana Gutride wrote: > When the already installed version was created, were those > uninstall custom actions included in it? The installed MSI > is called to handle the uninstall sequence, any changes you > make to your uninstall sequence will only affect the new > installers you create. > > As far as your logging question goes, you should be able to > see those actions (if they are in fact included) and the > other stuff that is happening when the cached msi is removed > by using l*v. Ok, thanks (also to Stefan Krueger). A typical example of PEBKAC: The condition of the custom action was wrong. I see the deinstallation now as expected. Andre' - 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
Re: [WiX-users] Automating maintenance of component lists
Steve Bennett wrote: > Hi all, Hi Steve. > I'm trying to automatically maintain wix source files to > generate a .msi as the final stage of a build process. That > is, each time a build is done, I'd like to update a wix > source file to refer to the latest set of files that are > designated as being in the release. It's quite important to > us that this be automated, as we're trying to reduce the > number of file lists that need to be hand-maintained down to > a very small number... > > I'm sill new to WiX, but so far I can see three pretty > different ways to do this: > > 1) "Manually" generating the tree structure by > writing code to traverse directories and generate code, guids > and component ids. > > 2) Using tallow from WiX 2.0 to generate a fragment, then > link it in. (Not sure about the linking process yet, but it > looks easy enough) > > 3) Using heat from WiX 3.0 to do basically the same thing as 2). All of them seem to work given my very short experience with Wix. I am using 1) right now since I need a bit of customization (like ignoring certain subdirectories, some renaming), but I have temporarily used the others, too. > However, I'm seeing warnings everywhere that generating Guids > automatically (with the -gg options on both tallow and heat) > is a Bad Thing (tm). For example, Tallow gives this warning > (annoyingly mixed into stdout): WARNING: AUTOMATICALLY > GENERATING GUIDS IS A DANGEROUS FEATURE BECAUSE IT MAY CA > USE COMPONENT RULES TO BE BROKEN. PLEASE READ THE FOLLOWING > ARTICLES TO LEARN MORE ABOUT THE COMPONENT RULES. I chose to ignore this particular warning as I have not found any case where the automatic component naming makes things worse than manual naming. Yes, I tried simple upgrade scenarios. Note that this does not mean that component management works in all cases: As soon as some 'legacy' installer messes with your files or if some other installer happens to install the same files using different component guids, the whole thing will get messed up anyway. So the whole compoment management thing seems a bit like an overengineered warning sign that does not add any structural security (the files would need to be under exclusive manage- ment of the installer system or such)... > Also, Derek Cicerone's blog on Heat explicitly says you're > not supposed to attempt to automatically maintain setup > files: "Heat is designed to allow a setup author to very > quickly generate their setup authoring the first time. From > then onward, the authoring should be maintained manually to > ensure that guids and identifiers remain stable and component > rules are not broken." > Does anyone have any thoughts, comments or suggestions on > what the best way to handle this is? Since we probably don't > really intend to track Guids anyway, or attempt to perform > upgrades at this fine-grained component level (the whole > product is under 10 meg), is it safe to disregard these > warnings? How do other people automatically maintain WiX > setup files, presuming that it is indeed safe and desirable to do so. Well, personally I think it is far more dangerous to leave any manual steps in the build process than to have some fairly well defined pitfall in an automated setup. Andre' - 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] logging of RemoveExistingProducts
I have a product that needs to run custom actions
when uninstalling. This works.
However, when trying to install a major upgrade
on an already installed version the older version
is properly found (i.e. I get something like
MSI (s) (3C:DC) [09:51:36:582]: PROPERTY CHANGE:
Adding NEWERVERSIONDETECTED property.
Its value is '{7F141428-1AC6-46F5-9915-763C2F1D5F11}'.
in the log) but it looks as if during its
deinstallation the custom actions do not run.
Ordinary deinstallation works just fine.
Is there a way to see the stuff that happens
when 'RemoveExistingProducts' somehow in the log
file (I am using /l*v already)
Andre'
-
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
Re: [WiX-users] New Official Installation Technology? CBS? What?
André Pönitz wrote:
> Rob Mensching wrote:
> > Is MSI that bad? I mean, I know that declarative programming
> > is very different from procedural programming but the Windows
> > Installer handles a lot of things very well. Probably my
> > biggest gripe is that the Component Rules suck. Is there
> > something you think is worse in MSI?
>
> One of my biggest gripes with MSI so far is that it dead slow
> (which is, of course, a very subjective impression).
Point two is the inability to nest ("foreign .msi") installers btw.
Andre'
PS: Is there a simple way to figure out which (installed) file belongs
to which component of which packages?
-
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
Re: [WiX-users] New Official Installation Technology? CBS? What?
Tony Hoyle wrote:
> André Pönitz wrote:
> > One of my biggest gripes with MSI so far is that it dead slow
> > (which is, of course, a very subjective impression).
>
> Not so subjective when it comes to patching... VS2005 SP1 took 6 hours
> on one machine here. 30 minutes even to get to the EULA.
It took here more than a minute to show any kind of progress
(including the initial 'Wait' screen) so in my first attempt
I managed to start three of those beasts because I thought
I might have failed to click on the right link...
> Average is 2-3 hours. Much longer than it takes to install
> the product in the first place...
Been there, done that. Unfortunately ;-{
And deinstallation (service pack alone) takes the same time, if not more...
> There was a blog entry a while back where they explained what the
> problem was... to do with the way MSI does everything in memory IIRC -
> it can't stream a large patch from disk so you end up with your machine
> mostly in swap (650mb for the patch + working space for the
> transformations on a 32bit machine is getting close to the limits).
I have 1G of RAM here, and even though I don't remember the exact times
of the VS2005 SP1 installation I do know that while VS2005 SP1 was
deinstalling I set up and configured one and a half virtual machines
with *cough* undisclosed operating systems. Complete with compiler and
all the stuff nobody ever needs (I need 14 of them in the end, *sigh*)
Of course, this happend on a second machine, the one deinstalling
VS SP1 was not exacly usable in that time...
The positive aspect of this is that with the proliferation of msi based
installers one does not look too bad when compared with the average ;-)
Andre'
-
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
Re: [WiX-users] New Official Installation Technology? CBS? What?
Rob Mensching wrote: > Is MSI that bad? I mean, I know that declarative programming > is very different from procedural programming but the Windows > Installer handles a lot of things very well. Probably my > biggest gripe is that the Component Rules suck. Is there > something you think is worse in MSI? One of my biggest gripes with MSI so far is that it dead slow (which is, of course, a very subjective impression). I understand that the amount of work MSI is doing under the hood takes some time and I don't expect the security given by the MSI way (ability to rollback, repair options, clean uninstall) coming for free, and in my eyes the advantages of MSI(/Wix) outweigh the disadvantages (that's why I ended up using it, after all...) However, an installation time exceeding e.g. a quick-and-dirty NSIS based install by a factor of four(!, and I had even worse cases) is hard to explain to both management and customers. Maybe I am doing something completely wrong, but I don't have the feeling my installers behave worse than other MSI based installers of applications of comparable size, so I don't feel too guilty yet... Andre' - 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
Re: [WiX-users] Need to set a registry value owned by anther product
Harvey Werner wrote:
> I tried the following. It works for the install, but on
> uninstall it removes ProgramArguments from the registry which
> is obviously not what I want. I just want to set it's value
> to null and leave it alone.
>
> Key="SOFTWARE\\\service\Started Processes\dlm"
> Name="ProgramArguments" Type="string" Value=" " Action="write" />
>
>
> How is this done?
I'd try a custom action:
In the InstallExecuteSequence:
some condition
and in ca.c
#include
#include
//The SDK is clear: the signature of a custom action should be:
//UINT __stdcall CustomAction( MSIHANDLE hInstall )
//_tcslen strlen strlen wcslen
__declspec(dllexport) int write_helper(wchar_t * key, wchar_t * cmd, int seq)
{
HKEY hk;
DWORD dwDisposition;
RegCreateKeyEx(HKEY_LOCAL_MACHINE, key, 0, L"", 0, KEY_READ | KEY_WRITE,
NULL, &hk, &dwDispos
RegSetValueEx(hk, L"Sequence", 0, REG_DWORD, (LPBYTE)&seq,
(DWORD)sizeof(seq));
RegSetValueEx(hk, L"InstallCommand", 0, REG_SZ, (LPBYTE)cmd,
(DWORD)(wcslen(cmd)+1)*sizeof(w
RegCloseKey(hk);
return 0;
}
__declspec(dllexport) int write_key()
{
return write_helper(
L"Software\\...\\..\\...",
L"your value",
100
);
}
Something like that used to work for me in a similar case.
Might be complete overkill, though...
Andre'
-
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
Re: [WiX-users] he cabinet 'setup.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remo
> Rob Mensching wrote: > Was this issue ever figured out? Wouldn't the 'EmbedCab = "yes"' stanza be responsible for such a 'warning'? Andre' - 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] Shortcuts/Fileassociation validation in Wix v3
Ok, let's try again. I have the following code in my test installer. The installer 'works just fine'. I.e. it installs the file, a program menu entry, a desktop entry, and a file association. However, it also fails validation: u:\src\fesetup\test\setup.wxs(79) : error LGHT0204 : ICE38: Component desktop_folder installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. u:\src\fesetup\test\setup.wxs(89) : error LGHT0204 : ICE38: Component program_menu installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. u:\src\fesetup\test\setup.wxs(79) : error LGHT0204 : ICE43: Component desktop_folder has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file. u:\src\fesetup\test\setup.wxs(89) : error LGHT0204 : ICE43: Component program_menu has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file. u:\src\fesetup\test\setup.wxs(101) : warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg312CD77B1D0E10687395CB75D9609CD7' of the Registry table belongs to component 'association'. However, the formatted string in column 'Value' references file 'Makefile' which belongs to component 'data'. Components are in the same feature. make: *** [Test/1.1-2-x86/Test.msi] Error 204 So I wonder how does a minimal example of Wix code look like that has above mentioned functionality _and_ passes validation. Andre' - 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
Re: [WiX-users] Shortcuts/
[EMAIL PROTECTED] wrote: > I have a very similar issue whereby Vista Logo testing > automatically fails any component that has more than one > shortcut within it. As such I have removed a shortcut from > the component containing the app's main executable and have > created a new component that installs an LNK file (a copy of > the advertised shortcut) into the second location - the > Desktop, for argument's sake. The code looks like this... > > >Guid="YOURGUID----" DiskId="1"> >Key="SOFTWARE\[Company]\[App]\[Version]\Install"> >Type="integer" /> > >Compressed="yes" src="Installs\ShortCut.lnk" /> > > > > The problem is that I now get a validation error in ICE57 > thinking that the "DesktopFolder" is a per-user location and > that the "HKMU" keypath can be either per-user or > per-machine. That's exactly my problem. > Whereas, we all know that the "DesktopFolder" > will resolve to either a per-user or per-machine location > just as the "HKMU" keypath will - depending on the value of ALLUSERS. > > The validation is very dumb, but Vista Logo relies upon it. > I have a workaround, but it's very untidy and I hate it... at > the end of the day, the "HKMU" keypath should satisfy > validation's need for a keypath that matches the component's > per-user/per-machine state. But the code you showed above is not that workaround, is it? It does not yield any improvements in terms of less errors in validation as faras I can tell. Regards, Andre' - 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
Re: [WiX-users] Convincing customer to use WiX toolset - isit enterprise ready?
Bob Arnson wrote: > André Pönitz wrote: > > However, this page only contains three "Sponsor Links", > > no trace of any Wix related documentation at all. > > > > This gives the wrong impression IMHO. > > Anyone can contribute documentation. I was not aware that mere users were supposed to contribute documentation. No offense meant. Seriously, I have a few more Wix related items bookmarked, so I seemingly found them interesting when struggling to become aquainted with Wix: http://weblogs.asp.net/lorenh/archive/2004/05/09/128899.aspx http://installing.blogspot.com/ http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx And maybe the connection to the MS installer could/should be emphasized a bit. A top-level link to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/windows_installer_guide.asp wouldn't be the worst thing to do in my eyes... When the mailing list was down on SF I got access to it via http://www.nabble.com/wix-users-f4470.html Given the fact that SF operation is generally somewhat shaky a link to such a backup just in case would not hurt either. > I added three links and deleted a bunch of spam. Took five minutes. Thank you. Looks much better now. Andre' - 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
Re: [WiX-users] Convincing customer to use WiX toolset - isit enterprise ready?
Rob Mensching wrote: > 2. There is a block of documentation in the WiX.chm file > that should be in every binaries.zip. You can also go to > http://wix.sourceforge.net and see the online manual and the > online tutorial there. We can always use more documentation > but there is definitely documentation available. When one accesses SF "the SF" way, documentation will be expected at http://sourceforge.net/docman/?group_id=105970. However, this page only contains three "Sponsor Links", no trace of any Wix related documentation at all. This gives the wrong impression IMHO. Andre' - 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
Re: [WiX-users] MSVC8 redistributables?
John Calcote wrote: > Funny - you'd think that Microsoft would be using these same > merge modules for their own applications that want to install > the MSVC runtime libraries in the side-by-side. In that case, > wouldn't they have worked out all the bugs long ago? Well, it's not exactly bugs, it just raises lots of warnings. So it is "useable" and "works". Then, I wouldn't think they'd use merge modules extensively thmenselves. I think I read something on this list here that use of merge modules is discouraged in general. I have not bookmarked it, though. > I guess I'm being a bit sardonic here - it's clear to me that when > things like this happen, it shows that the provider has their > own way of doing things. [Sure. And Microsoft has a long record of not doing things the Microsoft way. I have a book in front of me called "Windows User Experience" printed by Microsoft Press. It basically describes the do's and don't's of Windows UI development. I have yet to see a single (recent or not) MS application that comes even close to adhering the rules given there... And my long time favourite (which might be an urban legend, though...) is that MS does not use SourceSafe for version control themselves... But I think they are not to be blamed (alone). I guess there are only a few software companies out there that eat their own dog food exclusively ;-)] > I don't like the idea of working around the issue by > statically linking library support - the entire purpose of > the side-by-side cache is to allow multiple versions of a > library to be installed - in effect, it's Microsoft's answer > to Linux/Unix's built-in library versioning system. Since > DLL's aren't normally named "something.dll.x.y.z" (and even > if they were, the operating system wouldn't try to interpret > the values), they needed a secure way of installing multiple > versions of a library and have apps use the ones they care > about without conflicts. Right. And I think the proper solution would be to use the merge modules in the final installers. Nobody ever got fired for doing it the MS way *cough* > Anyway, I just wondered if there were some WIX approved way > of adding the redistributable package. It appears that we > just use the merge-module technique, or statically link the libraries. *shrug* I am a novice. I have successfully incorporated a third party .msm (some dongle driver), the MS merge modules also work (as stated above). Merge modules generated by VS deployment projects do not seem to work well, though. Within my own setup from my (very short!) experience I'd say Fragments are the first choice, followed by . No need for merge modules internally. > BTW, there is also a separate installation utility (.exe) for > redistributables - vcredist... .exe, but I'm fairly certain > this is not the proper way to integrate into WIX installers. Uh... never heard of that... Andre' - 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
Re: [WiX-users] Network based installations?
> I wrote: > > Mike Dimmick wrote: > > > See 'Internet Download Bootstrapping' in MSDN Library, at > > > http://msdn.microsoft.com/library/default.asp?url=/library/en- > > > us/msi/setup/internet_download_bootstrapping.asp. > > > > Looks very promising. > > ... however, I failed when trying to implement it. An one more post talking to myself: > Has anybody succeeded in creating a web based installation using > WinXP SP2 targetting Win2k+, using Windows Installer 3.0? It 'works' now. I just changed my initial 'https:' based setup to 'http:'. Is this some kind of known limitation that this kind of installation only work over non-secure http? Andre' - 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
Re: [WiX-users] Network based installations?
I wrote:
> Mike Dimmick wrote:
> > See 'Internet Download Bootstrapping' in MSDN Library, at
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-
> > us/msi/setup/internet_download_bootstrapping.asp.
>
> Looks very promising.
... however, I failed when trying to implement it.
So far I have:
- put msi, cabs, said 'setup.exe' modified by msistuff,
and instmsi{A,W}.exe on a web site.
- start the setup.exe from there.
A dialog pops up telling me that the issuer could not be
verified (so I propbably missed to put that in somewhere,...)
I click 'execute' nevertheless.
A window named 'Windows Installer Installation Wrapper' shows
up for a very short time and that's it.
I am pretty sure the web server as such works.
I've tried to follow
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/a_url_based_windows_installer_installation_example.asp
but that seems to require Windows Installer 2.0, so far I assumed 3.0.
So maybe it's not the appropriate receipt to follow.
Moreover, I did not find setup.exe on my system, but
sources in C:\Programme\Microsoft Platform SDK\Samples\SysMgmt\Msi\setup.exe
which I compiled.
instmsi{A,W}.exe I got from
C:\Programme\Microsoft Visual Studio\COMMON\Tools\VSInst\BuildRes
Has anybody succeeded in creating a web based installation using
WinXP SP2 targetting Win2k+, using Windows Installer 3.0?
If not, should I try Windows Installer 2.0?
Any hint is appreciated.
Regards,
Andre'
-
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
Re: [WiX-users] conditional components
Stefan Pavlik wrote: > I would prefer to use C++ Custom Action DLL. You should use the > RegSetValueEx() function to write the values to registry. > http://msdn2.microsoft.com/en-us/library/ms724923.aspx Just for the record: I just found out why the uninstall CA was not called: The feature on which they were conditioned did not contain any components anymore, so it was not considered as 'installed' when the installer run. Puttting a dummy component in the feature 'helps'. Andre', wondering what the clean solution might be... - 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
Re: [WiX-users] conditional components
Stefan Pavlik wrote: > The Registry Table of Windows installer does not support such > action. see MSDN: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/registry_table.asp Too bad... >>> If you need during uninstallation to write something to registry you >>> should write the CustomAction for it. >> >> I already tried to do so but failed to figure out how to >> write a registry key from a custom action. > >I would prefer to use C++ Custom Action DLL. You should use the >RegSetValueEx() function to write the values to registry. >http://msdn2.microsoft.com/en-us/library/ms724923.aspx > >Hope it wil help you. Ok, done that and it sort-of-works (or not). The problem right now is that the uninstall custom action is not called because 'the condition is false'. At least that's what the log file says. So my current workaround is to call the uninstall ca unconditionally and the install ca during install (this one _is_ called), un-doing the effect of the first ca. This will, of course, horribly break if the user is modifying the installation. Do you (or anybody else for that matter) where (i.e. in what sequence) and when (i.e. what sequence number or after which standard item) the uninstall ca should be called such that !Feature and &Feature contain 'proper' values? Regards (and of course thanks for the help) Andre' -- View this message in context: http://www.nabble.com/conditional-components-tf2635711.html#a7360841 Sent from the wix-users mailing list archive at Nabble.com. - 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
Re: [WiX-users] conditional components
> Hi André, Hi Stefan. > I realy don't know what is wrong. > > Maybe you should try to use the to avoid > conflicts with XML. Well, you did know what was wrong after all. CDATA helps indeed, &Netlm is no valid XML... > But I know that you cannot write to the registry during > uninstallation using standard action WriteRegistryValues. Urm, that's bad. Do you know why? > If you need during uninstallation to write something to registry you > should write the CustomAction for it. I already tried to do so but failed to figure out how to write a registry key from a custom action. I found all kind of fancy stuff for executings a function in a dll or an script or such, but no registry access. Would I have to use an embedded script in the custom action? Regards, Andre' - 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] conditional components
Hi all.
I want to write a certain registry key during an installation
and the same key with a different value during uninstall.
So I thought I could have something like
(&Netlm = 3) AND NOT (!Netlm = 3)
(&Netlm = 2) AND (!Netlm = 3)
under the main ('Netlm' is a sub-feature)
but I get:
u:\src\fesetup\wix\setup.wxs(562) : error CNDL0104 : Not a valid source file;
detail: Beim Analysieren von 'EntityName' ist ein Fehler aufgetreten. Zeile
562, Position 22.
["When analizing 'EntityName' an error occured"].
It compiles when I replace the condition with, say, '1'.
What am I doing wrong here?
Andre'
-
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] 32 and 64-bit installer in one
Hi all, I just stumbled over the 's' in the Package's "Platform_s_" attribute and then over the documentation "The list of platforms supported in the package." Does that mean I can build a single .msi that can be installed on 32bit and 64bit machines (provided that I get the stuff inside the package right)? Andre' - 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] "simpler" selection tree?
Is there a possibility to change the icons in the 'feature selection tree' to simple checkboxes? I think I read the relevant parts in Wix Schema and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/selectiontree_control.asp, and my guess is 'no', but I thought I'd better ask just to make sure I have not overlooked something... Regards, Andre' - SF.net email is sponsored by: A Better Job is Waiting for You - Find it Now. Check out Slashdot's new job board. Browse through tons of technical jobs posted by companies looking to hire people just like you. http://jobs.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Network based installations?
Mike Dimmick wrote: > See 'Internet Download Bootstrapping' in MSDN Library, at > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/msi/setup/internet_download_bootstrapping.asp. Looks very promising. Thanks for the pointer. Andre' - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] File associations/short cuts
This wix v3. I have a wix based merge module installing some exe + auxillary stuff. In the main .wxs I can use this merge module and everything works fine so far. Now I'd like to add shortcuts in the startmenu and associate a few extensions with this .exe - which seems to works at least for the shortcuts when I put everything unconditionally in the merge module like so: As putting arbitrary stuff unconditionally on the user's 'private area' is not too nice I thought it might be a good idea to have this as separate user-selectible 'features' in the installer. Now the first problem is that I can't reference a file in a merge module. From reading this list I suppose the canonical solution for this is not to use a merge module, but a Wix Fragment. Is this understanding correct? Now, I tried just putting the exe itself not in the merge module, but in the main .wxs, so the merge module related problem is 'gone'. This leave me with a component containing an exe and two shortcuts from which I only want to install the latter. Should I create two components, one with the shortcuts and one without, and install exactly one of them depending on the feature selection? Or is there a method to associate the shortcuts with the file _outside_ the file's 'home component'? Third(ish) problem: The file assosications. I 'found' in the Wix tutorial: This seems to be Wix v2 only and does not work for me with Wix v3. The error I get is: u:\src\fesetup\wix\setup.wxs(350) : error CNDL0045 : The Verb element's TargetFile or TargetProperty attribute was not found; one of these as required when attribute Advertise has a value of 'no'. So I suspect I need to change Target in TargetFile. And put the thing into the ... of the 'target' exe? That does not really help... Andre' - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Network based installations?
[Could probably be dismissed as "Can't read the FAQ"...] How would I approach a 'network based installation'? Scenario is as follows: I'd like to produce a 'slim' .msi and several .cabs (or whatever, maybe one per feature) somewhere on the net. Then a user downloads only the .msi, selects some features and then some machinery downloads the needed .cabs afterwards. Is this (the downloading, I kind of know by now how to create the necessary installer files) already built-in somehow or do I have to create the machinery by myself? Regards, Andre' - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] 'NoPrefix' explanation?
Hi all. I wonder what the authorative source of information regarding the structure of Wix documents is. I am aware of http://wix.sourceforge.net/manual-wix2/wix_xsd_control.htm, but when looking up e.g. i'NoPrefix' I see 'YesNoType - only valid for Text Controls'. This is, of course, some information, yet it's hard to tell what the consequences of using it will be... Andre' -- View this message in context: http://www.nabble.com/%27NoPrefix%27-explanation--tf2596289.html#a7241840 Sent from the wix-users mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Embedding another msi based installer
Rob Hamflett wrote:
> There are a few things you could consider.
Hi Rob.
> You could ask the
> other company to produce a merge module for you.
I did that, and they said 'no'. I am not too happy to depend
on that third party software, unfortunately there's no way
to replace this soonish.
Moreover, I came to the (possibly wrong) conclusion that
'Merge module' and 'Merge module' might be different beasts.
I had troubles to use merge modules produced by ("plain")
Visula Studio Merge Module porjects in a Wix based installer,
possibly due to the way the merge is actually done (Wix
seems to resolve the merging at link time whereas the
VS deployment stuff resolves them at install time, at least
that's my guess right now). So if this assumption is true,
even a merge module might not be enough since it might be of
the wrong breed.
> There is also a custom action type for launching another MSI file,
> but you'll have to run it during the UI Sequence.
That'd be interesting.
Let me try to figure out how this works.
>From the Wix Schema page I end up somewhere near
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/summary_list_of_all_custom_action_types.asp
which does not seem to contain something directly related to
starting another install. I can, of course, start 'msiexec',
but that yields the 'two installers at the same time' problem.
So maybe there are more 'native' custom action types then those
listed on that page?
> The problem here is that there's no possibility of rollback, and
> you can't get at the embedded MSI file if it's wanted for
> anything else like repairs.
Repair would not be that much of an issue as this would be new
functionality for our users anyway - so it'd be ok if it were
absent or 'semi-broken'.
What do you mean by 'no possibility of rollback' exactly?
That if the installer has to exit after the installation
of the embedded product there'd be no way to clean this
up, i.e. the embedded product would remain installed?
That'd be a problem I suppose...
> The recommended method is to use a bootstrapper which installs
> all the pre-requisites and then installs your own product.
Ok, we sort of have this kind of setup right now already in a
non-msi world. I had thought in beginning we could get rid
of it once everything uses msi... well...
Thanks for your input.
Andre'
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Line edit control
> Hi André Hi Stefan. > the Type="Edit" is probably what you want to use. Indeed. > You should read the wix tutorial > http://www.tramontana.co.hu/wix Believe it or not, I had looked at it yesterday evening but was probably too focused on the 'line' part... > The possible controls which are available in MSI are listed here: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/controls.asp Thanks for that hint as well. It's in my bookmarks now. Regards, Andre' -- View this message in context: http://www.nabble.com/Line-edit-control-tf2593733.html#a7234347 Sent from the wix-users mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Embedding another msi based installer
I have a third party product with an msi based installer that I need to install alongside my own stuff. Simply launching msiexec from a custom action does not seem to work as msiexec will complain that another installer (presumably my own) is already running. Decompiling the third party installer with dark fails (dark from v3 simply gives up after a while, dark from v2 produces something that fails to compile again even with Wix v2 (and I am trying to use v3 anyway). The installation of the third party product should be as transparent as possible to the user... Andre' -- View this message in context: http://www.nabble.com/Embedding-another-msi-based-installer-tf2593753.html#a7234117 Sent from the wix-users mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Line edit control
I've just started to use Wix v3 (or any .msi based installer toolkit for that matter) so please bear with me. First question: How would I add a "line edit" control to a dialog? I have found examples for PushButtons, RadioButtons, static text etc but nothing that looks like something that might be usable to get a string from the user. I am aware of the Wix schema not mentioning 'lineedit'. When I just try to use a control type 'lineedit' nevertheless, the installer is build, but running it yields an error 2885 (Failed to create control...) Andre' -- View this message in context: http://www.nabble.com/Line-edit-control-tf2593733.html#a7234058 Sent from the wix-users mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
