[WiX-users] Variables
Hi! I have found things like this, in example: $(var.SampParentDir) But I haven't been successful in finding information about it. Can anyone point me in the direction where to read up about this or explain it please. How do I declare it, init it Regards - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Debug CRT merge module
Hi, I have WiX source code, which contains debug version of an executable. Also, in WiX I have included CRT merge module (debug version): Merge Id=VC8Runtime SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1/ The MSI package is created successfully and it is also installed correctly on the target system. The CRT dll:s are installed in: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c Trying to launch the executable gives me following error: 'The system cannot execute the specified program.' Can someone explain to me why the debug version of the executable cannot be executed in the target system? Thanks, Harry -- View this message in context: http://www.nabble.com/Debug-CRT-merge-module-tf3794591.html#a10732487 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Debug CRT merge module
Like this, from my previous example: ?define SampDir=C:\projects\business\artgallery\sample_src\? ?define SampDiskId=1? ?define SampParentDir=INSTALLLOCATION? Anthony Wieser Wieser Software Ltd - Original Message - From: Harry Liljeström [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 8:03 AM Subject: [WiX-users] Debug CRT merge module Hi, I have WiX source code, which contains debug version of an executable. Also, in WiX I have included CRT merge module (debug version): Merge Id=VC8Runtime SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1/ The MSI package is created successfully and it is also installed correctly on the target system. The CRT dll:s are installed in: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c Trying to launch the executable gives me following error: 'The system cannot execute the specified program.' Can someone explain to me why the debug version of the executable cannot be executed in the target system? Thanks, Harry -- View this message in context: http://www.nabble.com/Debug-CRT-merge-module-tf3794591.html#a10732487 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using heat.exe as part of an automated build process
Thanks for the heads up. I'll bear that in mind. Presumably, changing the root folder for the files each time would solve this problem then. so sample-v1 sample-v2, etc would fix it as the root of the installed pieces. Anthony Wieser Wieser Software Ltd - Original Message - From: Mike Dimmick [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 12:17 AM Subject: RE: [WiX-users] Using heat.exe as part of an automated build process Yes, you're breaking rule 1 of the component rules: a file installed to the same location must always belong to the same component and have the same GUID. Change the GUID, it's a new component; change the component, you must change the final path name of the file. If you don't, you mess up Windows Installer's reference counting and it may either remove files prematurely or not remove them when it should. At the very least you restrict where you can schedule the RemoveExistingProducts action when performing an upgrade (if you do it after InstallFiles in the new product, Windows Installer will happily remove all the old components - and the files it's just installed). -- Mike Dimmick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a WiX element that will perform a FindWindow?
Has anyone else noticed a pattern of emails getting marked as spam by Windows Mail on vista. Does gmail always look like spam to source forge? This message was one of the messages marked as spam, presumably due to these headers: X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=addgroup_id=1atid=21 0.0 RCVD_BY_IP Received by mail server with no name 0.0 HTML_MESSAGE BODY: HTML included in message 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Variables
Sorry, somehow managed to respond in the wrong thread: Variables can be set like this, from my previous example: ?define SampDir=C:\projects\business\artgallery\sample_src\? ?define SampDiskId=1? ?define SampParentDir=INSTALLLOCATION? Anthony Wieser Wieser Software Ltd - Original Message - From: Wik Carl-Johan To: wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 7:47 AM Subject: [WiX-users] Variables Hi! I have found things like this, in example: $(var.SampParentDir) But I haven't been successful in finding information about it. Can anyone point me in the direction where to read up about this or explain it please. How do I declare it, init it .. Regards -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using heat.exe as part of an automated build process
After receiving emails from people on this subject asking about our process, I will reply to all publicly here. Unfortunatly my employer 'owns' the code, getting OS in the door is hard enough, getting it out is not an option I am afraid. However for those interested the general methodology used is as follows. Each file has an XML file which describes it, how it gets installed and any required params which cannot be auto harvested. It also lists what products this file gets used by ( we have a lot of code sharing among products). This file is then read and generates wix source files for each product using transforms and xpath. This pass also tell the products what components they have. The component files are then built, tranforms are done to generate the features using the information from pass 1 and then the final generation of msms and then msis. This process currently manages our msi generation for 20+ installation products from 240ish components built from source and a few hundred ancillary files. It removes most of the tedium and mistakes made, but is still fully extensible by careful use of include files. It's not quite the nirvana of fully automated code generation but it does remove the tedium and potential mistakes from changing one component which is used in all products. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Fileshare bug ?
Is this a bug ? When i update my application then shar ecreated in th einitail install is removed. The log is as follows : Actie gestart 12:06:03: CreateSmbRollback. CreateSmbRollback: Actie beeindigd 12:06:03: CreateSmbRollback. Retourwaarde 1. MSI (s) (70!70) [12:06:03:937]: PROPERTY CHANGE: Adding CreateSmb property. Its value is 'KINGSERVERC:\Program Files\king\Data01Iedereen268435456'. MSI (s) (70!70) [12:06:03:937]: Doing action: CreateSmb Actie 12:06:03: CreateSmb. Actie gestart 12:06:03: CreateSmb. CreateSmb: Actie beeindigd 12:06:03: CreateSmb. Retourwaarde 1. Actie beeindigd 12:06:03: ConfigureSmb. Retourwaarde 1. MSI (s) (70:50) [12:06:03:968]: Doing action: CreateShortcuts Actie 12:06:03: CreateShortcuts. Bezig met het maken van snelkoppelingen The wix source is as follows : Component Id=Serverwork2 Guid=$(var.GUIDdbshare) !-- Share de data directory -- Registry Id=Reg_sharenamehkcunl Root=HKCU Key=SOFTWARE\Quadrant\$(var.DEF_PAKKETDISPLAY)\$(var.DEF_SIMPLEBUILD) Name=Sharenamenl Type=string Value=[DBSHARENAME] Action=write KeyPath=yes/ User Id=everyone Name=[GROUPEVERYONE]/ FileShare Id=ClientShare Name=[DBSHARENAME] Permission User=everyone GenericAll=yes / /FileShare /Component [GROUPEVERYONE] is the name of group 'Everyone', which will be 'Iedereen' on dutch systems, depending on the language of the OS. I get the impression that there is no error in creating the file share. I have a hunch that every thing worked fine until i changed RemoveExistingProducts After='InstallFinalize' / to RemoveExistingProducts After='InstallInitialize' / I changed this to solve a bug. Some files were not installed onupdate When i update the GUID stays the same for this component. Is this a good or bad idea ? regards, Hugo van Putten -- View this message in context: http://www.nabble.com/Fileshare-bug---tf3795033.html#a10733876 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a WiX element that will perform a FindWindow ?
Thanks for the quick reply Bob. Now hurry up and put that new element into WiX! :-) On 5/21/07, Bob Arnson [EMAIL PROTECTED] wrote: Daniel Gurney wrote: I'd like to find out if an application is running. I don't want to close the application. This is more of a boolean action that I am looking for. Not at the moment. There's the beginnings of one in the CloseApplications CA; it'd be easy enough to expose the find functionality. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] More Questions on Component Rules
OK, I have to admit, I still can't fathom all of the implicit rules going on here. On Rob's blog, he shows a way of installing shortcuts, and shows us an example that hangs them here: RegistryKey Root=HKCU Key=Software\My Application\Uninstall But, what I'd like to do, is create my values in this way instead: RegistryKey Root=HKCU Key=Software\My Company\My Application\Uninstall I have a similar desire to create application folders on the system like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=CommonAppDataFolder Directory Id=companyCAD Name=Company Name Here !-- Does a component need to go here? -- Directory Id=productCAD Name=Product Name here Component Id=PersistentDataFolder Guid=GUID-HERE CreateFolder Permission GenericAll=yes User=Administrators / Permission ReadPermission=yes Synchronize =yes Read=yes ReadAttributes=yes ReadExtendedAttributes=yes CreateFile=yes WriteAttributes=yes WriteExtendedAttributes=yes CreateChild=yes GenericWrite=yes User=Users/ /CreateFolder /Component /Directory !-- End component here? -- /Directory /Directory more stuff /Directory Should I be creating components for the inner empty folders, and registry keys? I can't seem to find an explicit answer in the MSI or WiX documentation. Maybe that's because there's no right answer, so if I did do it, I presume the component GUID would need to be constant across all of my installs, because of the component rules discussed earlier today. I also presume that this would allow the node to be removed when there are no longer any users of the component. What happens if I leave it the way it is? I would have guessed that the key's above Uninstalled in Rob's example would be orphaned, but it seems that they're removed. Is it just that empty keys are removed, if not marked permanent on an uninstall? Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting Folder ACL Permissions
Hi John, I've dnone something similar, but while the MSI technology incorporates the LockPermissions table in order to achieve such things it actually removes any existing permissions and as such far more intrusive than you'd really want. I use SubinACL.exe from M$... the WiX looks something like this for a reg key. Binary Id=wixca src=Installs\Common\Tools\WiX\wixca.dll / CustomAction Id=SetCommandLineCommon Property=QtExecDeferred1 Value='[#subinaclexe] /noverbose /keyreg HKEY_LOCAL_MACHINE\SOFTWARE\...\blah\blah\ /GRANT=S-1-1-0=F' / CustomAction Id=QtExecDeferred1 BinaryKey=wixca DllEntry=CAQuietExec Execute=deferred Return=check / DirectoryRef Id=Program Component Id=RegPermissions Guid=YOURGUID---- DiskId=1 File Id=subinaclexe Name=subinacl.exe Compressed=yes src=installs/common/tools/SubinACL/subinacl.exe / /Component /DirectoryRef Where S-1-1-0 is the SID for the Users user group. I'm sure this is easily adaptable for a folder simply by reading the help that comes with SubinACL. And the CAQuietExec needs to be called differently if you don't wish to perform the CA as deferred... this is documented in the WiX help. If you're going for Vista verification, you'll need to make a manifest file for subinacl, or call it from your sourcedir, but then make sure you don't try and call it on modify/repair, etc. Good luck, Gareth -- View this message in context: http://www.nabble.com/Setting-Folder-ACL-Permissions-tf3768482.html#a10737099 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] public properties can be read inside the merge module?
...? From: Amit Srivastava (Tata Consultancy Services) Sent: Monday, May 21, 2007 6:19 PM To: wix-users@lists.sourceforge.net Cc: Rob Mensching Subject: RE: public properties can be read inside the merge module? Any Suggestion…? From: Amit Srivastava (Tata Consultancy Services) Sent: Monday, May 21, 2007 12:03 PM To: 'wix-users@lists.sourceforge.net' Cc: Rob Mensching Subject: FW: public properties can be read inside the merge module? Any help on this…? From: Amit Srivastava (Tata Consultancy Services) Sent: Monday, May 21, 2007 12:28 AM To: Rob Mensching Subject: RE: public properties can be read inside the merge module? Thanks for your quick response.. If we describe the properties inside the merge module then we can read it outside from the merge module(i.e. from wix project file that contain that merge module using module id) but if we define the properties inside the wix project(outside of merge module) and trying to read it inside the merge module can we do it? As we know merge module can be included in the project file now suppose that project file contains some properties and try to read that properties inside from the merge module( merge module also included as part of project), can we do that? Thanks in Advance Amit From: Rob Mensching Sent: Sunday, May 20, 2007 11:07 PM To: Amit Srivastava (Tata Consultancy Services); wix-users@lists.sourceforge.net Subject: RE: public properties can be read inside the merge module? Sure. Just remember the Properites have the Module Id appended to them as described in the MSI SDK. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amit Srivastava (Tata Consultancy Services) Sent: Sunday, May 20, 2007 4:30 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] public properties can be read inside the merge module? Hi, I have created a merge module using wix and I am trying to read the public properties which is defined outside of merge module(i.e. inside the MSI file). Can we read that properties? That merge module is included in the main wix file file for creation the MSI. I am trying to read the properties from the merge module but I am not getting success? If we can then how we can read that properties..? Thanks Amit srivastava - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using heat.exe as part of an automated build
Hi, I have a similar situation (where the list of files changes from release to release), and I use a perl script to generate wix include files for the components and features. Let me explain. We keep list files, split into what become components, containing simply the relative pathname of all files within that component (relative to the root install directory). There's another file that lists the features and the components they include. These are both simply text files. The perl script reads all of these files and keeps track of the features, components, files, and directories using %arrays, then spits out a features.wxi and components.wxi file that is included in a base .wxs file to fill out the feature and component sections. The perl script also keeps a list of known components and the GUIDs associated with them, so that the component GUIDs only change when we want. If you'd like a sanitized version of the perl script (with example files), let me know off-list and I'll send it to you. Lewis -Original Message- Date: Mon, 21 May 2007 15:21:29 -0400 From: Yexley, Robert \(LNG-CON\) [EMAIL PROTECTED] Subject: Re: [WiX-users] Using heat.exe as part of an automated build process To: Rob Mensching [EMAIL PROTECTED], Scott Palmer [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] t Content-Type: text/plain; charset=us-ascii Thanks Rob. But the code divination that you speak of is not really what I'm looking for. I'm not looking for some voodoo that will get me out of doing my job, I'm just looking for a way to do it more efficiently and effectively. The *actual* situation that I have is that the files that make up the web application that I'm trying to create an installer for change, at least slightly, from week-to-week. ASPX pages get added, js files get removed, etc. The file system is a moving target. I've discussed the maintenance of .wxs files with the development team and the general consensus seems to be that having to update/change a .wxs file to add or remove a component whenever a file is added or removed from the codebase is not really feasible. The hope, then, was that there might be some way, some tool that I could use, to automatically generate a .wxs source file with all of the components needed by simply pointing it at a given directory. I can setup my automated build process to take the raw code directory and copy only the files needed to a staging directory (remove all files with the following extensions: .cs, .csproj, etc)...that directory then becomes a mirror image of what I want the target machine to look like after having run the installer. I have no problem with creating a main .wxs source file with all of the custom UI logic and stuff like that in it, but having to manually maintain files for each and every single file that makes up an application is tedious at best (more colorful ways of describing that process come to mind as well). The other major consideration here is the fact that I don't really have a requirement to deploy to a large user base, nor is there a requirement for component upgrades either. We're developing an installer to simplify the process of internal deployment. Within the company that I work, there is a completely separate organization that maintains our server environments, and the deployment of applications to those servers. The idea of simplifying that process for them by creating a simple installer is very appealing to everyone. So, for our purposes, an upgrade would really just be a matter of checking to see if the application is already installed and if it is, uninstall it before continuing with the current installation. There are a few custom actions that I would want to perform as part of the process, but again, I can write that into the installer source and handle that myself. I simply want something that is capable of looking at a directory and generating a source file with a component for each of the files and directory structures in the given directory. I hope that clears some things up. I also hope that makes what I'm wanting/hoping/trying to do fairly easy. I just need some guidance as to how to do that, whether it involves the use of heat.exe or something else. If nothing else exists, fine...I'll write my own tool to do it. I just wanted to at least ask the question because my scenario seemed to me to be a common enough one that someone was bound to have faced this challenge before me, and hoped that someone had already figured out a solution for it. Thanks. __ // YEX // - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Re: [WiX-users] Is there a WiX element that will perform a FindWindow ?
Daniel Gurney wrote: Thanks for the quick reply Bob. Now hurry up and put that new element into WiX! :-) I'd be happy to review your code contribution...g -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are ICE45 warnings expected with ElevationShield=yes?
Anthony Wieser wrote: Unfortunately, ICE45 gives an error once you've added ElevationShield=yes to the Pushbutton control. Is this because ICE45 is out of date? Yes. You can update darice.cub from the Vista SDK to get the latest ICEs. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with SQL custom actions.
Maybe I am grasping at straws trying to get this v3 to work, but the latest weekly release (3.0.2921.0) doesn't even get in to the custom action DLL. Now I am getting this: MSI (s) (FC:3C) [09:35:15:234]: Doing action: ConfigureSql Action 9:35:15: ConfigureSql. Configuring SQL Server Action start 9:35:15: ConfigureSql. MSI (s) (FC:E4) [09:35:15:250]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10D.tmp, Entrypoint: ConfigureSql MSI (s) (FC:3C) [09:35:15:312]: Note: 1: 1723 2: ConfigureSql 3: ConfigureSql 4: C:\WINDOWS\Installer\MSI10D.tmp Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp MSI (s) (FC:3C) [09:35:16:531]: Product: Enterprise Reporting Server -- Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp Action ended 9:35:16: ConfigureSql. Return value 3. Any thoughts / suggestions? The DLL is actually in the binary table, so it's not a matter of the DLL missing. Regards, //aj On 5/21/07, Bob Arnson [EMAIL PROTECTED] wrote: Aaron Shurts wrote: I decided to go with v3 because I didn't feel like re-writing all the deprecated tags when v3 is released. I think we have a fix for it in the meantime, but it sure would be nice if the fixes were propagated in to the v3 code branch. Check the latest weekly release: RobMen: Reverse integrate WiX v2 CustomAction fixes. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer not placing any files
Yes, you can't define files to install in a Binary element. A binary can be used by the installer but is not installed on the system. You must be File elements as part of a Component. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ccitt Sent: Tuesday, May 22, 2007 1:24 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installer not placing any files I defined them below with the Binary tags... Am I missing something? Thanks ccitt You need to define File elements under each of those Components. -Brian Simoneau -- View this message in context: http://www.nabble.com/Installer-not-placing-any-files-tf3797683.html#a10 742790 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with SQL custom actions.
That was a huge integration last week. It is possible that you've found a bug in the integration (or even scarier a bug that wasn't fixed in WiX v2 either). Is it possible to share the .wxs and SQL script? The last bugs we've fixed have all been edge cases where the SQL Script had to be set just so. Difficult to review. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Shurts Sent: Tuesday, May 22, 2007 9:55 AM To: Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problem with SQL custom actions. Maybe I am grasping at straws trying to get this v3 to work, but the latest weekly release (3.0.2921.0) doesn't even get in to the custom action DLL. Now I am getting this: MSI (s) (FC:3C) [09:35:15:234]: Doing action: ConfigureSql Action 9:35:15: ConfigureSql. Configuring SQL Server Action start 9:35:15: ConfigureSql. MSI (s) (FC:E4) [09:35:15:250]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10D.tmp, Entrypoint: ConfigureSql MSI (s) (FC:3C) [09:35:15:312]: Note: 1: 1723 2: ConfigureSql 3: ConfigureSql 4: C:\WINDOWS\Installer\MSI10D.tmp Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp MSI (s) (FC:3C) [09:35:16:531]: Product: Enterprise Reporting Server -- Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp Action ended 9:35:16: ConfigureSql. Return value 3. Any thoughts / suggestions? The DLL is actually in the binary table, so it's not a matter of the DLL missing. Regards, //aj On 5/21/07, Bob Arnson [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Aaron Shurts wrote: I decided to go with v3 because I didn't feel like re-writing all the deprecated tags when v3 is released. I think we have a fix for it in the meantime, but it sure would be nice if the fixes were propagated in to the v3 code branch. Check the latest weekly release: RobMen: Reverse integrate WiX v2 CustomAction fixes. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Making a directory hidden
Hello all Is there a built-in way in WiX to make a target direcory hidden, or am i just going to have to call an external program to do it? Thanks ccitt -- View this message in context: http://www.nabble.com/Making-a-directory-hidden-tf3798371.html#a10744833 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Making a directory hidden
We are using a custom action to make a directory hidden. I think there is only built-in support to make files hidden. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ccitt Sent: Tuesday, May 22, 2007 2:23 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Making a directory hidden Hello all Is there a built-in way in WiX to make a target direcory hidden, or am i just going to have to call an external program to do it? Thanks ccitt -- View this message in context: http://www.nabble.com/Making-a-directory-hidden-tf3798371.html#a10744833 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with SQL custom actions.
This is a snippet of the include script that is called from the main product file: Binary Id=Sql_ServerInstall SourceFile=Components\Data\ERS\Database\ERSServer.sql / !--Execute SQL Scripts-- sql:SqlDatabase Id=LocalDbServer Server=[SQLSERVER] Database=master / !--Server-- DirectoryRef Id=INSTALLDIR Component Id=SqlErsServerInstall Guid=da6e0c89-2cfd-4bf4-92ae-40c8568bfd83 KeyPath=yes sql:SqlScript Id=InstallBaseScript SqlDb=LocalDbServer BinaryKey=Sql_ServerInstall ContinueOnError=no ExecuteOnInstall=yes Sequence=1 / Condition![CDATA[NOT ERS_VERSION AND NOT PLUS_VERSION]]/Condition /Component /DirectoryRef The attached SQL script is an obfuscated snippet of the SQL script we call which is a functioning script and I still get the failure described. If I can provide any other information let me know, but due to the nature of the product, I can't send you the full on scripts and files without an NDA. Regards, //aj On 5/22/07, Rob Mensching [EMAIL PROTECTED] wrote: That was a huge integration last week. It is possible that you've found a bug in the integration (or even scarier a bug that wasn't fixed in WiX v2 either). Is it possible to share the .wxs and SQL script? The last bugs we've fixed have all been edge cases where the SQL Script had to be set just so. Difficult to review. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Aaron Shurts *Sent:* Tuesday, May 22, 2007 9:55 AM *To:* Bob Arnson *Cc:* Mike Dimmick; wix-users@lists.sourceforge.net *Subject:* Re: [WiX-users] Problem with SQL custom actions. Maybe I am grasping at straws trying to get this v3 to work, but the latest weekly release (3.0.2921.0) doesn't even get in to the custom action DLL. Now I am getting this: MSI (s) (FC:3C) [09:35:15:234]: Doing action: ConfigureSql Action 9:35:15: ConfigureSql. Configuring SQL Server Action start 9:35:15: ConfigureSql. MSI (s) (FC:E4) [09:35:15:250]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10D.tmp, Entrypoint: ConfigureSql MSI (s) (FC:3C) [09:35:15:312]: Note: 1: 1723 2: ConfigureSql 3: ConfigureSql 4: C:\WINDOWS\Installer\MSI10D.tmp Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp MSI (s) (FC:3C) [09:35:16:531]: Product: Enterprise Reporting Server -- Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp Action ended 9:35:16: ConfigureSql. Return value 3. Any thoughts / suggestions? The DLL is actually in the binary table, so it's not a matter of the DLL missing. Regards, //aj On 5/21/07, *Bob Arnson* [EMAIL PROTECTED] wrote: Aaron Shurts wrote: I decided to go with v3 because I didn't feel like re-writing all the deprecated tags when v3 is released. I think we have a fix for it in the meantime, but it sure would be nice if the fixes were propagated in to the v3 code branch. Check the latest weekly release: RobMen: Reverse integrate WiX v2 CustomAction fixes. -- sig://boB http://joyofsetup.com/ ERSServer.sql Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Making a directory hidden
Fair enough I'll just use attrib instead then - thanks ccitt Brian Simoneau wrote: We are using a custom action to make a directory hidden. I think there is only built-in support to make files hidden. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ccitt Sent: Tuesday, May 22, 2007 2:23 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Making a directory hidden Hello all Is there a built-in way in WiX to make a target direcory hidden, or am i just going to have to call an external program to do it? Thanks ccitt -- View this message in context: http://www.nabble.com/Making-a-directory-hidden-tf3798371.html#a10744833 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Making-a-directory-hidden-tf3798371.html#a10751850 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing both X64 and X86 problems.
I've used Wix include files fairly successfully to do what you describe below. I have a main install file (wxs) for i386, AMD64 and IA64 and a Wix include (wxi) containing the common files. I'm able to pass in variables for Win64 and Source at build time. You could also use fragments to get the same thing done but I think there may be a bit more to manage that way. Thanks, Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magus Sent: Tuesday, May 22, 2007 4:43 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing both X64 and X86 problems. My first quesiton is, can I install both x64 and x86 with the same installer. IF so, if I specify Program files, does it know which program files directory to put the files into? I shouldn't have my x64 applicaiton installing to the Program Files(x86) directory, but the data between the x86 and x64 is the same data, so the only thing different between the two is the executables, (2 executables(x86, x64) sharing the same data files). Would it be simplier to make two different installers or is there an easy way to share this information between them. -- View this message in context: http://www.nabble.com/Installing-both-X64-and-X86-problems.-tf3800346.ht ml#a10752179 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Allowing sources from either x64 or x86
I've got a rather simple question that is probably due to some obvious in hindsight error, but I'm totally stymied by it and haven't had any luck searching for a solution. I just recently switched from an x86 machine to an x64 machine running XP x64. I suddenly find that some of the installers I've written don't compile because they're looking for files in Program Files rather than Program Files (x86). In particular the Microsoft VC80 CRT and MFC merge modules in Program Files (x86)\Common Files\Merge Modules are being problematic. I thought for starters I could try using ProgramFilesFolder to see if that would resolve properly, but I can't get it to work correctly. I've got the following setup in the relevant wxs file: ?if ($(var.PLATFORM) = Win32)? ?define PROGRAMFILESFOLDER = ProgramFilesFolder? Directory Id=$(var.PROGRAMFILESFOLDER) Name=PFiles So at first I thought it'd try Merge Id=CRT Language=0 src=$(var.PROGRAMFILESFOLDER)\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm DiskId=1 FileCompression=yes / However that results in the error: Error 25 error LGHT0100 : File of type 'Module' with name 'ProgramFilesFolder\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm' could not be found. light.exe So it's getting resolved to ProgramFilesFolder but not getting any further. I tried [ProgramFilesFolder] instead, but that didn't work either. Is there some other variable I should be using or am I going about this in entirely the wrong way? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Allowing sources from either x64 or x86
You're looking for something defined at build time. Try $(env.ProgramFiles). Windows defines the ProgramFiles environment variable to the location of the Program Files folder. I'm not guaranteeing this will work as I don't have an x64 system and don't know whether ProgramFiles is defined differently for a 64-bit versus 32-bit process. I _think_ that since the WiX toolset is compiled with .NET 1.1, all the programs will run in 32-bit processes. Personally I prefer to put all my dependencies under my source tree and check them into source control so I can be certain that all builds are fully reproducible. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: 22 May 2007 23:23 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Allowing sources from either x64 or x86 I've got a rather simple question that is probably due to some obvious in hindsight error, but I'm totally stymied by it and haven't had any luck searching for a solution. I just recently switched from an x86 machine to an x64 machine running XP x64. I suddenly find that some of the installers I've written don't compile because they're looking for files in Program Files rather than Program Files (x86). In particular the Microsoft VC80 CRT and MFC merge modules in Program Files (x86)\Common Files\Merge Modules are being problematic. I thought for starters I could try using ProgramFilesFolder to see if that would resolve properly, but I can't get it to work correctly. I've got the following setup in the relevant wxs file: ?if ($(var.PLATFORM) = Win32)? ?define PROGRAMFILESFOLDER = ProgramFilesFolder? Directory Id=$(var.PROGRAMFILESFOLDER) Name=PFiles So at first I thought it'd try Merge Id=CRT Language=0 src=$(var.PROGRAMFILESFOLDER)\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm DiskId=1 FileCompression=yes / However that results in the error: Error 25 error LGHT0100 : File of type 'Module' with name 'ProgramFilesFolder\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm' could not be found. light.exe So it's getting resolved to ProgramFilesFolder but not getting any further. I tried [ProgramFilesFolder] instead, but that didn't work either. Is there some other variable I should be using or am I going about this in entirely the wrong way? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] conditionally set permission
Is there a way to conditionally set permission on a folder depending on a property value? If value then set permission else do not set permission. I'd like to set a permission on a newly created folder if the user exists, but if the user doesn't exist then of course I don't want to set permissions for it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with SQL custom actions.
Something got broken in the build process: ConfigureSql is not exported from the CA DLL contained in WixSqlExtension.dll. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 22 May 2007 18:48 To: Aaron Shurts; Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problem with SQL custom actions. That was a huge integration last week. It is possible that you've found a bug in the integration (or even scarier a bug that wasn't fixed in WiX v2 either). Is it possible to share the .wxs and SQL script? The last bugs we've fixed have all been edge cases where the SQL Script had to be set just so. Difficult to review. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Shurts Sent: Tuesday, May 22, 2007 9:55 AM To: Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problem with SQL custom actions. Maybe I am grasping at straws trying to get this v3 to work, but the latest weekly release (3.0.2921.0) doesn't even get in to the custom action DLL. Now I am getting this: MSI (s) (FC:3C) [09:35:15:234]: Doing action: ConfigureSql Action 9:35:15: ConfigureSql. Configuring SQL Server Action start 9:35:15: ConfigureSql. MSI (s) (FC:E4) [09:35:15:250]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10D.tmp, Entrypoint: ConfigureSql MSI (s) (FC:3C) [09:35:15:312]: Note: 1: 1723 2: ConfigureSql 3: ConfigureSql 4: C:\WINDOWS\Installer\MSI10D.tmp Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp MSI (s) (FC:3C) [09:35:16:531]: Product: Enterprise Reporting Server -- Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp Action ended 9:35:16: ConfigureSql. Return value 3. Any thoughts / suggestions? The DLL is actually in the binary table, so it's not a matter of the DLL missing. Regards, //aj On 5/21/07, Bob Arnson [EMAIL PROTECTED] wrote: Aaron Shurts wrote: I decided to go with v3 because I didn't feel like re-writing all the deprecated tags when v3 is released. I think we have a fix for it in the meantime, but it sure would be nice if the fixes were propagated in to the v3 code branch. Check the latest weekly release: RobMen: Reverse integrate WiX v2 CustomAction fixes. -- sig://boB http://joyofsetup.com/ http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with SQL custom actions.
Actually, it looks like you changed the name of the entry point to InstallSqlData and added an UninstallSqlData, but did not change src\ext\SqlExtension\wixlib\SqlExtension.wxs. You did change src\ca\serverca\scawixlib\sca.wxs, but I don't think that file is used any more in WiX v3. Sorry, guys, looks like WiX 3.0.2921.0 isn't going to work for anyone who needs the SQL features, unless you modify SqlExtension.wxs and build WiX yourself. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: 23 May 2007 00:06 To: 'Rob Mensching'; 'Aaron Shurts'; 'Bob Arnson' Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problem with SQL custom actions. Something got broken in the build process: ConfigureSql is not exported from the CA DLL contained in WixSqlExtension.dll. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 22 May 2007 18:48 To: Aaron Shurts; Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problem with SQL custom actions. That was a huge integration last week. It is possible that you've found a bug in the integration (or even scarier a bug that wasn't fixed in WiX v2 either). Is it possible to share the .wxs and SQL script? The last bugs we've fixed have all been edge cases where the SQL Script had to be set just so. Difficult to review. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Shurts Sent: Tuesday, May 22, 2007 9:55 AM To: Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problem with SQL custom actions. Maybe I am grasping at straws trying to get this v3 to work, but the latest weekly release (3.0.2921.0) doesn't even get in to the custom action DLL. Now I am getting this: MSI (s) (FC:3C) [09:35:15:234]: Doing action: ConfigureSql Action 9:35:15: ConfigureSql. Configuring SQL Server Action start 9:35:15: ConfigureSql. MSI (s) (FC:E4) [09:35:15:250]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10D.tmp, Entrypoint: ConfigureSql MSI (s) (FC:3C) [09:35:15:312]: Note: 1: 1723 2: ConfigureSql 3: ConfigureSql 4: C:\WINDOWS\Installer\MSI10D.tmp Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp MSI (s) (FC:3C) [09:35:16:531]: Product: Enterprise Reporting Server -- Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp Action ended 9:35:16: ConfigureSql. Return value 3. Any thoughts / suggestions? The DLL is actually in the binary table, so it's not a matter of the DLL missing. Regards, //aj On 5/21/07, Bob Arnson [EMAIL PROTECTED] wrote: Aaron Shurts wrote: I decided to go with v3 because I didn't feel like re-writing all the deprecated tags when v3 is released. I think we have a fix for it in the meantime, but it sure would be nice if the fixes were propagated in to the v3 code branch. Check the latest weekly release: RobMen: Reverse integrate WiX v2 CustomAction fixes. -- sig://boB http://joyofsetup.com/ http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can I put preprocessor directly under Wix tag?
Hello, I plan to add preprocessor before the Product, under Wix, is that possible? Wix ... ?define var0 = value ? Product ... /Product /Wix Thanks, - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with SQL custom actions.
This is actually good news. I thought I was doing something crazy wrong. :-) On a side note, if I want to build this myself, every time I try to open the solution, I get all kinds of errors that the project files are not valid project files. Is there something I am missing? Regards, //aj On 5/22/07, Mike Dimmick [EMAIL PROTECTED] wrote: Actually, it looks like you changed the name of the entry point to InstallSqlData and added an UninstallSqlData, but did not change src\ext\SqlExtension\wixlib\SqlExtension.wxs. You did change src\ca\serverca\scawixlib\sca.wxs, but I don't think that file is used any more in WiX v3. Sorry, guys, looks like WiX 3.0.2921.0 isn't going to work for anyone who needs the SQL features, unless you modify SqlExtension.wxs and build WiX yourself. -- Mike Dimmick -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Mike Dimmick *Sent:* 23 May 2007 00:06 *To:* 'Rob Mensching'; 'Aaron Shurts'; 'Bob Arnson' *Cc:* wix-users@lists.sourceforge.net *Subject:* Re: [WiX-users] Problem with SQL custom actions. Something got broken in the build process: ConfigureSql is not exported from the CA DLL contained in WixSqlExtension.dll. -- Mike Dimmick -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Rob Mensching *Sent:* 22 May 2007 18:48 *To:* Aaron Shurts; Bob Arnson *Cc:* Mike Dimmick; wix-users@lists.sourceforge.net *Subject:* Re: [WiX-users] Problem with SQL custom actions. That was a huge integration last week. It is possible that you've found a bug in the integration (or even scarier a bug that wasn't fixed in WiX v2 either). Is it possible to share the .wxs and SQL script? The last bugs we've fixed have all been edge cases where the SQL Script had to be set just so. Difficult to review. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Aaron Shurts *Sent:* Tuesday, May 22, 2007 9:55 AM *To:* Bob Arnson *Cc:* Mike Dimmick; wix-users@lists.sourceforge.net *Subject:* Re: [WiX-users] Problem with SQL custom actions. Maybe I am grasping at straws trying to get this v3 to work, but the latest weekly release (3.0.2921.0) doesn't even get in to the custom action DLL. Now I am getting this: MSI (s) (FC:3C) [09:35:15:234]: Doing action: ConfigureSql Action 9:35:15: ConfigureSql. Configuring SQL Server Action start 9:35:15: ConfigureSql. MSI (s) (FC:E4) [09:35:15:250]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10D.tmp, Entrypoint: ConfigureSql MSI (s) (FC:3C) [09:35:15:312]: Note: 1: 1723 2: ConfigureSql 3: ConfigureSql 4: C:\WINDOWS\Installer\MSI10D.tmp Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp MSI (s) (FC:3C) [09:35:16:531]: Product: Enterprise Reporting Server -- Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action ConfigureSql, entry: ConfigureSql, library: C:\WINDOWS\Installer\MSI10D.tmp Action ended 9:35:16: ConfigureSql. Return value 3. Any thoughts / suggestions? The DLL is actually in the binary table, so it's not a matter of the DLL missing. Regards, //aj On 5/21/07, *Bob Arnson* [EMAIL PROTECTED] wrote: Aaron Shurts wrote: I decided to go with v3 because I didn't feel like re-writing all the deprecated tags when v3 is released. I think we have a fix for it in the meantime, but it sure would be nice if the fixes were propagated in to the v3 code branch. Check the latest weekly release: RobMen: Reverse integrate WiX v2 CustomAction fixes. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Allowing sources from either x64 or x86
This the ProgramFiles64Folder property isn't it? Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, May 22, 2007 3:57 PM To: 'Geoff Finger'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Allowing sources from either x64 or x86 You're looking for something defined at build time. Try $(env.ProgramFiles). Windows defines the ProgramFiles environment variable to the location of the Program Files folder. I'm not guaranteeing this will work as I don't have an x64 system and don't know whether ProgramFiles is defined differently for a 64-bit versus 32-bit process. I _think_ that since the WiX toolset is compiled with .NET 1.1, all the programs will run in 32-bit processes. Personally I prefer to put all my dependencies under my source tree and check them into source control so I can be certain that all builds are fully reproducible. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: 22 May 2007 23:23 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Allowing sources from either x64 or x86 I've got a rather simple question that is probably due to some obvious in hindsight error, but I'm totally stymied by it and haven't had any luck searching for a solution. I just recently switched from an x86 machine to an x64 machine running XP x64. I suddenly find that some of the installers I've written don't compile because they're looking for files in Program Files rather than Program Files (x86). In particular the Microsoft VC80 CRT and MFC merge modules in Program Files (x86)\Common Files\Merge Modules are being problematic. I thought for starters I could try using ProgramFilesFolder to see if that would resolve properly, but I can't get it to work correctly. I've got the following setup in the relevant wxs file: ?if ($(var.PLATFORM) = Win32)? ?define PROGRAMFILESFOLDER = ProgramFilesFolder? Directory Id=$(var.PROGRAMFILESFOLDER) Name=PFiles So at first I thought it'd try Merge Id=CRT Language=0 src=$(var.PROGRAMFILESFOLDER)\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm DiskId=1 FileCompression=yes / However that results in the error: Error 25 error LGHT0100 : File of type 'Module' with name 'ProgramFilesFolder\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm' could not be found. light.exe So it's getting resolved to ProgramFilesFolder but not getting any further. I tried [ProgramFilesFolder] instead, but that didn't work either. Is there some other variable I should be using or am I going about this in entirely the wrong way? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Allowing sources from either x64 or x86
That worked, thank you! And of _course_ var.PROGRAMFILESFOLDER is going to have issues at build time, what was I thinking? *sigh* On 5/22/07, Mike Dimmick [EMAIL PROTECTED] wrote: You're looking for something defined at build time. Try $(env.ProgramFiles). Windows defines the ProgramFiles environment variable to the location of the Program Files folder. I'm not guaranteeing this will work as I don't have an x64 system and don't know whether ProgramFiles is defined differently for a 64-bit versus 32-bit process. I _think_ that since the WiX toolset is compiled with .NET 1.1, all the programs will run in 32-bit processes. Personally I prefer to put all my dependencies under my source tree and check them into source control so I can be certain that all builds are fully reproducible. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: 22 May 2007 23:23 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Allowing sources from either x64 or x86 I've got a rather simple question that is probably due to some obvious in hindsight error, but I'm totally stymied by it and haven't had any luck searching for a solution. I just recently switched from an x86 machine to an x64 machine running XP x64. I suddenly find that some of the installers I've written don't compile because they're looking for files in Program Files rather than Program Files (x86). In particular the Microsoft VC80 CRT and MFC merge modules in Program Files (x86)\Common Files\Merge Modules are being problematic. I thought for starters I could try using ProgramFilesFolder to see if that would resolve properly, but I can't get it to work correctly. I've got the following setup in the relevant wxs file: ?if ($(var.PLATFORM) = Win32)? ?define PROGRAMFILESFOLDER = ProgramFilesFolder? Directory Id=$(var.PROGRAMFILESFOLDER) Name=PFiles So at first I thought it'd try Merge Id=CRT Language=0 src=$(var.PROGRAMFILESFOLDER)\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm DiskId=1 FileCompression=yes / However that results in the error: Error 25 error LGHT0100 : File of type 'Module' with name 'ProgramFilesFolder\Common Files\Merge Modules\Microsoft_VC80_CRT_x86.msm' could not be found. light.exe So it's getting resolved to ProgramFilesFolder but not getting any further. I tried [ProgramFilesFolder] instead, but that didn't work either. Is there some other variable I should be using or am I going about this in entirely the wrong way? Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Am I using a property and condition correctly
Hi, I'm not sure what I'm doing wrong. When one feature is selected it will go to a certain dialog, in this dialog I will always set a property to true. And later I will check this property in a component. Here is what I have in the dialog: Control Id=Next Type=PushButton X=236 Y=243 Width=56 Height=17 Default=yes Disabled=no Text=$(loc.WixUINext) Publish Property=ISWEBBOX Value=TRUETRUE/Publish Publish Event=NewDialog Value=[WixUI_WEBConfigToReadyToInstall_Next]/Publish /Control And in the component: Component Id='Comp1' Guid='345c09f9-f760-4700-89da-12f1a1cbf08c' KeyPath=yes DiskId=1 Condition![CDATA[(ISWEBBOX = 'FALSE')]]/Condition ... (I cut out the stuff here, doesn't matter) /Component Component Id='Comp2' Guid='0BBCE421-BC25-46cc-8A86-3F9EAEF4A839' Condition![CDATA[(ISWEBBOX = 'TRUE')]]/Condition CreateFolder / ... (I cut out the stuff here, doesn't matter) /Component Any help would be much appreciated! Thanks, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Am I using a property and condition correctly
Ignore those extra spaces, I don't know where they came from. :-P Publish Property=ISWEBBOX Value=TRUE1/Publish //aj On 5/22/07, Aaron Shurts [EMAIL PROTECTED] wrote: The condition on your publish property event appears to be the problem. If you always want this event to trigger than this text: Publish Property= ISWEBBOX Value=TRUE TRUE/Publish should read like this: Publish Property = ISWEBBOX Value= TRUE1/ Publish When you have just TRUE in there. The installer isn't really checking against anything so that condition will always evaluate to false. 1 means run this all the time. Regards, //aj On 5/22/07, Mike Menaker [EMAIL PROTECTED] wrote: Hi, I'm not sure what I'm doing wrong. When one feature is selected it will go to a certain dialog, in this dialog I will always set a property to true. And later I will check this property in a component. Here is what I have in the dialog: Control Id = Next Type= PushButton X =236 Y =243 Width =56 Height=17 Default=yes Disabled= no Text= $(loc.WixUINext) Publish Property = ISWEBBOX Value= TRUETRUE/ Publish Publish Event = NewDialog Value= [WixUI_WEBConfigToReadyToInstall_Next]/Publish / Control And in the component: Component Id =' Comp1' Guid=' 345c09f9-f760-4700-89da-12f1a1cbf08c' KeyPath =yes DiskId=1 Condition![CDATA[ (ISWEBBOX = 'FALSE')]]/Condition … (I cut out the stuff here, doesn't matter) / Component Component Id =' Comp2' Guid=' 0BBCE421-BC25-46cc-8A86-3F9EAEF4A839' Condition![CDATA[ (ISWEBBOX = 'TRUE')]]/Condition CreateFolder / … (I cut out the stuff here, doesn't matter) /Component Any help would be much appreciated! Thanks, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing dialogs
I always create my own based off of the Mondo file, but I would assume you should be able to use the DialogRef tag to overwrite/alter the elements that you wish. Someone correct me if I am wrong. Regards, //aj On 5/22/07, Kevin Fischer [EMAIL PROTECTED] wrote: I'm currently using the WixUI_InstallDir dialog set for my install UI. I need to make several minor changes to the stock dialogs including: 1) removing specific icons from dialogs 2) using different text for a few of the controls 3) removing controls and changing their behavior I know I can change text (#2) by using a new localization file. Are the other items possible without copying the entire UI source code into my project? I was unable to figure out how to do #1 or #2 without doing that. I know about inserting/removing dialogs into the sequence, but I would end up defining replacements for most of the core dialogs if I did that. Thanks, Kevin -- Change is good. See what's different about Windows Live Hotmail. Check it out!http://www.windowslive-hotmail.com/learnmore/default.html?locale=en-usocid=RMT_TAGLM_HMWL_reten_changegood_0507 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing dialogs
Kevin Fischer wrote: I'm currently using the WixUI_InstallDir dialog set for my install UI. I need to make several minor changes to the stock dialogs including: 1) removing specific icons from dialogs 2) using different text for a few of the controls 3) removing controls and changing their behavior The MSI UI model doesn't really allow fine-grained customization; we added some of that via the floating Publish element to let you specify behavior outside the dialog element. (The WixUI_InstallDir.wxs fragment has them for most of its dialogs, for example.) Currently, it's only possible to add behavior; you can't remove anything. It might be possible to use control conditions to hide the elements you're interested in removing but right now, there's no such thing as a floating Condition element. It'd make a great addition, however, so feel free to file a feature request or submit a patch.g -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
