[WiX-users] How to deal with same applications installed by two different installers?
I’ve been using WiX for a few years. I have a question that’s about installation but not strictly about WiX. But this is the only forum I know dealing with installation on Windows. If this is out of place please feel free to redirect me elsewhere, I’d appreciate it. My company currently has Product A with an installer that installs Application A. We also have a Product B which installs a Device Driver B consisting of a few DLLs. These are already released and available for download. Now I am being asked to make an installer for new Product C. The installer must be a single file that is downloaded from a web page and then executed. It must include Application A, Device Driver B, and a new Application C. The old Product A and Product B will still exist separately though. Product C does not replace them. A quick and dirty way: I could create a separate installer for just Application C, then put all three installers for A, B and C in a self-extracting Zip file so that they get run one at a time. But that is not atomic, ugly for the end user, and it’s bad for upgrades. What if only one of the three get upgraded? The other two installers will get launched anyway and prompt the user for repair or removal. Not only that, what if the user sees an upgrade for the separate Product A on our website and install that? So my best solution so far is to create a single installer for Product C that that includes all three of Application A, Driver for Device B, and Application C. But I need to forbid users from installing Product A or B since I cannot have two of Application A or Device Driver B on the same computer. So I was thinking I need to consider Product A’s Application A and Product C’s Application A as two separate things with different component GUIDs, even though they are really the same application. The same goes for the Device Driver component. One thing I’d like to know is whether the following makes sense. Could I give Application A the same component GUIDs in both Product A and Product C installers? Then if a user tried to install Product A after Product C was already installed (or an upgrade to Application A via a Product A installer) would it not harm anything? It would just be like one Application A on the system. Then could I still apply Product C upgrades later without trouble? (I can already imagine problems though with the Start Menu shortcuts if they install it to a different location on disk, by default.) I really need a multi-level install, but I know Windows Installer doesn’t work that way. Are there any better ways to handle this? Sheesh, managers don’t realize what trouble they cause when they hand you these kind of requirements. Thanks, Jim -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade without providing or removing some previous component.
Sorry for my previous empty post. Must've got sent by accident. Thanks, Peter, for your ideas. I’ll consider them. Cant you just upgrade the older installer with the fixes to A, keeping B as it was at release, and make that available to old users for download? The old installer (pre-2010) did not include B. Yes, I could make two separate upgrade installers, but it would get confusing for users to know which one they were supposed to use. Then make a later version of that installer with the new version of B and make that available for new users on CD. Upgrading people by sending them another CD would work but is kind of tough. It requires them to call up to ask for it, and would be a cost to us. I guess it depends how many of those users are out there, which I don’t know. I may have misunderstood your suggestion, though. If you don't want to make an upgrade installer you could make the upgrade available as a patch (.msp) for older users. The patch would only contain the changes to component A and couldn't be used without the older installer. A patch is harder to write than a major upgrade but, if you haven't violated component rules, it might work for you. Yes that’s one possibility and I thought of that, too. I’m not so familiar with patches so I’ll have to look into it. If it happens that we want to update the driver part of it I’m not sure a driver can be patched. We use DIFxApp for that. I had another thought along the lines of the workaround I mentioned earlier. I’m going to see if I can make an upgrade that can include a dummy component B and then use a condition for it that which is always false so B doesn't get installed. If that doesn’t work because it still removes existing, installed component Bs (which I don’t want), then I’ll try to set the condition dynamically at runtime depending on whether I find component B already on hard disk. I’m not sure if that’s possible or if it will work so I’ll need to experiment. Thanks! Jim -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Thursday, June 09, 2011 1:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Upgrade without providing or removing some previouscomponent. Cant you just upgrade the older installer with the fixes to A, keeping B as it was at release, and make that available to old users for download ? Then make a later version of that installer with the new version of B and make that available for new users on CD. If you don't want to make an upgrade installer you could make the upgrade available as a patch (.msp) for older users. The patch would only contain the changes to component A and couldn't be used without the older installer. A patch is harder to write than a major upgrade but, if you haven't violated component rules, it might work for you. -Original Message- From: Jim Hewes [mailto:jimhe...@gmail.com] Sent: 09 June 2011 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrade without providing or removing some previous component. Due to my lack of expertise in installers, I think I got into a bad situation with the wrong installer arrangement and I'm wondering what the best way out of it is. I'm using WiX 3.0, but this is a more general install problem so let me know if it's not appropriate to ask here. I have an installer that installs two components A and B both within the same feature. Component A is a device driver and some associated software. Component B is a third-party library comprised of two DLLs and is used by the driver/software. This third-party library requires a per-unit license. We distribute this on CD with the device and so by counting the CDs we can keep track of the licenses. We began including the library on the CD last year. But there are older owners of the device who would want to download the new version. We cannot put this installer on the web for download because we can't count or track those licenses. So the problem is, we want to upgrade Component A with bug fixes and make it available for web download. But we can't include component B for license reasons---because older users shouldn't get it for free. But if I leave component B out of the upgrade, I believe the upgrade process will remove B from the hard disk of legitimate owners of it. (I know if I had at least made component B as a separate feature, I could specify that it not be removed and do a major upgrade. But it's too late at this point.) My best workaround idea so far is for the upgrade to include dummy DLLs for component B that have a lower version number than the real ones. So when an upgrade happens, the real DLLs already on hard disk will be left alone. And for older users who don't have the license to the library, they will just get the dummy DLLs installed. It's messy, and I hate to think I have to do this for the life of the product. Is there a better way? I think for the future I will put component B completely
[WiX-users] Upgrade without providing or removing some previous component.
Due to my lack of expertise in installers, I think I got into a bad situation with the wrong installer arrangement and I’m wondering what the best way out of it is. I’m using WiX 3.0, but this is a more general install problem so let me know if it’s not appropriate to ask here. I have an installer that installs two components A and B both within the same feature. Component A is a device driver and some associated software. Component B is a third-party library comprised of two DLLs and is used by the driver/software. This third-party library requires a per-unit license. We distribute this on CD with the device and so by counting the CDs we can keep track of the licenses. We began including the library on the CD last year. But there are older owners of the device who would want to download the new version. We cannot put this installer on the web for download because we can’t count or track those licenses. So the problem is, we want to upgrade Component A with bug fixes and make it available for web download. But we can’t include component B for license reasons---because older users shouldn’t get it for free. But if I leave component B out of the upgrade, I believe the upgrade process will remove B from the hard disk of legitimate owners of it. (I know if I had at least made component B as a separate feature, I could specify that it not be removed and do a major upgrade. But it’s too late at this point.) My best workaround idea so far is for the upgrade to include dummy DLLs for component B that have a lower version number than the real ones. So when an upgrade happens, the real DLLs already on hard disk will be left alone. And for older users who don’t have the license to the library, they will just get the dummy DLLs installed. It’s messy, and I hate to think I have to do this for the life of the product. Is there a better way? I think for the future I will put component B completely in its own installer and put that only on the CD. But that doesn’t help the current problem. Thanks for any help, Jim -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to force uninstall before install
This is what I do (although I might be missing something since it's been a while since I had my head into this). This doesn't force users to manually uninstall, but rather it automatically uninstalls the previous version. So it may not be what you want. 1. Increment the installer version number. 2. Change your product code guid. This causes a major upgrade. Leave the upgrade code guid the same. 3. Add a section similar to this example: - Upgrade Id=8C4CC510-38A2-4747-95B1-D2C487D77093 UpgradeVersion Minimum=0.00. IncludeMinimum=yes Maximum=1.02.1004 IncludeMaximum=no OnlyDetect=no MigrateFeatures=yes IgnoreRemoveFailure=yes Property=OLDERVERSIONBEINGUPGRADED / /Upgrade The Upgrade Id= must match your upgrade code guid. For Maximum=, use the installer version number. I use WiX to install device drivers and I currently use DIFxApp . I usually do a major upgrade because DIFxApp doesn't seem to do minor upgrades correctly. (Actually, I used to do a better job of upgrades when I was using my own code in custom actions instead of DIFxApp.) Jim -Original Message- From: jo...@msli.com [mailto:jo...@msli.com] Sent: Friday, July 24, 2009 8:59 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] how to force uninstall before install I am going thought the process of making msi's for new versions of my software. I would like to force the user to uninstall before installing the new version, so I would like some install dialog to stop them there. Where can I find some info on doing this? CONFIDENTIALITY NOTICE: This electronic mail message and any attachment hereto may contain confidential information of Meyer Sound Laboratories, Incorporated and is intended for the personal and confidential use of the designated recipient(s) only. If you are not the intended recipient (or responsible for delivering the message to the intended recipient), you have received this message in error and any review, distribution, or copying of this message or any attachment hereto is prohibited. If you have received this message in error, please promptly notify the sender and permanently delete it from your computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] More languages done?
I noticed at the WiX Localization Project page that more languages seem to have been officially released. At least I noticed Italian, which I've been hoping for. That's great! But, any idea when these will show up in the release builds? Jim - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question on DIFxApp.msm, DIFXAppSample.msi ?
I've never tried using the toaster example, but I think the error message you're getting isn't telling you that the INF file is missing. It's telling you that some other file that the INF refers to is missing. This may be some file like tostrcls.dll or tostrco2.dll or whatever else is supposed to go with it. All driver files need to be in the same directory as the INF file. I currently use DIFxApp.msm with WiX. By the way, to avoid having to use Orca every time you build, you can add the MsiDriverPackages table in the WiX script with something like: CustomTable Id=MsiDriverPackages Column Id=Component Type=string Width=255 PrimaryKey=yes / Column Id=Flags Type=int Width=4 / Column Id=Sequence Nullable=yes Type=int Width=4 / Row Data Column=ComponentINFComponent/Data Data Column=Flags30/Data Data Column=Sequence / /Row /CustomTable ...where INFComponent is the component name of your INF file. - Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ar Sent: Tuesday, October 23, 2007 5:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question on DIFxApp.msm, DIFXAppSample.msi ? DIFXAppSample.msi is not able to install drivers properly. I am trying to develop an installer (*.msi) to install drivers application using DIFxApp.msm. (Toaster sample from WIN DDK) I can merge DIFXApp.msm into the package and can see an empty MsiDriverPackages custom table, MsiProcessDrivers, etc custom actions. Using Orca.exe, I add a record to the MsiDriverPackages custom table. From the log, I can say why it has failed. DIFXAPP: ERROR: One or more files referenced by 'C:\Program Files\Microsoft\DIFxAppSample\toastpkg.inf' cannot be found in the package. DIFXAPP: INFO: RETURN: DriverPackageInstallW (0xE303) DIFXAPP: ERROR encountered while installing driver package C:\Program Files\Microsoft\DIFxAppSample\toastpkg.inf But I can see the toastpkg.inf in C:\Program Files\Microsoft\DIFxAppSample\ From the log also, we can confirm that it is copying that file. Action 9:14:23: InstallFiles. Copying new files InstallFiles: File: toastpkg.inf, Directory: C:\Program Files\Microsoft\DIFxAppSample\, Size: 3228 InstallFiles: File: PlugAndPlay.cat, Directory: C:\Program Files\Microsoft\DIFxAppSample\, Size: 8695 I am searching for a solution to install the DIFXApp.msm sample from WIN DDK. If you are able to install the drivers using DIFXApp.msm, DIFXAppSample.msi from WIN DDK, Please let me the procedure. As I am trying this for the first time , I might be having a completely wrong understanding. I appreciate your help if you can point me in the right direction. Thanks, Anuradha. -- View this message in context: http://www.nabble.com/Question-on-DIFxApp.msm%2C-DIFXAppSample.msi---tf46811 53.html#a13376403 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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there any way to find out version of your .MSI file (installed)
Another way is to call the MsiGetProductInfo function. Pass the product code GUID as the first parameter (including the surrounding braces). Pass the string VersionString for the second parameter. Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of V K Gangwar Sent: Wednesday, September 26, 2007 10:24 PM To: John Lalande; wix-users@lists.sourceforge.net Subject: [WiX-users] Is there any way to find out version of your .MSI file (installed) Sorry, I think i didn't mention my question properly. Actually I wanted to know the version number of an already installed package. Thanks!! Veerendra John Lalande [EMAIL PROTECTED] wrote: Veerendra You could use Orca to open the MSI and look at the ProductVersion property in the Properties table. But I find it easier to author my packages so that the version is in the Explorer tool tip for the MSI file. The way I do this is to put the version in the Comments attribute of the Package tag. So that I don't have to update the comment every time I make a new version, I simply use the same pre-processor variable definition that I use elsewhere in my WiX source such as the Version attribute of the Product tag and the Upgrade entries. John Date: Wed, 26 Sep 2007 07:28:48 -0700 (PDT) From: V K Gangwar [EMAIL PROTECTED] Subject: [WiX-users] Is there any way to find out version of your .MSI file To: wix-users@lists.sourceforge.net Message-ID: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hello, Is there any method to find out the version number (major.minor.build) of our msi package. Thanks in advance. Regards, Veerendra _ Be a better Heartthrob. Get http://us.rd.yahoo.com/evt=48255/*http:/answers.yahoo.com/dir/_ylc=X3oDMTI5 MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNs awNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=listsid=396545433 better relationship answers from someone who knows. Yahoo! Answers - Check it out. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Trouble when linking to non-English languages
Thank, Bob. I will try that at some point. In the meantime I've just linked the .wxl language files (from http://www.tramontana.co.hu/wix/loc/index.php) explicitly using the -loc option and that seems to work. Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, September 19, 2007 8:55 PM To: Jim Hewes Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Trouble when linking to non-English languages Jim Hewes wrote: I'm using Wix version 3.0.2925.0 and the Mondo UI. I can link with the English culture fine. But when I link for German or Spanish I get over 260 errors such as: C:\delivery\Dev\wix\src\ext\uiextension\wixlib\ErrorDlg.wxs(10): error LGHT0102: The localization variable !(loc.WixUIYes) is unknown. Please ensure the variable is defined. You might want to try updating to a later version of WiX. I don't recall whether 2925 had all the loc strings in place. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Trouble when linking to non-English languages
I think this may turn out to be one of those dumb problems. I'd swear I had my Wix project working fine before I went on vacation; now I'm back and it seems to be broken and I can't see what the problem is. I'm using Wix version 3.0.2925.0 and the Mondo UI. I can link with the English culture fine. But when I link for German or Spanish I get over 260 errors such as: C:\delivery\Dev\wix\src\ext\uiextension\wixlib\ErrorDlg.wxs(10): error LGHT0102: The localization variable !(loc.WixUIYes) is unknown. Please ensure the variable is defined. I know this can happen when you don't specify the -cultures option. But my link line looks like this: Light.exe -cultures:de-de -dWixUILicenseRtf=EULA German.rtf -ext WixUIExtension -out D:\MyInstaller1031.msi D:\MyInstaller.wixobj If I change the culture to en-us it works fine. Also, I have the following line in my .wxs file: UIRef Id=WixUI_Mondo / As far as I know, German and Spanish should already be built into the WixUIExtension. So as long as I specify the -cultures:de-de it should work. I must be doing something wrong somewhere else but I can't find it. I tried reinstalling Wix to no avail. What else can cause this to happen? Jim - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Building a setup.exe
I had seen one product that used DemoShield and I knew that DemoShield was no longer available. But I hadn't found that Installsite link you gave. Thanks Friedrich! Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Friedrich Brunzema Sent: Saturday, July 28, 2007 5:45 AM To: WixUsers Subject: [WiX-users] Building a setup.exe Hi Jim, it would seem that you are talking about a CD-browser-like functionality. In the past we have used DemoShield (no longer available) from Installshield to do this. There are a couple of freeware/shareware ones available, a good list is shown on installsite.com [http://installsite.org/pages/en/tt_cdbrowse.htm]. In the past, I have written a launcher in c++ to do prerequisite installs -- the important thing to watch out for these kinds of tools is the prerequisites that must exist on the machine before your launcher starts. You have to assume that the machine you are inserting the CD into has just been installed and has no .NET framework (if XP), no service packs, no updated C++ runtime, not visual basic runtime etc. Be sure to test on a new, virgin OS installation either on a Virtual box or on a real one. Testing this sort of stuff with a Virtualization environment (especially VMWare, where you can do a whole bunch of stuff, and then just not commit, but revert back to the original), is a real timesaver. Hope this helps, Friedrich Brunzema _ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the http://us.rd.yahoo.com/evt=40705/*http:/mrd.mail.yahoo.com/try_beta?.intl=c a All-new Yahoo! Mail - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Building a setup.exe
Thanks for the info. I appreciate all the work you guys do on WiX. I'm a install novice, but it seems to me that some of the stuff the bootstrapper has to worry about should probably be done by Windows Installer. For example, I was surprised to discover that it's part of the bootstrapper's duty to detect if the current installation is an upgrade and which type of upgrade it is in order to specify the REINSTALLMODE property to the msi. If only I could sleep less. smile/ If you're going to work that many hours, you might as well be a game developer and have fun. :) Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, July 27, 2007 1:21 AM To: Jim Hewes; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Building a setup.exe I'm slowly making progress on a new tool for the WiX toolset called burn (see: http://robmensching.com/blog/archive/2007/04/10/WiX-v3-Roadmap-Draft.aspx). It is a generic bootstrapper that will eventually handle the things you list below. It's slow going and not really anything in a state to share yet. If only I could sleep less. smile/ Anyway, that's where I'm moving towards. The existing setupexe project is as limited as you point out. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Hewes Sent: Thursday, July 26, 2007 1:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Building a setup.exe I've been working on building an installer using Wix. Building an msi seems to work well and I have no major problem. But where I'm getting bogged down is in the things surrounding it, such as the setup.exe program. I have a couple of questions. 1. I've noticed the setupbld.exe utility and I've tried it. It seems to create a setup.exe with all files packed into a single EXE, which are then extracted at runtime. That's good. But in addition to that, I also need a setup.exe that will launch loose, uncompressed files for installation from a CD. Can it currently do that as well? 2. This isn't so much a question as a feature request. I need for to the setup.exe to show a language selection dialog to allow the user to select an installation language (like Installshield does). I think I will probably try to add it myself to the setupexe project if it never gets added by the Wix guys. 3. I read about chaining as a way of handling more than one installation. I currently have this requirement, since I need to install a driver and also an application that works with the product. For various reasons, it's better for us not to package these in the same installer. But chaining doesn't seem like an ideal solution either---I think that automatically launching one installer after another can be confusing to the end user. I think a better solution, at least for CD installation, is to begin with a menu. The menu allows the user to choose what to install; that is, which installer to run. The menu can list the device installer and the application installer. It can also allow users to optionally install things like Adobe Reader if your documentation is in PDF form. I've seen some products that do this and they have graphically pretty menu programs. Unfortunately, in doing a search, I didn't find any decent existing software for developing such a menu program. Can anyone recommend something? Sure, perhaps it's really just a dialog with buttons, so you can probably write one yourself (I'm a C++ programmer). But I was hoping to find something that included some pre-designed fancy graphics, and allowed you to slap together a menu launcher in an hour or so with no programming. Does this make sense? Or am I thinking in the wrong direction? Although I like the feeling of working close to the metal with Wix as compared to some commercial product like InstallShield, I also seem to be getting slowed by the setup.exe issues outside of the actual msi more than anything. Thanks for any comments. Jim - 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] Building a setup.exe
I've been working on building an installer using Wix. Building an msi seems to work well and I have no major problem. But where I'm getting bogged down is in the things surrounding it, such as the setup.exe program. I have a couple of questions. 1. I've noticed the setupbld.exe utility and I've tried it. It seems to create a setup.exe with all files packed into a single EXE, which are then extracted at runtime. That's good. But in addition to that, I also need a setup.exe that will launch loose, uncompressed files for installation from a CD. Can it currently do that as well? 2. This isn't so much a question as a feature request. I need for to the setup.exe to show a language selection dialog to allow the user to select an installation language (like Installshield does). I think I will probably try to add it myself to the setupexe project if it never gets added by the Wix guys. 3. I read about chaining as a way of handling more than one installation. I currently have this requirement, since I need to install a driver and also an application that works with the product. For various reasons, it's better for us not to package these in the same installer. But chaining doesn't seem like an ideal solution either---I think that automatically launching one installer after another can be confusing to the end user. I think a better solution, at least for CD installation, is to begin with a menu. The menu allows the user to choose what to install; that is, which installer to run. The menu can list the device installer and the application installer. It can also allow users to optionally install things like Adobe Reader if your documentation is in PDF form. I've seen some products that do this and they have graphically pretty menu programs. Unfortunately, in doing a search, I didn't find any decent existing software for developing such a menu program. Can anyone recommend something? Sure, perhaps it's really just a dialog with buttons, so you can probably write one yourself (I'm a C++ programmer). But I was hoping to find something that included some pre-designed fancy graphics, and allowed you to slap together a menu launcher in an hour or so with no programming. Does this make sense? Or am I thinking in the wrong direction? Although I like the feeling of working close to the metal with Wix as compared to some commercial product like InstallShield, I also seem to be getting slowed by the setup.exe issues outside of the actual msi more than anything. Thanks for any comments. Jim - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Extra localization files
I have the same question, since I need French and Italian. I've been watching the status of French for a long time and it's been at finished for as long as I can remember. Presumably it only needs a signature to go from finished to released. I wonder what can be done to nudge that process. For Italian, I think I may be able to get my company to have that one done. It's the only thing preventing us from using WiX. I guess I'm a little surprised that more people don't need multiple languages so much. Or maybe they have them translated on their own, I don't know. Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Robertson Sent: Sunday, February 04, 2007 11:57 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Extra localization files The list of Wix localizations has a fairly large number that are listed as complete and that presumably should then be available with the Wix project files. But they don't seem to be there, only English, Dutch, German and Spanish? Are the other files available elsewhere? Specifically I'm looking for French, Finnish and Norwegian versions. Thanks in advance for any pointers. -- View this message in context: http://www.nabble.com/Extra-localization-files-tf3171079.html#a8796569 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 - 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
Re: [WiX-users] Question about additional translations
Thanks for the reply. I probably should have mentioned that I had seen the localization project web page. I noticed that French has been finished for a while. Anyway, I'll do what I can. (Sorry, if this gets sent twice. I always get some sort of error the first time I send...something about my domain not having a postmaster address. Then it seems to work on the following try.) Jim - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
