[WiX-users] Using the same .exe file for different services in one MSI?
Hello everyone, our product contains multiple services and all use the same .exe file and differ only via their name and command line, where a DLL name is passed that contains the real service code. So the exe file is more or less a reusable framework much like svchost.exe and distinct service functionality is implemented in DLLs. Is it possible to use the WiX ServiceInstall element to install multiple such services from one WiX script or is this simply impossible and I have to resort to a custom action? As far as I see, the File element whose Keypath is set to 'Yes' within the component where the ServiceInstall element resides, is considered the BinaryPath of the service. In my case however, this file element would be the same for different services/components and even worse, other installs that we are about to write in the future will use the same exe file as well so ideally it would be in one component that we reuse across installs. Any help appreciated, -- Stefan Kuhr -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-the-same-exe-file-for-different-services-in-one-MSI-tp6520212p6520212.html Sent from the wix-users mailing list archive at Nabble.com. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [SPAM] Languages attribute in package element
Hello everyone, I posted this question a few day ago, but not to this sub-forum, so maybe this is why no one answered. The wix-users sub-forum is probably a better place for it: I am just reading the Ramirez book on Wix. The author writes here about the Languages attribute of the Package element: When the end user launches the installer, their computer looks to the Package element to find out what the supported language is. If that language isn't installed locally, an error will be displayed telling the user so. However, up to now, I have always set this attribute to 1033 (en-US) and never received complaints about my MSIs not installing on localized versions of Windows. Am I missing something or is this statement of the author just plain wrong? -- Stefan Kuhr -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Languages-attribute-in-package-element-tp5861785p5861785.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How can I use DefaultVersion for unversioned files?
Hello Bob, Bob Arnson-6 wrote: On 6/19/2010 4:06 AM, Stefan Kuhr wrote: is it possible to use the DefaultVersion attribute for unversioned files? No. DefaultVersion just sets the File.Version column. See the MSI SDK doc for the File table for limitations. OK, thanks for the answer and the clarification. I still wonder how Jim Evans did this with his text file, I am referring to: http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg19007.html So what would then be a proper solution for my problem? I have PNG files (so theses are unversioned by definition) that I always want to replace with those from my install, even if the customer replaced them with his own files in the older version of my app that I am about to upgrade with a major update. I am always doing major updates and currently have only one file per component, so each PNG file represents its own component. I guess if I created each PNG-component with a new GUID with each new major version that would break component rules, right? Would making the PNG files companion files of a DLL or exe, that I replace with a new version in each major update, solve the problem? Thanks, -- Stefan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-can-I-use-DefaultVersion-for-unversioned-files-tp5198138p5209040.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How can I use DefaultVersion for unversioned files?
Hello everyone, is it possible to use the DefaultVersion attribute for unversioned files? I ship PNG files as part of my install. I always want the PNG files that come with my installer to copy over the PNG files of an older version of my product, even if the user has modified them or replaced them with his own files. So I thought, I could give the PNG files in my WiX source code the DefaultVersion attribute and increment their version number with each new version of my product. However, if I add the DefaultVersion attribute to one of my PNG files, I get the following linker error: error LGHT1103: The DefaultVersion '1.2.3' was used for file 'AbcPng' which has no version. No entry for this file will be placed in the MsiFileHash table. For unversioned files, specifying a version that is different from the actual file may result in unexpected versioning behavior during a repair or while patching. Version the resource to eliminate this warning. So what am I doing wrong? I read that people use the DefaultVersion attribute for text files, so this must work somehow. What am I missing? Or does the DefaultVersion attribute only work for Windows PE files that contain a version info resource in order to achieve version lying? Any help appreciated, -- Stefan Kuhr -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-can-I-use-DefaultVersion-for-unversioned-files-tp5198138p5198138.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Files missing after major update - what am I doing wrong?
Hello everyone, new releases of my app are always installed with a major update and the old version of the app is always uninstalled if the MSI for the new version runs, just before the MSI of the new version does its work copying files, creating registry entries and so on. Now if my app currently runs, it has file handles open to files that are also installed via the MSI, those are PNG files, in case this is important. Now if a new version of the app gets installed while the old version is running and the old version is first uninstalled, those PNG files cannot be deleted and are scheduled to be removed after the next reboot (via PendingFileRenameOperations in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager). Now the new version of my app is installed which brings the same PNG files, that the old version had and after reboot they are now gone. So for the user it seems like the freshly installed new version of my app is lacking the PNG files that the old version had, just because the app was running (as the old version) at the very moment, when the new version was installed. Obviously the exe and DLL files of the currently running old version of the app are moved to c:\Config.Msi\.rbf and are then scheduled to be removed from this location at the next reboot, but not those PNG files, they are scheduled to be removed from the install directory. What is going wrong here? What can be done so the PNG files are also moved to c:\Config.Msi as an rbf file and then scheduled to be removed during reboot from there? Or maybe I am doing sth entirely wrong? Any help appreciated, -- Stefan Kuhr -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Files-missing-after-major-update-what-am-I-doing-wrong-tp5125447p5125447.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Files missing after major update - what am I doing wrong?
Yes, sure, my application holds a lock on these files. I would expect that MSI can deal with such a situation, because having a file open is an everday scenario, even if this happens only for a short time. It can deal with exe and dll files that are currently running and the files that are locked because of that, why can't it in my case with the PNG files or any other file that the app is currently holding a file handle open to? -- Stefan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Files-missing-after-major-update-what-am-I-doing-wrong-tp5125447p5127026.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Files missing after major update - what am I doing wrong?
Hi Blair, I did some more investigation and reading archived posts to this group. Until now I had RemoveExistingProducts scheduled before InstallInitialize in all my installs. If I now schedule it after InstallFinalize, everything seems to work. Is this the way to go? Is there any downside to schedule RemoveExistingProducts after InstallFinalize? Can I do this for every install? I mean, all my installations up to now had RemoveExistingProducts scheduled before InstallInitialize, are there any types of installs (whatever that is) that should not schedule RemoveExistingProducts after InstallFinalize? E.g. installs that install services or some other sort of unusual installs? What can break if I schedule RemoveExistingProducts after InstallFinalize? Any advice appreciated, -- Stefan Kuhr -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Files-missing-after-major-update-what-am-I-doing-wrong-tp5125447p5127517.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent files in use dialog?
Hello Neil, Neil Sleightholm wrote: You can use the MSIRESTARTMANAGERCONTROL property to disable restart manager (http://msdn.microsoft.com/en-us/library/aa370377(VS.85).aspx). I have had issues with RM and services, does your install include a service? [...] No, it doesn't, it is simply an app that runs on the user's desktop. I have made a number of experiments in the meantime with different values of the MSIRESTARTMANAGERCONTROL when doing a major upgrade with msiexec /qb from one build of my software to the next if the app from the older build is currently running. And the results really puzzle me and nourish my doubts on the real value of the Windows Vista restart manager. These are my results for the different values of this property and my observations, maybe someone can comment on them, notehowever, that the app is fully registered with the restart manager: 0: The dialog The following applications should be appears. If I choose Automatically close applications and attempt to restart... the running instance of the older build shuts down and after install a new instance from the newer build is started. Disable: No dialog appears, the running instance continues to run. Just like the install experience on Windows XP DisableShutdown: The dialog The following applications should be appears. If I choose Automatically close applications and attempt to restart... the running instance of the older build shuts down and after install a new instance from the newer build is started. From my observations, there is no difference between MSIRESTARTMANAGERCONTROL having the value 0 or DisableShutdown. Both times this annoying dialog appears and the app is restarted after the install. However what I would like to have is no dialog but restart of the app. So the UI should be like MSIRESTARTMANAGERCONTROL=Disable (i.e. no dialog) but the restart behaviour like with MSIRESTARTMANAGERCONTROL=0 or MSIRESTARTMANAGERCONTROL=DisableShutdown (in both cases the app is restarted). Is what I would like to have simply not possible? Or against the design of the restart manager and its coupling with MSI? Any help appreciated, -- Stefan Kuhr -- View this message in context: http://n2.nabble.com/Prevent-%22files-in-use%22-dialog--tp3115333p3125753.html Sent from the wix-users mailing list archive at Nabble.com. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent files in use dialog?
Hi Alex, Alex Shevchuk-2 wrote: However what I would like to have is no dialog but restart of the app. Hi Stefan, This blog post (http://blogs.msdn.com/windows_installer_team/archive/2006/12/11/windows-ins taller-and-restart-manager-msi-files-in-use-v2.aspx) explains the behavior in different UI modes. Looks like what you want is possible only in No UI mode. Yes sure. Maybe I forgot to mention that everything works quite nicely if I run msiexec with /qn. But management would like to see the /qb scenario with progress bars to run in an unattended mode and unfortunately this dialog is killing the unattended scenario. -- Stefan Kuhr -- View this message in context: http://n2.nabble.com/Prevent-%22files-in-use%22-dialog--tp3115333p3126129.html Sent from the wix-users mailing list archive at Nabble.com. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent files in use dialog?
Hello everyone, When running my msi as part of a major upgrade on Vista with msiexec /qb, I get a dialog stating The following applications should be closed before continuing the install followed by the app that the msi will replace and that is currently running and the option to close and attempt to restart the app or instead not to close the app and thus require a reboot. A similar dialog with something like Files in use in its text appears if I run the msi with full UI. On Windows XP or Windows 2000 no such dialogs appear at all. How can I prevent these two dialogs from appearing? My app is already Vista restart manager aware so it successfully restarts after an update, therefore I see no reason why these dialogs should appear at all. Am I missing something? I am using WiX version 3.0.4805 in case that matters. Any help appreciated, -- Stefan Kuhr -- View this message in context: http://n2.nabble.com/Prevent-%22files-in-use%22-dialog--tp3115333p3115333.html Sent from the wix-users mailing list archive at Nabble.com. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a better way for custom UI?
Hi Neil, Neil Sleightholm wrote: I documented the approach I use here: http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html. Works like a charm with my projects. Thank you. -- Stefan Kuhr -- View this message in context: http://n2.nabble.com/Is-there-a-better-way-for-custom-UI--tp2264821p2274427.html Sent from the wix-users mailing list archive at Nabble.com. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a better way for custom UI?
Hi Neil Neil Sleightholm wrote: I documented the approach I use here: http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html. Thank you, this looks promising. I will give that a try. -- Stefan -- View this message in context: http://n2.nabble.com/Is-there-a-better-way-for-custom-UI--tp2264821p2268310.html Sent from the wix-users mailing list archive at Nabble.com. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Is there a better way for custom UI?
Hello everyone, I currently maintain a number of WiX3 based MSI setups that use custom UI. For the custom UI I create a copy of the wixui sources from the WiX sources package, customize it, create my own wixlib and link against that instead of creating a reference to the stock WixUIExtension.dll. I think I have this technique from the tramontana tutorial. Is there meanwhile a simpler way of creating a custom UI? Creating a custom wixlib gets tedious over time and I always have to update my copy of the sources if I adopt a new WiX3 build in case files in the wixui extension have changed. Also, my builds take a much longer time if I have to create a wixlib for every setup, so I really would like to get rid of these custom wixlibs if possible. Any help appreciated, -- Stefan Kuhr -- View this message in context: http://n2.nabble.com/Is-there-a-better-way-for-custom-UI--tp2264821p2264821.html Sent from the wix-users mailing list archive at Nabble.com. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Running MSI as SYSTEM and no ARP and other weirdnesses?
Hello everyone, I have an MSI built with WiX. If I install this using msiexec from the SYSTEM account, the product gets installed (files and registry keys are there) but it is not visible in ARP. Also if I run this MSI then again from an interactive user, I do not get the option to repair or remove it but instead the UI behaves as if the product had not been previously installed. Can someone explain to me what's happening there? I'd rather have an entry in ARP as if it was installed by an ordinary user. -- Stefan -- View this message in context: http://n2.nabble.com/Running-MSI-as-SYSTEM-and-no-ARP-and-other-weirdnesses--tp721312p721312.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running MSI as SYSTEM and no ARP and other weirdnesses?
Hi Pierson, Pierson Lee wrote: Two questions: 1. If you run through interactive does it appear in ARP? 2. Do you have the GUIDs setup for Product Code, Upgrade code, Components, etc? The answer to both questions is yes. -- Stefan -- View this message in context: http://n2.nabble.com/Running-MSI-as-SYSTEM-and-no-ARP-and-other-weirdnesses--tp721312p721740.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running MSI as SYSTEM and no ARP and other weirdnesses?
Hi Johan, Johan Appelgren wrote: Are you doing a per-user or a per-machine install? Oops, please excuse my ignorance, but how do I know that? The command line is the same as I would install as an interactive user, something like: msiexec.exe /i path-to-my.msi /qn /l*v path-to-logfile I use the exact same command line as I would when logging in interactively, but now just running as SYSTEM. The real purpose of all this is to remotely install an MSI and the msiexec command line is executed as a scheduled task running as SYSTEM. However I experienced the same behaviour when starting this MSI from an interactive command shell run as SYSTEm with the cmdasuser tool. -- Stefan -- View this message in context: http://n2.nabble.com/Running-MSI-as-SYSTEM-and-no-ARP-and-other-weirdnesses--tp721312p721744.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running MSI as SYSTEM and no ARP and other weirdnesses?
Hi Johan, Johan Appelgren wrote: That is determined by the ALLUSERS property. If it is not set you get a per-user installation, so I'm guessing that is what you have. OMG, your guess was right. I normally place the ALLUSERS property in every WiX project I create but this time I forgot it. Thanks, Johan! -- Stefan -- View this message in context: http://n2.nabble.com/Running-MSI-as-SYSTEM-and-no-ARP-and-other-weirdnesses--tp721312p722406.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Strange CNDL1054 errors with weekly builds
Hi Bob, Bob Arnson-6 wrote: [...] You might want to try running the candle command at a console to get more details. CNDL1054 is a deprecation warning so the schema changed since the version you authored against. WixCop might convert the authoring for you. Thanks, I didn't know that builds in VS2005 seem to somehow suppress the real error message. In my case it was the now deprecated Platforms attribute in the Package element. Thanks again for helping. -- Stefan -- View this message in context: http://www.nabble.com/Strange-CNDL1054-errors-with-weekly-builds-tf4891783.html#a14126589 Sent from the wix-users mailing list archive at Nabble.com. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Strange CNDL1054 errors with weekly builds
Hello everyone, up to now I used the last official build, build 2925 for my installs. I want to use the patching feature as described in Peter Marcu's Blog and tried to build my installs with the latest weekly build. Unfortunately, I now get very strange CNDL1054 errors. I tried to find out what the latest build is, that shows no problems and this is build 3206 (as of 08/07/2007). From Build 3210 onwards (08/10/2007) I always get CNDL1054 errors for no apparent reason. This is an excerpt of my build output in the VS2005 build output window: -- Rebuild All started: Project: capadmin, Configuration: Debug Any CPU -- C:\Program Files\Windows Installer XML v3\bin\candle.exe -dDebug -dBINSOURCE=debug -dPLATFORMS_SUPPORTED=Intel -dWIN64=no -dPRODUCT_ID=EC06D1D8-062B-4CEC-B064-CE6CA52EF526 -dUPGRADE_CODE=6E206BE6-C5FF-453D-A3D5-94A079A02C7E -dPROGRAM_FILES_FOLDER=ProgramFilesFolder -dINT_ADMIN_EXE_COMP=06D732AB-A4B0-4E8D-81C4-AE239DE4D9CB -dADMIN_DEU_RES_COMP=9B057DAF-AD84-475A-BCB2-CEB23FBB34DB -dINT_ADMIN_ELEV_LAUNCH_COMP=A5F5AFC2-AF38-499A-B432-296311DB720F -dINT_ADMIN_DLL_COMP=81400583-005B-4D2D-9330-35ED993A357E -dINOTE_MSG_COMP=3866AAFA-A14E-4EA8-8D56-F5AE1DD582B9 -dINT_AD_CHM_COMP=E31E98FA-A7D4-4F25-81B3-242C47C486B7 -dINT_AD_CHM_DEU_COMP=66706EF0-5716-41AD-96ED-AFF2657A66FC -dDevEnvDir=*Undefined if not building from within Visual Studio* -dSolutionDir=*Undefined if not building a solution or within Visual Studio* -dSolutionExt=*Undefined if not building a solution or within Visual Studio* -dSolutionFileName=*Undefined if not building a solution or within Visual Studio* -dSolutionName=*Undefined if not building a solution or within Visual Studio* -dSolutionPath=*Undefined if not building a solution or within Visual Studio* -out obj\Debug\capadmin.wixobj -pedantic -ext C:\Program Files\Windows Installer XML v3\bin\WixUIExtension.dll -wx capadmin.wxs C:\applic\cap\installer\capadmin\capadmin\capadmin.wxs(8,0)Error CNDL1054: Done building project capadmin.wixproj -- FAILED. Build FAILED Another project shows this output: -- Rebuild All started: Project: inotesvc, Configuration: Debug Any CPU -- C:\Program Files\Windows Installer XML v3\bin\candle.exe -dDebug -dBINSOURCE=debug -dPLATFORMS_SUPPORTED=Intel -dWIN64=no -dPRODUCT_ID=E14EEFDE-D467-4A6B-ABF9-6C69EC0D57BB -dUPGRADE_CODE=378A235C-8C54-436F-9F70-B208001CD96F -dPROGRAM_FILES_FOLDER=ProgramFilesFolder -dTRIGGER_COMPONENT=55233D5B-C643-42BD-A51C-B41221EAD167 -dPANEL_COMPONENT=414875AE-A61F-47BA-97F9-DE671569191E -dRTL_COMPONENT=7DF65316-835C-4025-8458-3E6DFCC9DB77 -dSVC_COMPONENT=E3F7A496-2268-4442-A3D8-612D38EE64A0 -dMSG_COMPONENT=3866AAFA-A14E-4EA8-8D56-F5AE1DD582B9 -dCAT_COMPONENT=658E64F5-3C64-42B9-B556-ABBFC05EF9E6 -dDevEnvDir=*Undefined if not building from within Visual Studio* -dSolutionDir=*Undefined if not building a solution or within Visual Studio* -dSolutionExt=*Undefined if not building a solution or within Visual Studio* -dSolutionFileName=*Undefined if not building a solution or within Visual Studio* -dSolutionName=*Undefined if not building a solution or within Visual Studio* -dSolutionPath=*Undefined if not building a solution or within Visual Studio* -out obj\Debug\inotesvc.wixobj -pedantic -ext C:\Program Files\Windows Installer XML v3\bin\WixUIExtension.dll -wx inotesvc.wxs C:\applic\cap\installer\inotesvc\inotesvc.wxs(8,0)Error CNDL1054: Done building project inotesvc.wixproj -- FAILED. Build FAILED. Can anyone tell me what's wrong with my projects? What is the real reason for my failing builds? Thanks in advance, -- Stefan Kuhr -- View this message in context: http://www.nabble.com/Strange-CNDL1054-errors-with-weekly-builds-tf4891783.html#a14007908 Sent from the wix-users mailing list archive at Nabble.com. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Re use wxs for x64 Build of the same product
Hello everyone, I hope this question doesn't sound outright stupid: I have a soon-to-be-released product whose binaries are all x86. But I slo have a version of the product that is all native x64 binaries, all with the exact same file names as the x86 build. We do not have plans for an immediate release of the x64 version of the product, but how would I go about with reusing my current wxs files (for my current x86 build) for the x64 build? Do I have to use new GUIDs everywhere for the x64 components? If so, is there support in WiX version 3 that allows me to do sort of a conditional compilation and use GUID A for the x86 build and GUID B for the x64 build of one and the same component? Or should I use the same GUIDs for the x64 installer? Thanks, -- Stefan -- View this message in context: http://www.nabble.com/Reuse-wxs-for-x64-Build-of-the-same-product-tf4744279.html#a13566512 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Next official v3 build?
Hello everyone, I would like to use a version of WiX 3 that supports the new patch creation features as described on Peter Marcu's blog. While I certainly know that I could use a weekly build for that, it would give me much, much more confidence if this feature were available in an official build like the last one, build 2925 as of May 25th 2007. So can anybody tell me if there is a new official build underway in the next few weeks, so it is worth waiting for that? Is there any official release schedule plan for WiX 3 anywhere on the web so I don't have to bother anyone on this list with such a question? Thanks, -- Stefan Kuhr -- View this message in context: http://www.nabble.com/Next-official-v3-build--tf4696094.html#a13423576 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent overwrite of existing files
Hello everyone, I am currently developing our company's first install with WiX, everything before was homegrown installers or InstallShield. My WiX-based install distributes files that may also come with other installers for our product and it is very, very important that the WiX-based install will not install into directories (that the user chose) which contain files that came with other installers. So the best would be to just not let the user choose a directory where files reside that came from our other installs. After experimenting a bit I finally decided to bite the bullet and write a custom action DLL (can be found here: http://mcblogs.craalse.de/skufiles/2007/custact.zip) that scans the File table and tests for the existence of all files in this table's FileName column in the INSTALLDIR the user provided. If such a file can be found, a messagebox is shown and the install aborted, because this is an attempt to install into a directory where other installer of our products have previously installed into. While this all works I wonder if there is an easier way to achieve the same result, maybe without a custom action DLL? Any clues anyone? -- Stefan -- View this message in context: http://www.nabble.com/Prevent-overwrite-of-existing-files-tf3167486.html#a8786686 Sent from the wix-users mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
