Re: [WiX-users] Root folder other than Program Files
There isn't really such a location. Most people just put their binaries in Program Files folder and go from there. Nothing wrong with that (with modern version of the Windows Installer). Putting stuff in C:\var would be very strange on a Windows machine. I can tell you from personal experience, many users hate new stuff showing up in the root of their drives. Can you be more specific about what barfs means (a specific error message?) and what your authoring for this looks like exactly? Directory Id=WindowsVolume/ alone is not valid authoring for a Directory element so I'm wondering if that is just some short hand. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gus Grubba Sent: Thursday, February 15, 2007 7:07 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Root folder other than Program Files I guess the first question is: What is the Windows equivalent of / var? Where should a service/daemon running with the credentials of a system account store its runtime data? For now I'm creating and storing it in C:\var. Now comes the question in the subject line. How do you create this in WiX/MSI? The main application binaries and whatnot get installed in C:\Program Files \Company Name\Product Name just like everybody else. I have not for the life of me been able to figure out a way to have some files stored some place off the root. According to the MSI documentation, WindowsVolume should resolve to C:\ (or wherever Windows is installed). If I define a Directory Id='WindowsVolume', light barfs telling me that is an MSI Public Property. Nothing I try seems to work. TIA! g - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding a hyperlink (link label) to a message...
Alex Henderson wrote: However I was wondering if it's possible to add a clickable hyperlink to the message (so the user can navigate to the Microsoft website to download the Framework, read more about or whatever), or some other work around for achieving a similar idea .. clicking on a button to navigate to a URL perhaps? You can use a PushButton with a control event calling the new(ish) WixShellExec custom action with a WixShellExecTarget of an URL. See the ShellExecute CustomAction topic in the v3 WiX.chm. -- sig://boB http://bobs.org - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Light Exception with Merge Modules
Thanks Rob for your response.
Your comments about path problems with cygwin, gave me a hint, so I got this
to work on a command prompt, the paths to candle and light had both forward
and back slash in my wix driver app, using back slash consistently fixed the
problem. We do our builds using cygwin and I still have the problem with
getting this to work in cygwin, but I should be able to figure that out, we
have utils to handle the windows and linux path separators.
Another quick question I had was whats the replacement for UIRef Id=WixUI
/ ?
With 3309, I had this tag within the Product tag and linked with
wixui_mondo.wixlib, with 4820, I am linking with wixui.wixlib and get the
following error with using the UIRef tag.
error LGHT0112 : Unresolved reference to
symbol 'UI:WixUI' in section 'Product:225454C0-F159-491C-8CE7-BC035678C315'.
Thanks,
-Sandip
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Thursday, February 15, 2007 11:53 PM
To: Sandip Ghosh; Wix Users (Wix Users)
Subject: Re: [WiX-users] Light Exception with Merge Modules
I think I remember problems with cygwin bash shell (or something like that)
messing with the load of mergemod.dll. Also, do make sure you have
mergemod.dll next to the rest of the tools. that *should* be that way but
good to check. smile/
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sandip Ghosh
Sent: Thursday, February 15, 2007 11:28 PM
To: Wix Users (Wix Users)
Subject: [WiX-users] Light Exception with Merge Modules
I create MSIs through the use of merge modules. I have been using Wix
version 2.0.3309 for a while now and have not had any problems generating
the MSIs, I have tried a few times to upgrade to later versions of Wix. I
have tried 3719 and now 4820. With both the latter versions, The MSM
generation looks fine, but I get the following error during the final light
phase when it attempts to create the MSI from the MSM.
light.exe : error LGHT0001 : Retrieving the COM class factory for component
with
CLSID {F94985D5-29F9-4743-9805-99BC3F35B678} failed due to the following
error:
8007007e.
Exception Type: System.IO.FileNotFoundException
Stack Trace:
at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String
databasePat
h, Output output)
at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output)
at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args)
I think I have seen some prior posts about installing Orca and registering
mergemod.dll to fix this problem. I have done both and I can find the CLSID
above in the registry as a registered COM object. Still get this failure.
What else is needed to get this to work ?
Thanks for your responses,
-Sandip
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=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: Property Id=UNINSTALLCMD Value=MSIEXEC.EXE /x [!PRODUCTID] / And also... Component Id=Uninstaller Guid=F72CE94D-8E6E-4b9e-95BC-7DC80C3641B6 Shortcut Target=[UNINSTALLCMD] Id=UninstallIcon Name=Uninstall Description=Uninstall My Application Directory=ProgramMenuDir / /Component 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 Component Id='Uninstaller' RegistryValue Id='Uninstaller' Root='HKCU' Key='Software\.\Uninstaller' Name='Dummy' Action='write' Type='integer' Value='0' KeyPath='yes' / ... /Component 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is possible to install IIS as part of MSI setup ?
It is possible. There is stuff on MSDN (or is it TechNet?) that shows how to install IIS scripted. You could technically speaking call that at some point during the MSI install (UI sequence may be best). Not sure if that is a good idea or not... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Petr Vones Sent: Wednesday, February 14, 2007 3:39 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is possible to install IIS as part of MSI setup ? Hi, I know it is strange requirement (customers ... you know :-) but I'd like to be sure that it is not possible to install IIS (Windows Server 2003 or 2000) as a part of MSI setup. I know that installing IIS means rather changing the system configuration but it might be scriptable somehow. Thanks, Petr - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Root folder other than Program Files
Rob, First, thanks for taking the time. Second, sorry for being terse! Here we go: The actual error put out by light is: error LGHT0204 : ICE99: The directory name: WindowsVolume is the same as one of the MSI Public Properties and can cause unforeseen side effects. make: *** [product.msi] Error 204 The directory block looks like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=COMPANYDIR Name=Company Name Directory Id=INSTALLDIR Name=Product Name / /Directory /Directory Directory Id=ProgramMenuFolder Name=Programs Directory Id=ProgramMenuDir Name=Product Name / /Directory Directory Id=DesktopFolder Name=Desktop / Directory Id=WindowsVolume Name=RootDisk Directory Id=VARDIR Name=var Directory Id=LOGDIR Name=log / Directory Id=PRDDBDIR Name=ProductName Directory Id=DBDIR Name=db / /Directory /Directory /Directory /Directory What goes into var are the logs and database files. It just seems to be too strange to put this into the application's directory. These files, specially the databases can grow rather large. Under UNIX, the database is usually a storage of its own (RAID). This product is rather large and it is unusual (but not impossible) to have it installed on some computer that is used for other tasks. The Installer has many custom dialogs and these directories above should all be configurable. I'm just trying to come up with reasonable defaults. Thanks! g On Feb 16, 2007, at 3:23 AM, Rob Mensching wrote: There isn't really such a location. Most people just put their binaries in Program Files folder and go from there. Nothing wrong with that (with modern version of the Windows Installer). Putting stuff in C:\var would be very strange on a Windows machine. I can tell you from personal experience, many users hate new stuff showing up in the root of their drives. Can you be more specific about what barfs means (a specific error message?) and what your authoring for this looks like exactly? Directory Id=WindowsVolume/ alone is not valid authoring for a Directory element so I'm wondering if that is just some short hand. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Gus Grubba Sent: Thursday, February 15, 2007 7:07 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Root folder other than Program Files I guess the first question is: What is the Windows equivalent of / var? Where should a service/daemon running with the credentials of a system account store its runtime data? For now I'm creating and storing it in C:\var. Now comes the question in the subject line. How do you create this in WiX/MSI? The main application binaries and whatnot get installed in C:\Program Files \Company Name\Product Name just like everybody else. I have not for the life of me been able to figure out a way to have some files stored some place off the root. According to the MSI documentation, WindowsVolume should resolve to C:\ (or wherever Windows is installed). If I define a Directory Id='WindowsVolume', light barfs telling me that is an MSI Public Property. Nothing I try seems to work. TIA! g -- --- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Manually setting inclusion destination?
I use the tool heat to capture all the (*many*) files in my directory foo/ into a foo.wxs. This is done automatically as part as a larger build process and it can therefore be considered *not* possible to edit foo.wxs manually at any time. In my main Installer.wxs file I have defined a directory tree, say /Parth/ To/ My/ Subdir/ Now, I wan't foo/ to be included in this tree. Eg. at /Path/To/My/Subdir/foo/ How can I do that (without being able to modify foo.wxs)? Aren't there some kind of inclusion destination parameter somewhere? - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding a hyperlink (link label) to a message...
I do that by creating my own dialog in an external DLL (Custom Action). While in the subject, how do you get the installer's window handle? g On Feb 16, 2007, at 2:53 AM, Rob Mensching wrote: Unfortunately, MSI UI does not support hyperlinks. A much requested feature. The only other option is to create an external UI handler... and that is a very much lot of work. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Alex Henderson Sent: Thursday, February 15, 2007 10:59 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding a hyperlink (link label) to a message... My application relies on the .Net Framework 2.0 being installed... we currently display a failure message when it's unavailable like this: Condition Message=The .NET Framework 2.0 must be installed Installed OR NETFRAMEWORK20 /Condition However I was wondering if it's possible to add a clickable hyperlink to the message (so the user can navigate to the Microsoft website to download the Framework, read more about or whatever), or some other work around for achieving a similar idea .. clicking on a button to navigate to a URL perhaps? What would be considered best practice for an installer in this case at any rate? Cheers, - Alex -- --- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Do not remove webserviceextention on UnInstall process
Hi. I've written a part of wix installation file like this: WebServiceExtension Id=TurOnWebExtention Allow=yes Description=ASP.NET v2.0 File=SYSTEMROOT\Microsoft.NET\Framework\DOTNETFRAMEWORKVER\aspnet_isapi .dll UIDeletable=no / But this wervice extention is removing then I try to Uninstall my installation. I don't need to remove this one. What should I do to save my extention file ? P.S. I'm using Wix v3.0 - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error 26251 -- Failed to register DLL with PerfMon
That's an error from a custom action. You'll need to contact the owner of the CA. Moving SetupSup to BCC. Heath Stewart Software Design Engineer Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Amol Tambat (Wipro Technologies) Sent: Friday, February 16, 2007 1:58 AM To: Rob Mensching; wix-users@lists.sourceforge.net Cc: Windows Installer Support (MS Internal) Subject: RE: Error 26251 -- Failed to register DLL with PerfMon Adding Windows Installer Support (MS Internal) and wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net for the below mentioned problem. From: Rob Mensching Sent: Friday, February 16, 2007 3:22 PM To: Amol Tambat (Wipro Technologies); Windows Installer Team Subject: RE: Error 26251 -- Failed to register DLL with PerfMon Please see http://sharepoint/sites/wix for the correct place to ask questions. From: Amol Tambat (Wipro Technologies) Sent: Friday, February 16, 2007 1:51 AM To: Windows Installer Team Subject: Error 26251 -- Failed to register DLL with PerfMon Hi, I got an error at the time of un-installation only once. Can any one from the team, help me out to find the exact issue which caused the problem. Product: Microsoft BizTalk RFID -- Error 26251. Failed to register DLL with PerfMon. (-2147024894 C:\Program Files\Microsoft BizTalk RFID\process.ini ) Thanks Regards, Amol Tambat - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Checking for Passive mode
I have a situation where the user might want to run an MSI I've created in passive mode, but my Custom Action needs to change if that is the case. Is there a way of having the MSI check whether it is being run in passive mode or not? Otherwise I'm going to have to get the user to include a property in the command that will be read by the MSI and allow the modification in my Custom Action. Which will work, but is slightly annoying. Thanks. - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Do not remove webserviceextention on UnInstall process
Make the Component that installs it permanent. Then it won't get uninstalled. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stepan Tinskiy Sent: Friday, February 16, 2007 6:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Do not remove webserviceextention on UnInstall process Hi. I've written a part of wix installation file like this: WebServiceExtension Id=TurOnWebExtention Allow=yes Description=ASP.NET v2.0 File=SYSTEMROOT\Microsoft.NET\Framework\DOTNETFRAMEWORKVER\aspnet_isapi.dll UIDeletable=no / But this wervice extention is removing then I try to Uninstall my installation. I don't need to remove this one. What should I do to save my extention file ? P.S. I'm using Wix v3.0 - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Manually setting inclusion destination?
There are many discussions on this mailing list that heat is not intended to be used in a build process to automatically generate .wxs files. The Component Rules will be violated. There are some long threads on this... you might go read through those for more context. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Very Secret Sent: Friday, February 16, 2007 6:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Manually setting inclusion destination? I use the tool heat to capture all the (*many*) files in my directory foo/ into a foo.wxs. This is done automatically as part as a larger build process and it can therefore be considered *not* possible to edit foo.wxs manually at any time. In my main Installer.wxs file I have defined a directory tree, say /Parth/ To/ My/ Subdir/ Now, I wan't foo/ to be included in this tree. Eg. at /Path/To/My/Subdir/foo/ How can I do that (without being able to modify foo.wxs)? Aren't there some kind of inclusion destination parameter somewhere? - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding a hyperlink (link label) to a message...
No. External UI handler cannot be a CustomAction. There is no supported method to get the installer window's handle. Some people have used ::FindWindow() with some success... although you could find the wrong window. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gus Grubba Sent: Friday, February 16, 2007 6:13 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding a hyperlink (link label) to a message... I do that by creating my own dialog in an external DLL (Custom Action). While in the subject, how do you get the installer's window handle? g On Feb 16, 2007, at 2:53 AM, Rob Mensching wrote: Unfortunately, MSI UI does not support hyperlinks. A much requested feature. The only other option is to create an external UI handler... and that is a very much lot of work. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Alex Henderson Sent: Thursday, February 15, 2007 10:59 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding a hyperlink (link label) to a message... My application relies on the .Net Framework 2.0 being installed... we currently display a failure message when it's unavailable like this: Condition Message=The .NET Framework 2.0 must be installed Installed OR NETFRAMEWORK20 /Condition However I was wondering if it's possible to add a clickable hyperlink to the message (so the user can navigate to the Microsoft website to download the Framework, read more about or whatever), or some other work around for achieving a similar idea .. clicking on a button to navigate to a URL perhaps? What would be considered best practice for an installer in this case at any rate? Cheers, - Alex -- --- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Root folder other than Program Files
Ahh, now I understand. If you read the MSI SDK documentation about WindowsVolume it says: Do not use the WindowsVolume property in the Directory colum of the Directory table. The WindowsFolder property contains the path to the Windows folder. I understand your use of var better now and maybe your customers expect it. Anyway, the documentation says don't use WindowsVolume. If you really want to have a directory point to WindowsVolume, you'll need to use a CustomAction to set the appropriate Directory. Seems kinda' strange that the Windows Installer requires you to go all the way around like this but... whatever. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gus Grubba Sent: Friday, February 16, 2007 6:01 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Root folder other than Program Files Rob, First, thanks for taking the time. Second, sorry for being terse! Here we go: The actual error put out by light is: error LGHT0204 : ICE99: The directory name: WindowsVolume is the same as one of the MSI Public Properties and can cause unforeseen side effects. make: *** [product.msi] Error 204 The directory block looks like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=COMPANYDIR Name=Company Name Directory Id=INSTALLDIR Name=Product Name / /Directory /Directory Directory Id=ProgramMenuFolder Name=Programs Directory Id=ProgramMenuDir Name=Product Name / /Directory Directory Id=DesktopFolder Name=Desktop / Directory Id=WindowsVolume Name=RootDisk Directory Id=VARDIR Name=var Directory Id=LOGDIR Name=log / Directory Id=PRDDBDIR Name=ProductName Directory Id=DBDIR Name=db / /Directory /Directory /Directory /Directory What goes into var are the logs and database files. It just seems to be too strange to put this into the application's directory. These files, specially the databases can grow rather large. Under UNIX, the database is usually a storage of its own (RAID). This product is rather large and it is unusual (but not impossible) to have it installed on some computer that is used for other tasks. The Installer has many custom dialogs and these directories above should all be configurable. I'm just trying to come up with reasonable defaults. Thanks! g On Feb 16, 2007, at 3:23 AM, Rob Mensching wrote: There isn't really such a location. Most people just put their binaries in Program Files folder and go from there. Nothing wrong with that (with modern version of the Windows Installer). Putting stuff in C:\var would be very strange on a Windows machine. I can tell you from personal experience, many users hate new stuff showing up in the root of their drives. Can you be more specific about what barfs means (a specific error message?) and what your authoring for this looks like exactly? Directory Id=WindowsVolume/ alone is not valid authoring for a Directory element so I'm wondering if that is just some short hand. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Gus Grubba Sent: Thursday, February 15, 2007 7:07 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Root folder other than Program Files I guess the first question is: What is the Windows equivalent of / var? Where should a service/daemon running with the credentials of a system account store its runtime data? For now I'm creating and storing it in C:\var. Now comes the question in the subject line. How do you create this in WiX/MSI? The main application binaries and whatnot get installed in C:\Program Files \Company Name\Product Name just like everybody else. I have not for the life of me been able to figure out a way to have some files stored some place off the root. According to the MSI documentation, WindowsVolume should resolve to C:\ (or wherever Windows is installed). If I define a Directory Id='WindowsVolume', light barfs telling me that is an MSI Public Property. Nothing I try seems to work. TIA! g -- --- 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.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and
[WiX-users] Supressing the command window on ExeCommand custom action
Hi, I've got a problem and I was hoping someone could help me out. I'm trying to run a command line program, and I've got it working with a custom action: CustomAction Id='Action' Execute='deferred' Return='check' Property='EXEPATH' ExeCommand='PARAMS' HideTarget='yes' Impersonate='yes' / The only problem is I don't want that command window popping up and disappearing all the time. Is there some way I can get this custom action to not pop up the command window? Thanks Will - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supressing the command window on ExeCommand custom action
I'm not sure there is a standard pattern. There are many different ways you can do something like that depending on how you want things to work and what you are trying to do. What does embedding ADAM in my installer mean? From: Jon LeCroy Sent: Friday, February 16, 2007 6:01 PM To: Rob Mensching; Will Qian; wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] Supressing the command window on ExeCommand custom action To hijack this a little as that should answer Will's question.. When using QtExec, what's the standard pattern for getting files on the box to execute? In my case I'm embedding ADAM in my installer and need to unpack it so that I can call it with QtExec.. Cheers, Jon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, February 16, 2007 5:06 PM To: Will Qian; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Supressing the command window on ExeCommand custom action That's what QtExec (http://wix.sourceforge.net/manual-wix2/qtexec.htm) is for in the WiX toolset. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Will Qian Sent: Friday, February 16, 2007 4:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Supressing the command window on ExeCommand custom action Hi, I've got a problem and I was hoping someone could help me out. I'm trying to run a command line program, and I've got it working with a custom action: CustomAction Id='Action' Execute='deferred' Return='check' Property='EXEPATH' ExeCommand='PARAMS' HideTarget='yes' Impersonate='yes' / The only problem is I don't want that command window popping up and disappearing all the time. Is there some way I can get this custom action to not pop up the command window? Thanks Will - 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.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
