[WiX-users] LGHT0204 : ICE64: The directory is in the user profile but is not listed in the RemoveFile table.
Hello WiX Community, I hope you can help us with an error message we do not understand. J Scenario: * We want to create the empty folder %AppData%\X\Y. Current solution: Directory Id=AppDataFolder Directory Id=X Name=X Directory Id=Y Name=Y / /Directory /Directory DirectoryRef Id=Y Component Id=Z Guid=... !-- Light wants to have HKCU registry key as KeyPath for directories in user's profile. -- RegistryValue Root=HKCU Key=Software\MyCompany\[ProductName] Name=_default Value= Type=string KeyPath=yes / !-- We only want to get an empty folder but not any files in it. -- CreateFolder / /Component /DirectoryRef Problem: * When building the MSI, we get the following error messages which we do not understand: error LGHT0204 : ICE64: The directory Y is in the user profile but is not listed in the RemoveFile table. error LGHT0204 : ICE64: The directory X is in the user profile but is not listed in the RemoveFile table. We would be really glad if anybody could tell us what to do! J Thanks! -Markus -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] when can we expect Wix 3.5 RTM?
I don't have write access to the web page and I don't think that it makes sense to open a tracked issue for that. -Original Message- From: Jeremy Farrell [mailto:jfarr...@pillardata.com] Sent: Donnerstag, 15. April 2010 23:25 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] when can we expect Wix 3.5 RTM? If people can't be bothered to read the last day or two of the mailing list, or to search the mailing list archives, I'm not convinced that repeating the information elsewhere will have much value - it just gives them somewhere else to not bother looking. On the other hand, your suggestion can't do any harm; feel free to contribute the change. -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, April 15, 2010 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] when can we expect Wix 3.5 RTM? If it is really so frequently asked, maybe it would be a good idea to post the date in the WiX FAQ http://wix.sourceforge.net/faq.html or on the WiX web site's front page http://wix.sourceforge.net/ to prevent dumb people like me asking silly questions like this over and over again? ;-) -Original Message- From: Jeremy Farrell [mailto:jfarr...@pillardata.com] Sent: Dienstag, 13. April 2010 17:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] when can we expect Wix 3.5 RTM? I'll be surprised if the date has moved much since this question was answered yesterday, or even since the several times it and similar questions have been answered in recent weeks. From: MYFLEX [mailto:shrinuen...@gmail.com] Sent: Tuesday, April 13, 2010 5:41 AM when can we expect Wix 3.5 RTM? Is it ok to use Wix 3.5 beta versions to build my setups? -- - --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] when can we expect Wix 3.5 RTM?
If it is really so frequently asked, maybe it would be a good idea to post the date in the WiX FAQ http://wix.sourceforge.net/faq.html or on the WiX web site's front page http://wix.sourceforge.net/ to prevent dumb people like me asking silly questions like this over and over again? ;-) -Original Message- From: Jeremy Farrell [mailto:jfarr...@pillardata.com] Sent: Dienstag, 13. April 2010 17:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] when can we expect Wix 3.5 RTM? I'll be surprised if the date has moved much since this question was answered yesterday, or even since the several times it and similar questions have been answered in recent weeks. From: MYFLEX [mailto:shrinuen...@gmail.com] Sent: Tuesday, April 13, 2010 5:41 AM when can we expect Wix 3.5 RTM? Is it ok to use Wix 3.5 beta versions to build my setups? --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Searching for existing files but only once
Again, it seems you misunderstood my intention due to your personal experience with lazy people etc. Sorry that I don't match your pattern here and actually am not lazy but just wanted to get help with the problem described (from my point of view) actually clearly in the subject line. If you expect everybody to be a MSI + WiX master, then on that background it should be clear what this subject line targets in. Anyways, if you think it was my fault, ok, let's assume it was my fault and now let's stick with it. I will try to more explicitly tell what my actual problem is next time. Have no time for more lenghty emails like that one, as *my* manager wants me to make my time *just* get that single job done (will never have to write more setups in the next months) and *not* to become MSI or WiX experts, since it is just more efficient to *ask* these experts for help (maybe there is an expert willing to make some dollars with asking our silly questions?). We're JAVA experts and just have to use MSI for this single project. But let's stop this thread now. Regars Markus -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Dienstag, 13. April 2010 18:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Searching for existing files but only once -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Saturday, April 10, 2010 7:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Searching for existing files but only once I assure you, all of us were beginners once.g And, of course, learning WiX is almost trivial; it's MSI that's hard. That's not true in one point: WiX comes with lots of stuff that has nothing to do with MSI. See the extensions. Maybe somebody write a brilliant custom task that does what we need, but he did not contribute it but just put it somewhere in some foreign place. How should we learn about that without asking? And where to ask if not here? I mean, we did *not* ask How to solve that with 100% pure MSI?. We described just our problem: We want to have a DirectoryScan run only once. but we do not want to write it completely from scratch. It is a valid solution (and [Castro, Edwin (Hillsboro)] And the explicit answer to your question is You can't do that. If you want a DirectoryScan that runs only once *you* need to build it yourself. Did you find the wix-contrib project in your research? How about the msiext project? There are very few projects out there were sharing custom actions (the MSI way of doing non-MSI things) with the rest of the world. One of them happens to be the WiX project. I can only think of two others and I've seen references to both of them in the mailing list in the past. The problem with your question is but we do not want to write it completely from scratch. You _know_ you need a custom action to achieve your goal because you understand how RegistrySearch and FileSearch, etc, work. They execute on every run. Your question should reflect that you understand already how MSI works and that WiX does not have a standard custom action to do the work for you. It would be nice to show that you've looked at the other two projects that intend to provide open source custom actions, wix-contrib and msiext, and didn't find a custom action that does what you'd like. It would be nice to show to us that you are look for somebody to share their custom action code with you in some way. As far as I could tell none of this information was given unless somebody requested it. Sadly, it's becoming more common: Even theoretically smart people who understand foundations want to put some work like setup in the it shouldn't be hard, so therefore it isn't hard bucket and avoid planning it or even considering it might require some engineering effort. On the other hand, as a project manager, I'd love it more if people get solutions quickly by asking others instead of spending weeks with trying things others already proven to be impossible or inefficient. Ain't it part of the idea of a forum to share experience? Won't you like to just download a sample code from us when starting with a technology we have lots of experience with and you have not, just to reduce time to understand Chapter X from one week to five minutes? At least my managing director will kick my ass if he learns that my coders are spending time with weird experiments if there is someone out there having the answer in the pocket, but we just didn't dare to ask because we want to prevent senseless discussion like this one... [Castro, Edwin (Hillsboro)] If I was a manager I would fire any employee that didn't show an aptitude for learning. With a field that changes as quickly as this one does (seems like everything is obsolete the day before it launched) I would expect
Re: [WiX-users] Searching for existing files but only once
but not _just_ because of this particular case. Ok. Hopefully, the fires won't heat up any further. And hopefully we'll all ask better questions and we'll all respond with more questions. RTFM? Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, April 09, 2010 6:52 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Searching for existing files but only once Everyone on this list with the exception of Rob M, Bob A the rest of the core WiX dev team was a beginner with WiX at one time. However a large number of people (myself included) took it upon themselves to learn about the tools they're trying to use. Most of us would've done that by going through the tutorials, reading the WiX documentation, reading MSDN pages for Windows Installer, looking up blog pages for Windows Installer etc. (see www.google.com) then actually trying to do things for ourselves by creating installers testing them. As I've said before on this list would you try to build executables DLL's in C++ without having any knowledge of CRT/ATL/MFC/.NET (delete where appropriate)? General discussion for Windows Installer XML toolset doesn't mean e-mail here to ask for help on every little issue you get stuck on without trying to figure it out for yourself. Maybe I'm being too harsh on yourself but there's a lot of people posting questions on here which can be answered by a single line reply containing a URL to either the WiX tutorial, WiX documentation or an MSDN page for Windows Installer. What's even worse is some people appear to not even read the links they're directed to ask another question which would be answered if they took the time to look over the page they've been pointed at. None of us, not even the core WiX dev team get paid for working on WiX or for helping people by replying to queries on this list yet there are people treating it like a subscription based support service for a commercially bought software package. I guess this is a symptom of the growing popularity of WiX but there's no reason why anyone should be happy with that. Maybe I'm just too used to non-Windows based communities for free software where people will take the time to try find the solution themselves seeing discussion forums as a last resort when all else fails not the first place to go when you hit a bump in the road. You're not going to learn anything if we tell you the solution to everything but I get the impression most people asking questions aren't bothered about learning how to fix it themselves, they just want to be handed a solution to get their installers building so they can ship their products, get a pat on the back from the management for all their hard work cash their pay checks. Great in the short term but when the next release comes along lo behold the queries start again in earnest. On a side note, a lot of people say How do I do this in WiX? when the question should be Does Windows Installer support this? WiX is not Windows Installer. Time to take another long rest from replying to list queries I guess. Have fun everyone. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 09 April 2010 13:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Searching for existing files but only once Any chance you might start thinking for yourself sometime soon? Actually I do not understand why writing this. We are beginners with MSI and WiX and have no clue what is there for free out of the box, and what must be done with special tasks. Possibly there would be something that can prevent actions to run if a property is set? How should we know without asking? We spent two days and did not find something, so we asked that question. If you don't like answering them, why did you answer at all? We know pretty well how to use conditions and all that, we just wanted to know whether there is a trick now mentioned in the manuals, not more. How should we find out that by self-thinking? If this would be possible, this newsgroup would be obsolete. - -- - -- Download Intel#174
Re: [WiX-users] Searching for existing files but only once
I assure you, all of us were beginners once.g And, of course, learning WiX is almost trivial; it's MSI that's hard. That's not true in one point: WiX comes with lots of stuff that has nothing to do with MSI. See the extensions. Maybe somebody write a brilliant custom task that does what we need, but he did not contribute it but just put it somewhere in some foreign place. How should we learn about that without asking? And where to ask if not here? I mean, we did *not* ask How to solve that with 100% pure MSI?. We described just our problem: We want to have a DirectoryScan run only once. but we do not want to write it completely from scratch. It is a valid solution (and what we hoped to find) that someone says: Guys, download this five VB lines from my personal web site! or Guys, there is a bug in the docs, you can add a constraint to prevent this. Both obviously cannot be learned without asking the question as simple as we did. Everything else would constrain in a way that we don't want to constrain. Sadly, it's becoming more common: Even theoretically smart people who understand foundations want to put some work like setup in the it shouldn't be hard, so therefore it isn't hard bucket and avoid planning it or even considering it might require some engineering effort. On the other hand, as a project manager, I'd love it more if people get solutions quickly by asking others instead of spending weeks with trying things others already proven to be impossible or inefficient. Ain't it part of the idea of a forum to share experience? Won't you like to just download a sample code from us when starting with a technology we have lots of experience with and you have not, just to reduce time to understand Chapter X from one week to five minutes? At least my managing director will kick my ass if he learns that my coders are spending time with weird experiments if there is someone out there having the answer in the pocket, but we just didn't dare to ask because we want to prevent senseless discussion like this one... Regards Markus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ProductVersion / Small Updates
AFAIK for a small update (not minor upgrade) the version number of a product must not change. The problem is: How to identify which version (the original or the patched one) is installed now? Maybe I misunderstood the contraint about version numbers, so I *may* change the ProductVersion, but I *must not* modify major.minor but only the postfixed fraction (major.minor.x.y)? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut is not using specified icon
Rather weird, but I'll have to accept it -- Microsoft makes the rules. ;-) Strange but true, it still is not working: I have now used NOTEPAD.exe as source file (which obviously is in the right format and contains only a single icon) and named the icon as .exe by using Icon id=my.exe SourceFile=C:\WINDOWS\NOTEPAD.exe. After installation, the short cut shows the icon found in the linked EXE, not the icon of NOTEPAD! But when I then click on select different icon then it shows the notepad icon as the default selection. I'm totally confused. Seems uninstall and reinstall does not update the explorer's icon cache...? -Original Message- From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com] Sent: Donnerstag, 8. April 2010 20:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Shortcut is not using specified icon Hi Markus, The Source (http://msdn.microsoft.com/en-us/library/aa369210) is saying: Icon files that are associated strictly with file name extensions or CLSIDs can have any extension, such as .ico. However, Icon files that are associated with shortcuts must be in the EXE binary format and must be named such that their extension matches the extension of the target. The shortcut will not work if this rule is not followed. For example, if a shortcut is to point to a resource having the key file Red.bar, then the icon file must also have the extension .bar. Multiple icons can be stuffed into the same icon file as long as all of the target files have the same extension. So, to fix that: Icon Id=MyIcon.exe SourceFile=pointer to exe file/ Shortcut Icon=MyIcon.exe ... / Regards, Alex -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, April 08, 2010 4:34 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Shortcut is not using specified icon I have a strange problem. Following the directions in the WiX manual, I added a ShortCut which is working well. Now I added a icon, but the shortcut is not using it - it still uses the icon of the EXE! The installation is per machine. Icon Id=my.ico SourceFile=..\foo\my.ico / Component Id=Shortcut Guid=... RegistryValue Root=HKCU Key=Software\X\[ProductName] Name=Shortcut Value= Type=string KeyPath=yes / Shortcut Id=Menu Directory=MenuDir Name=!(loc.ShortcutName) WorkingDirectory=INSTALLDIR Target=[INSTALLDIR]my.exe Icon=my.ico Advertise=no / /Component Any ideas? --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Searching for existing files but only once
Any chance you might start thinking for yourself sometime soon? Actually I do not understand why writing this. We are beginners with MSI and WiX and have no clue what is there for free out of the box, and what must be done with special tasks. Possibly there would be something that can prevent actions to run if a property is set? How should we know without asking? We spent two days and did not find something, so we asked that question. If you don't like answering them, why did you answer at all? We know pretty well how to use conditions and all that, we just wanted to know whether there is a trick now mentioned in the manuals, not more. How should we find out that by self-thinking? If this would be possible, this newsgroup would be obsolete. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ProductVersion / Small Updates
The question is, whether this holds true for Small Updates, since Microsoft writes that ProductVersion must not be modified. So is it a valid assumption (that holds true forever and not just by incident is at the moment so) that the ignoring described in the link you posted also is in place for Small Updates? -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Freitag, 9. April 2010 11:59 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ProductVersion / Small Updates Windows Installer only uses the first 3 fields of version numbers so you can change the 4th one as much as you'd like. See - http://msdn.microsoft.com/en-us/library/aa370859.aspx Personally I stay away from Small Updates for this reason. Minor upgrades work just as well with no ambiguity. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 09 April 2010 09:11 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] ProductVersion / Small Updates AFAIK for a small update (not minor upgrade) the version number of a product must not change. The problem is: How to identify which version (the original or the patched one) is installed now? Maybe I misunderstood the contraint about version numbers, so I *may* change the ProductVersion, but I *must not* modify major.minor but only the postfixed fraction (major.minor.x.y)? --- - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS
...@iesve.com] Sent: Thursday, March 25, 2010 5:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS MSI's themselves are built for either x86 or x64 platforms (or Intel64 aka Itanium but they're so rare it's not worth mentioning). Build your MSI for x86 as you normally do if a user tries to install it on an x64 system msiexec/WoW will take care of it. Ignore everything Harshil says, you don't need an x64 machine to build an x86 MSI which works on both x86 x64 Windows installations. MSI's DLL's are separate issues. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: 25 March 2010 11:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Well it is obvious that msi created on 32-bit machine has no knowledge of 64-bit environment and if u wont to provide support to both 64-bit and 32-bit OS, its required man...sorry.. you can try with it.. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:59 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS But that's weird -- it would mean that it is impossible to install a MSI on a 64 Bit machine that was created in times when there was no 64 Bit around already... -- or that all software vendors in the past obtained 64 Bit machines just to create their 32 Bit MSIs THERE!? Can't believe that. -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Well you have to do it on 64-bit machine only then and then only msi will be fully 64-bit\32-bit compatible. I already encounter this issue in past and had to get 64-bit OS just to solve this issue. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS But we do not own a 64 Bit machine, so how to do it on a 32 Bit machine? -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Just create your MSI on 64-bit machine with the DLLs created as target x86, and it will run on both 32-bit\64-bit machine. 64-bit OS will automatically take care of system folder. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Beginner's Question: 32 Bit MSI on 64 Bit OS Dear WiX Community, we need to write a MSI file that has to install a 32 Bit software. It shall correctly install on both, Windows 32 and Windows 64. Is it correct to do one setup that always installs into SystemFolder, or do we have to take any special care for the Windows 64 case? Thanks Markus --- - - -- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- - - -- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists
Re: [WiX-users] Searching for existing files but only once
General discussion for Windows Installer XML toolset doesn't mean e-mail here to ask for help on every little issue you get stuck on without trying to figure it out for yourself. Maybe I'm being too harsh on yourself but there's a lot of people posting questions on here which can be answered by a single line reply containing a URL to either the WiX tutorial, WiX documentation or an MSDN page for Windows Installer. What's even worse is some people appear to not even read the links they're directed to ask another question which would be answered if they took the time to look over the page they've been pointed at. Sorry, but you completely missed the point with our question. We are open source committers on our own and are very active on several other newsgroups in the Java area. We invested four weeks so far on learning about WiX and MSI, we have read the MSI documentation two times, we two times follows the brilliant tutorial, we have read lots of links at MSDN and other places. We just did not found a solution to the question how to prevent that the disk scan is performed *every* time and hoped that some guru found a solution to prevent us from spending lots of more days just to detect that there is no solution. If the idea of participating of an already worked-out solution found by some other user in front of this background does not qualify us for asking this particular question, then I actually do not understand what types of question are actually allowed to get asked in this forum at all. I always had the impression that everybody on this newsgroup was very helpful and friendly and lots of our problems acually had been solved by some kind guys understanding that not everybody wants to invest more weeks just to find out what others can tell in one minute, and we always had been very thankful for that and always told that on this list so far. But today some of these friendly and helpful guys seems to have forgotten to take his pills or what a forum actually is good for: To talk. What else did we do? If you don't know the solution or don't like to provide it, no problem, we respect this. But we dislike being told to start thinking after investing weeks. Seems you got up on the wrong side this morning. Regards Markus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Support Phone Number
We'd like to provide a support phone number in our WiX-generated .msi in a way that this phone number is visible to the end user when looking at Support Details in the Software Control Panel of Windows. How to do that? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Support Phone Number
Thanks! It works pretty well! :-) -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Donnerstag, 8. April 2010 11:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Support Phone Number http://msdn.microsoft.com/en-us/library/aa367588.aspx Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 08 April 2010 09:49 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Support Phone Number We'd like to provide a support phone number in our WiX-generated .msi in a way that this phone number is visible to the end user when looking at Support Details in the Software Control Panel of Windows. How to do that? --- - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Shortcut is not using specified icon
I have a strange problem. Following the directions in the WiX manual, I added a ShortCut which is working well. Now I added a icon, but the shortcut is not using it - it still uses the icon of the EXE! The installation is per machine. Icon Id=my.ico SourceFile=..\foo\my.ico / Component Id=Shortcut Guid=... RegistryValue Root=HKCU Key=Software\X\[ProductName] Name=Shortcut Value= Type=string KeyPath=yes / Shortcut Id=Menu Directory=MenuDir Name=!(loc.ShortcutName) WorkingDirectory=INSTALLDIR Target=[INSTALLDIR]my.exe Icon=my.ico Advertise=no / /Component Any ideas? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Searching for existing files but only once
We need to upgrade a preinstalled software. That software is very old and knows nothing of MSI, Registry etc. We actually have to search all local drives for the old EXE file and remove the surrounding folder. As this is a time consuming task, this shall only happen if this is really an update of that old version but not if this is an update / upgrade / patch of a previous new MSI setup. I hope it is clear what I like to tell. We have no clue how to do that... Can anybody paste a short code snippet describing an idea how this could be done? Thanks! Markus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Cannot start any WiX 3.0 tool
I've set up a clean windows XP machine, installed MSVB5 on it, and WiX 3.0. I can use MSVB5 to create the EXEs which in a second step shall get packed into a MSI by WiX. But when I start any WiX tool (like CANDLE or HEAT) it tells me that it cannot initialize the tool. Maybe I have to install .NET to run WiX? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cannot start any WiX 3.0 tool
Thank you for this information! I installed .NET 2.0 and now everything works well. I wonder why that is not mentioned in the WiX 3.0 docs? -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Mittwoch, 7. April 2010 11:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Cannot start any WiX 3.0 tool A quick check in dependency walker (http://www.dependencywalker.com/) of any of the WiX v3.0.5419.0 binaries shows them needing mscoree.dll version 2.0.50727.x so yes you need the .NET 2.0 Framework installed. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 07 April 2010 10:16 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Cannot start any WiX 3.0 tool I've set up a clean windows XP machine, installed MSVB5 on it, and WiX 3.0. I can use MSVB5 to create the EXEs which in a second step shall get packed into a MSI by WiX. But when I start any WiX tool (like CANDLE or HEAT) it tells me that it cannot initialize the tool. Maybe I have to install .NET to run WiX? --- - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to check if JRE is installed using WIX
There is no generic solution to detect any JRE. What you did below should work with Sun's. -Original Message- From: ppremk [mailto:prem.kumar.ponutho...@exact.com] Sent: Sonntag, 4. April 2010 08:29 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to check if JRE is installed using WIX Hi, I am doing this for my package, not sure if this is the correct way, but might be of help: Property Id=JREINSTALLED RegistrySearch Key=SOFTWARE\JavaSoft\Java Runtime Environment Root=HKLM Type=raw Id=JREINSTALLED_REGSEARCH Name=CurrentVersion / /Property Condition Message=Java Runtime Environment is not installed. (JREINSTALLED) /Condition there might be better ways to achieve this but this works for my package and alerts users cheers -- View this message in context: http://n2.nabble.com/How-to-check-if-JRE- is-installed-using-WIX-tp4837649p4849482.html Sent from the wix-users mailing list archive at Nabble.com. --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.0: Bug in LIGHT
The original error message is: error LGHT0130 : The primary key 'regA2E5343F2EC34F3CCC232B9D03BB2A85' is duplicated in table 'Registry'. Please remove one of the entries or rename a part of the primary key to avoid the collision. I expect that this key is generated internally by LIGHT, since the .wxs file does not include it. Regards Markus -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Donnerstag, 1. April 2010 02:26 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX 3.0: Bug in LIGHT On 3/31/2010 8:55 AM, Markus Karg wrote: tried to link it using LIGHT. LIGHT says that there is a duplicate in that fragment, so we checked the fragment. In fact, there is no duplicate: What's the exact error message? -- sig://boB http://joyofsetup.com/ --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent deinstallation
We have to write a .msi to install modules into a preinstalled software. The problem is that once the module is installed, it can never get uninstalled, as it modifies some software-internal structures in a way that makes it impossible to undo. So, we have to prevent that somebody goes into the system control panel, selects the module, and presses uninstall. Can we do that using WiX? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.0: Bug in LIGHT
Thank you for posting the URL. Yes, we are suffering exactly from that bug, and the proposed solution is working. :-) BTW, I actually do not understand why the *unversioned* variant has to be *inside* the versioned one? I would understand if the semantics would be exchanged (There shall be a registry entry, and in particular, there shall be a versioned one.), but I don't get the idea of the actual encapsulation (There shall be a versioned registry entry, and hey, also there shall be an unversioned one.?! Regards Markus -Original Message- From: Ondrej Zarevucky [mailto:ondrej.zarevu...@fine.cz] Sent: Donnerstag, 1. April 2010 10:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX 3.0: Bug in LIGHT Hi Markus, I had the same problem with one of our COM objects. I'm was told there problem in our COM object registration and I fixed it by moving the version independent class entry under the version dependent one using our custom built WiX post processing tool: ProgId Id=FRFEMesh2D.FEMeshGen2DGenerator.1 Description=FEMeshGen2DGenerator Class ProgId Id=FRFEMesh2D.FEMeshGen2DGenerator Description=FEMeshGen2DGenerator Class / /ProgId More about this issue can be found in this bug report: http://sourceforge.net/tracker/index.php?func=detailaid=2793966group_ id=105970atid=642714 http://sourceforge.net/tracker/index.php?func=detailaid=2793966group _id=105970atid=642714 I hope it helps a bit Ondřej Zarevúcky On 1.4.2010 8:21, Markus Karg wrote: The original error message is: error LGHT0130 : The primary key 'regA2E5343F2EC34F3CCC232B9D03BB2A85' is duplicated in table 'Registry'. Please remove one of the entries or rename a part of the primary key to avoid the collision. I expect that this key is generated internally by LIGHT, since the .wxs file does not include it. Regards Markus -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Donnerstag, 1. April 2010 02:26 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX 3.0: Bug in LIGHT On 3/31/2010 8:55 AM, Markus Karg wrote: tried to link it using LIGHT. LIGHT says that there is a duplicate in that fragment, so we checked the fragment. In fact, there is no duplicate: What's the exact error message? -- sig://boB http://joyofsetup.com/ - -- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent deinstallation
Yes, but on modules no major updates will happen -- due to the technological solution, the major upgrade will replace the main product completele, including all modules. So the idea of having modules as .msp is actually fascinating us, as it would solve this issue, too. -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: Donnerstag, 1. April 2010 11:52 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent deinstallation Are you aware that disabling installs will prevent major upgrades? Rob On 01/04/2010 10:29, Markus Karg wrote: We have to write a .msi to install modules into a preinstalled software. The problem is that once the module is installed, it can never get uninstalled, as it modifies some software-internal structures in a way that makes it impossible to undo. So, we have to prevent that somebody goes into the system control panel, selects the module, and presses uninstall. Can we do that using WiX? - - Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX 3.0: Bug in LIGHT
We noticed that there must be a bug in LIGHT (WiX 3.0):
We used
HEAT file my.ocx -out my.wxs
to create a Fragment from an OCX file, compiled it using CANDLE, then
tried to link it using LIGHT. LIGHT says that there is a duplicate in
that fragment, so we checked the fragment. In fact, there is no
duplicate:
Class Id={EF600D71-358F-11D1-8FD4-00AA00BD091C}
Context=InprocServer32 Description=Annotation Objects
ThreadingModel=both
ProgId Id=AnnotationX.AnnList Description=Annotation Objects
/
ProgId Id=AnnotationX.AnnList.1 Description=Annotation
Objects /
/Class
In fact, we can link it, if we remove one of that ProgId entries
(actually it plays no role which one). It seems as if LIGHT makes no
difference between AnnotationX.AnnList and AnnotationX.AnnList.1,
which is wrong, since obviously that are different entries.
What to do?
Thanks
Markus
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX 3.5: Error in HEAT
We're using HEAT to create Fragments from files: CD %PROGRAMFILES%\Windows Installer XML v3\bin HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs That works pretty well as long as HEAT and EXCEL8.OLB are located in the same folder. But if they are not, both of the following commands will fail: CD C:\ %PROGRAMFILES%\bin\HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs or CD %PROGRAMFILES%\Windows Installer XML v3\bin HEAT file C:\EXCEL8.OLB -gg -out EXCEL8.wxs The result is always the same: heat.exe : error HEAT0001 : The Value must not be NULL. Parameter name: path Exception Type: System.ArgumentNullException Stack Trace: bei System.IO.Path.GetFullPathInternal(String path) bei System.IO.Path.GetFullPath(String path) bei Microsoft.Tools.WindowsInstallerXml.HarvesterCore.ResolveFilePath(String fileSource) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teFile(IParentElement parentElement, File file) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teElement(IParentElement parentElement, ISchemaElement element) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teElement(IParentElement parentElement, ISchemaElement element) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teElement(IParentElement parentElement, ISchemaElement element) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teElement(IParentElement parentElement, ISchemaElement element) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teElement(IParentElement parentElement, ISchemaElement element) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta teElement(IParentElement parentElement, ISchemaElement element) bei Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta te(Wix wix) bei Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix) bei Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: Registering OCX
Thank you for this explanation. To make the solution easier to find for others possibly having the same problem, here is what to do: HEAT.exe file my.ocx -out my.wxs That will create a file my.wxs containing the necessary WiX commands to register the OCX. Compile it and then link it with the rest of our installer. I wonder why this simple instruction is not found in the manual or tutorial. ;-) Regards Markus -Original Message- From: DEÁK JAHN, Gábor [mailto:d...@tramontana.co.hu] Sent: Montag, 29. März 2010 16:57 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Beginner's Question: Registering OCX On Mon, 29 Mar 2010 16:15:02 +0200, Markus Karg wrote: Markus, That page does not contain the word OCX, so what do you like to tell me? But it does mention the word file and OCX (a DLL, actually) is a file type that Heat can harvest. So just follow the description of how to extract information from an OCX DLL as a file, Heat will generate the appropriate WiX source for you. Bye, Gábor --- Gábor DEÁK JAHN -- Budapest, Hungary E-mail: d...@tramontana.co.hu --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: Registering OCX
Great! Thanks a lot! :-) -Original Message- From: DEÁK JAHN, Gábor [mailto:d...@tramontana.co.hu] Sent: Dienstag, 30. März 2010 11:27 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Beginner's Question: Registering OCX On Tue, 30 Mar 2010 08:21:05 +0200, Markus Karg wrote: Markus, I wonder why this simple instruction is not found in the manual or tutorial. ;-) http://www.tramontana.co.hu/wix/lesson6.php#6.1 ;-) Bye, Gábor --- Gábor DEÁK JAHN -- Budapest, Hungary E-mail: d...@tramontana.co.hu --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Beginner's Question: Registering OCX
We need to register a OCX file using WiX. How to do that? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: Registering OCX
That page does not contain the word OCX, so what do you like to tell me? -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Montag, 29. März 2010 16:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: Registering OCX http://wix.sourceforge.net/manual-wix3/heat.htm Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 29 March 2010 14:49 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question: Registering OCX We need to register a OCX file using WiX. How to do that? --- - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Replacing files in WINDOWS\System32
Dear WiX Community, for one of our applications, we need to provide the latest version of a DLL which comes with XP in an older version (e. g. ASycFilt.dll) and lives in WINDOWS\System32. When we try to run our MSI on XP, it says that it cannot replace this DLL since it is protected by the OS. How can we tell our MSI that it shall deal with this? Thanks Markus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FW: Beginner's Question: 32 Bit MSI on 64 Bit OS
Dear WiX Community, we need to write a MSI file that has to install a 32 Bit software. It shall correctly install on both, Windows 32 and Windows 64. Is it correct to do one setup that always installs into SystemFolder, or do we have to take any special care for the Windows 64 case? Thanks Markus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS
But we do not own a 64 Bit machine, so how to do it on a 32 Bit machine? -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Just create your MSI on 64-bit machine with the DLLs created as target x86, and it will run on both 32-bit\64-bit machine. 64-bit OS will automatically take care of system folder. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Beginner's Question: 32 Bit MSI on 64 Bit OS Dear WiX Community, we need to write a MSI file that has to install a 32 Bit software. It shall correctly install on both, Windows 32 and Windows 64. Is it correct to do one setup that always installs into SystemFolder, or do we have to take any special care for the Windows 64 case? Thanks Markus --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS
But that's weird -- it would mean that it is impossible to install a MSI on a 64 Bit machine that was created in times when there was no 64 Bit around already... -- or that all software vendors in the past obtained 64 Bit machines just to create their 32 Bit MSIs THERE!? Can't believe that. -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Well you have to do it on 64-bit machine only then and then only msi will be fully 64-bit\32-bit compatible. I already encounter this issue in past and had to get 64-bit OS just to solve this issue. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS But we do not own a 64 Bit machine, so how to do it on a 32 Bit machine? -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Just create your MSI on 64-bit machine with the DLLs created as target x86, and it will run on both 32-bit\64-bit machine. 64-bit OS will automatically take care of system folder. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Beginner's Question: 32 Bit MSI on 64 Bit OS Dear WiX Community, we need to write a MSI file that has to install a 32 Bit software. It shall correctly install on both, Windows 32 and Windows 64. Is it correct to do one setup that always installs into SystemFolder, or do we have to take any special care for the Windows 64 case? Thanks Markus - -- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - -- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Replacing files in WINDOWS\System32
Thanks for your help. Doesn't sound really promising... Maybe it's just best to run Microsoft's original Runtime Installer EXE then (unfortunately it's such old that there is no MSM). Thanks Markus -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Donnerstag, 25. März 2010 13:25 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing files in WINDOWS\System32 Use a bootstrapper to install the redistributable from Microsoft which updates that file to the version you require before you install your MSI. Any other solution has massive potential for problems. If you're looking for a bootstrapper I recommend dotNetInstaller - http://dotnetinstaller.codeplex.com/ Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 25 March 2010 11:05 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Replacing files in WINDOWS\System32 Dear WiX Community, for one of our applications, we need to provide the latest version of a DLL which comes with XP in an older version (e. g. ASycFilt.dll) and lives in WINDOWS\System32. When we try to run our MSI on XP, it says that it cannot replace this DLL since it is protected by the OS. How can we tell our MSI that it shall deal with this? Thanks Markus --- - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS
Sounds good, thank you! :-) -Original Message- From: Richard Horsley [mailto:richard.hors...@eicltd.com] Sent: Donnerstag, 25. März 2010 13:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS As I said a bit further back, installing regular x86 MSI's on x64 windows systems works absolutely fine. It will automatically use SysWOW64 instead of system32, Wow6432Node for registry settings and Program Files (x86) for the actual program directory. Unless you specify otherwise, this is the defauly behaviour of the standard x86 variables on x64 machines. Richard -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: 25 March 2010 12:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Karg, If you get a chance to install your x86 msi on 64 bit OS, please share your results with me. It will help me in future. -- H -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Thursday, March 25, 2010 5:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS MSI's themselves are built for either x86 or x64 platforms (or Intel64 aka Itanium but they're so rare it's not worth mentioning). Build your MSI for x86 as you normally do if a user tries to install it on an x64 system msiexec/WoW will take care of it. Ignore everything Harshil says, you don't need an x64 machine to build an x86 MSI which works on both x86 x64 Windows installations. MSI's DLL's are separate issues. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: 25 March 2010 11:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Well it is obvious that msi created on 32-bit machine has no knowledge of 64-bit environment and if u wont to provide support to both 64-bit and 32-bit OS, its required man...sorry.. you can try with it.. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:59 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS But that's weird -- it would mean that it is impossible to install a MSI on a 64 Bit machine that was created in times when there was no 64 Bit around already... -- or that all software vendors in the past obtained 64 Bit machines just to create their 32 Bit MSIs THERE!? Can't believe that. -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Well you have to do it on 64-bit machine only then and then only msi will be fully 64-bit\32-bit compatible. I already encounter this issue in past and had to get 64-bit OS just to solve this issue. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS But we do not own a 64 Bit machine, so how to do it on a 32 Bit machine? -Original Message- From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] Sent: Donnerstag, 25. März 2010 12:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS Just create your MSI on 64-bit machine with the DLLs created as target x86, and it will run on both 32-bit\64-bit machine. 64-bit OS will automatically take care of system folder. -- H -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: Thursday, March 25, 2010 4:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Beginner's Question: 32 Bit MSI on 64 Bit OS Dear WiX Community, we need to write a MSI file that has to install a 32 Bit software. It shall correctly install on both, Windows 32 and Windows 64. Is it correct to do one setup that always installs into SystemFolder, or do we have to take any special care for the Windows 64
Re: [WiX-users] Replacing files in WINDOWS\System32
...because I need to install a VisualBasic5 runtime, and Microsoft only provides a EXE but not a MSM for that. What the EXE does is basically replacing some DLLs in Windows\System32. So it is not *my* idea to do that, but Microsoft's... -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Donnerstag, 25. März 2010 16:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing files in WINDOWS\System32 Guten Tag Markus Karg, am Donnerstag, 25. März 2010 um 13:37 schrieben Sie: Doesn't sound really promising... Maybe it's just best to run Microsoft's original Runtime Installer EXE then (unfortunately it's such old that there is no MSM). Maybe the more preferable way is to get a solution for why you need the DLL to be in system32? Microsoft doesn't recommend that for years now. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow --- --- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is perMachine the default?
But what actually is the difference in the outcome between not setting InstallScope and setting it to perMachine? Actually (at least on my Vista laptop) it seems what I am getting is always an elevated perMachine install. So why setting it? -Original Message- From: Blair [mailto:os...@live.com] Sent: Freitag, 6. November 2009 01:59 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Is perMachine the default? Not quite. There are two things at play here: the ALLUSERS property and the don't elevate flag. If you set InstallPrivileges to elevated the flag is not set (the default). If you set InstallPrivileges to limited the flag is set. Nothing is done wrt the property with this attribute. If instead you set the InstallScope property, then the following happens: If it is set to perMachine, the property is set to 1 and the flag is not set. If it is set to perUser, the property is not created and the flag is set. In perUser packages, you want the flag set and the property not created. In perMachine packages, you want the property set and the flag not set. Thus, the InstallScope attribute does it all, and you don't need to worry about the flag or the property being set correctly (for non Win7-only switching packages). -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Thursday, November 05, 2009 1:02 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Is perMachine the default? When running my .msi on Vista, I do not see any difference between InstallScope=perMachine and not using this attribute at all. Is perMachine the default? --- - -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallScope=perUser makes only sense on Windows Seven?
Blair, once more, thank you for this interesting insights! So in short: perMachine will work everywhere the same, but perUser will work differently for Windows 7 to all the rest - on Windows 7 the MSI5 will automatically provide privately mapped locations, while on all other platforms the .msi author has to provide this logic (what also will work on Windows 7). Ok, since least of my customers will have Windows 7 in the next months, then I should provide this on my own. If I see it correctly, what I have to do is *not* using ProgramFilesFolder but something different. This shouldn't be hard to do, but: As a result, it is up to the *.msi author* to decide *where* the software will go. I don't think that administrators will love the idea that each .msi has some other, fancy location (they had been so glad about the fact that some day ProgramFilesFolder was invented: now they know for sure where all the software is located). This is a real drawback I think. In fact, what I think would be optimal: * Files go into %ProgramFilesFolder% (per Machine) * Shortcuts and Verbs go into each user's profile (per User) * both in one installation step ...but this is exactly what you told me *not* to do... :-( Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Freitag, 6. November 2009 01:51 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] InstallScope=perUser makes only sense on Windows Seven? If you set InstallScope=perUser then your MSI will be marked to not prompt for elevation. As a consequence you cannot set ALLUSERS and all resources must go into locations that don't require elevation, unless you want to see the error you are reporting. ProgramFilesFolder always requires elevation (unless the default permissions have been severely altered) and as a result your files should not go under ProgramFilesFolder if you set perUser as your installation scope. Real perUser installations are very possible under Vista and XP (I have written several), but they require that you pick a directory to install that is in the user's profile and not in Program Files, and that you don't put anything in HKLM. In Windows 7 (using MSI 5.0), the ProgramFilesFolder gets remapped to a profile location when the installation ends up perUser, which is what helps enable switchable packages, but only when setting the MSIINSTALLPERUSER property. In downlevel platforms, that folder never changes value and thus always points to a protected perMachine location. Also, Windows 7 does not force you to write perUser. You can write perMachine and get just as good a job as under Vista with the very same MSI. It simply makes a very old pattern installation pattern that was never very well supported previously more viable. Without Windows 7 you generally have to write two MSI files if you wish one to be perUser and the other perMachine. With Windows 7 you can still use the exact same MSI files in the same way (there is NO forcing of a new way), or you can make a single package that can be installed either way using the new property to enable the new behavior. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Thursday, November 05, 2009 1:01 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] InstallScope=perUser makes only sense on Windows Seven? This perMachine / perUser discussion really confuses me. ;-) I tried what happens if I set InstallScope=perUser. The result is, that I cannot install the software on Vista, because it says I do not have sufficient access rights to enter C:\Program Files\[Manufacturer] (no, it does not ask whether it shall elevate, even if I set InstallPrivileges=elevated in addition to InstallScope=perUser). This is because real perUser installs are only possible in Windows 7, but all other Windows (= 99,9% of all existing installations) will share the files folder. So if InstallScope=perUser useless on every OS besides Windows 7? The consequence would be that one must write different .msi for Vista and Windows 7 -- one that is perMachine (since perUser will not work) and one that is perUser (since that seems to be what Microsoft wants us to do in Windows 7). This sounds weird, since everything else besides that flag will be the same! Or did I miss something? Thanks Markus --- - -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https
Re: [WiX-users] Per User / Per Machine
Blair, thank you very much for your detailed answer. :-) So if I understand correctly, all I have to do is to set ALLUSERS to 1? Ok, nice. :-) But actually, after decades of seeing lots of installers asking the administrator where the *he* wants the files get copied to, I do not understand why it is up to *the .msi author* to decide about this... (actually I do not see any sense in deciding this *per .msi file* at all, as virtually all currently installed products are installed *per machine* anyways since no Windows before Seven was able to do a pure per-user install, and nobody ever seriously complained about that, and with a decision *per .msi file* chaos is likely to come...: Hey admin, why can I execute all programs but not this one? Why can everybody but me execute this program? And why did it work on Vista but on Seven it is just vanished from my Start menu?). For me as a MSI starter this reads like: You can't do it right. I will fail anyways. ;-) Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 5. November 2009 12:57 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Some items' ultimate locations depend on the ALLUSERS value. Some examples: HKCR is really a merge of a key under HKLM and a different key under HKCU. If ALLUSERS is set to 1, you get the HKLM registration, otherwise (when it is blank) you get the HKCU one. The predefined property StartMenuFolder varies its value based on ALLUSERS as well. See the following table: Type of Install REFKNOWNFOLDERIDCSIDL Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU Per-user StartMenu CSIDL_STARTMENU The portion of your authoring for items using those two values are easy since the actual authoring doesn't change. However, the location of the binary that the verb and the shortcut point to need to be in a location that will be correctly identified, and that location should vary based on what value of ALLUSERS you are supporting (if you use ProgramFilesFolder, for instance, the location you get will be in a non-profile location that requires elevation to access, that is, a per-machine location, so you can't really use it in a per-user package.) -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Wednesday, November 04, 2009 10:53 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine But how to do that, author the package based on your decision? I mean, I just have two files, one program menu item and one extension verb. The .wxs file is more or less a copy of the WiX manual's samples / WiX tutorial code snippets. The WiX manual does not say something about authoring the packaging based on your decision, nor does the WiX tutorial. Is it enough to just set the ALLUSERS property, or how is that to be done author the package based on your decision? Sorry for one more silly questions, but I just can't find a How-To for that. Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Mittwoch, 4. November 2009 06:47 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Sorry if I am confusing you. I recommend you decide upfront if your installation will be per-user or per-machine. Don't try to make a package that is intended to be switchable. Then author the package based on your decision. MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make workable packages that can be switched during installation. However, the advice is still: don't do it. Make it one or the other and prevent the one you don't support. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Tuesday, November 03, 2009 9:28 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Blair, now I am more confused than before. On one hand you say, I shall write a .msi that is either perUser OR perMachine, on the other hand you say that it is very hard to do when not using MSI 5 (which is only available on Windows 7). So for me this reads like: For a MSI beginner it is impossible to write a correctly working setup on any OS before W7.;-( Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Montag, 2. November 2009 21:43 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine All resources (files, registry entries, etc.) can generally be divided into three spaces: those that live in administrator per-machine areas (C:\Program Files, etc.), those that live in the user profile, and those very few that live
[WiX-users] InstallScope=perUser makes only sense on Windows Seven?
This perMachine / perUser discussion really confuses me. ;-) I tried what happens if I set InstallScope=perUser. The result is, that I cannot install the software on Vista, because it says I do not have sufficient access rights to enter C:\Program Files\[Manufacturer] (no, it does not ask whether it shall elevate, even if I set InstallPrivileges=elevated in addition to InstallScope=perUser). This is because real perUser installs are only possible in Windows 7, but all other Windows (= 99,9% of all existing installations) will share the files folder. So if InstallScope=perUser useless on every OS besides Windows 7? The consequence would be that one must write different .msi for Vista and Windows 7 -- one that is perMachine (since perUser will not work) and one that is perUser (since that seems to be what Microsoft wants us to do in Windows 7). This sounds weird, since everything else besides that flag will be the same! Or did I miss something? Thanks Markus -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Is perMachine the default?
When running my .msi on Vista, I do not see any difference between InstallScope=perMachine and not using this attribute at all. Is perMachine the default? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per User / Per Machine
But as I just tried out, it is impossible to author a elevated perUSer installation: InstallScope=perUser actually does override a manually coded InstallPrivileges=elevated attribute! So is that a bug in WiX? -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: Donnerstag, 5. November 2009 21:44 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Per User / Per Machine A couple of comments: 1. It's only since UAC that the per-machine/per-user difficulty has been around. It's not been there forever. MSIINSTALLPERUSER is the solution in MSI 5.0. http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authori ng-a-single-package-for-per-user-or-per-machine-installation-context- in-windows-7.aspx 2. It's hard to talk about per-user and per-machine without taking privilege into account. A lot of people seem to be under the impression that you don't need to be elevated to install a per-user MSI, and then author it to write to all kinds of restricted locations and wonder why they need admin privilege to install it. ALLUSERS=2 produces unexpected effects for non-elevated users where you get a per-user install when a per-system may have been assumed (some other user logs on and says I can see the files are installed but there's no shortcut). Phil Wilson -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Thursday, November 05, 2009 11:53 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Blair, thank you very much for your detailed answer. :-) So if I understand correctly, all I have to do is to set ALLUSERS to 1? Ok, nice. :-) But actually, after decades of seeing lots of installers asking the administrator where the *he* wants the files get copied to, I do not understand why it is up to *the .msi author* to decide about this... (actually I do not see any sense in deciding this *per .msi file* at all, as virtually all currently installed products are installed *per machine* anyways since no Windows before Seven was able to do a pure per-user install, and nobody ever seriously complained about that, and with a decision *per .msi file* chaos is likely to come...: Hey admin, why can I execute all programs but not this one? Why can everybody but me execute this program? And why did it work on Vista but on Seven it is just vanished from my Start menu?). For me as a MSI starter this reads like: You can't do it right. I will fail anyways. ;-) Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 5. November 2009 12:57 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Some items' ultimate locations depend on the ALLUSERS value. Some examples: HKCR is really a merge of a key under HKLM and a different key under HKCU. If ALLUSERS is set to 1, you get the HKLM registration, otherwise (when it is blank) you get the HKCU one. The predefined property StartMenuFolder varies its value based on ALLUSERS as well. See the following table: Type of Install REFKNOWNFOLDERIDCSIDL Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU Per-userStartMenu CSIDL_STARTMENU The portion of your authoring for items using those two values are easy since the actual authoring doesn't change. However, the location of the binary that the verb and the shortcut point to need to be in a location that will be correctly identified, and that location should vary based on what value of ALLUSERS you are supporting (if you use ProgramFilesFolder, for instance, the location you get will be in a non-profile location that requires elevation to access, that is, a per-machine location, so you can't really use it in a per-user package.) -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Wednesday, November 04, 2009 10:53 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine But how to do that, author the package based on your decision? I mean, I just have two files, one program menu item and one extension verb. The .wxs file is more or less a copy of the WiX manual's samples / WiX tutorial code snippets. The WiX manual does not say something about authoring the packaging based on your decision, nor does the WiX tutorial. Is it enough to just set the ALLUSERS property, or how is that to be done author the package based on your decision? Sorry for one more silly questions, but I just can't find a How-To for that. Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Mittwoch, 4. November 2009 06:47 To: 'General discussion for Windows
Re: [WiX-users] Fragments or Merge Modules?
Just what I say: IDs should be GUIDs. If actually is not, it is a bug, since you run in the problem that you actually run into. If I were you, I would file a bug report describing the problem. Regards Markus -Original Message- From: Nick Ball [mailto:nick.b...@grantadesign.com] Sent: Mittwoch, 4. November 2009 12:56 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Fragments or Merge Modules? Actually, no. Say I have two wixlibs for two different features. I run heat as a prebuild on both libs (so in total it is run twice) with the -cg option which very nicely generates componentgroups, but the ID's for each directory are things like 'folder1'. Now when both libraries have directories with the same Id it is there that I run into trouble. -Nick -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: 03 November 2009 18:21 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Fragments or Merge Modules? For me this more sounds like a bug in heat. IDs should be GUID -- *unique* IDs. Regards Markus -Original Message- From: Nick Ball [mailto:nick.b...@grantadesign.com] Sent: Dienstag, 3. November 2009 16:07 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Fragments or Merge Modules? I've had a problem using wixlibs in that auto-generated (heat.exe) libraries can end up having the same ID's for components, which then fails to build. This doesn't happen with merge modules - which is what I've ended up doing. -N -Original Message- From: Blair [mailto:os...@live.com] Sent: 02 November 2009 21:02 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Fragments or Merge Modules? More-or-less yes, you have it right. There are several servicing issues related to Merge Modules, and some of those issues are carried into the way that WiX incorporates Merge Modules (making them even harder to deal with than they already would have been, especially as relates to patching/patch generation). You can create binary wixlibs, which are compiled fragments that carry the files they otherwise incorporate by reference in the wixlib itself, making them have all the advantages of merge modules except the portability with other toolsets. The typical decision path is: prefer either fragments or wixlibs over merge modules when you don't need to incorporate the shared code with non-wix toolsets. Note that wix 3.5 and 3.0 can share the same wixlibs, while wix 2.0 can't share the same libs with 3.x (or the same source code without some transformation either). -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 12:07 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Fragments or Merge Modules? If I understand correctly, there are two ways to modularize my setup: Fragments and Merge Modules. So the question is: Which one to use? For me it looks like Merge Modules being a more heavy weight solution, but the benefit is that those are a product-independent standard (i. e. InstallShield or Wise can use them, too), while Fragments are more light weight, but can be used only by WiX. Is that correct? Or did I missed the point? Maybe there is a more essential difference (besides the fact that a Fragment is a *source object* while a Merge Module is a *binary (compiled and linked) object*)? What is the typical decision path (when to prefer Fragments over Merge Modules and vice versa)? Thanks Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per User / Per Machine
But how to do that, author the package based on your decision? I mean, I just have two files, one program menu item and one extension verb. The .wxs file is more or less a copy of the WiX manual's samples / WiX tutorial code snippets. The WiX manual does not say something about authoring the packaging based on your decision, nor does the WiX tutorial. Is it enough to just set the ALLUSERS property, or how is that to be done author the package based on your decision? Sorry for one more silly questions, but I just can't find a How-To for that. Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Mittwoch, 4. November 2009 06:47 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Sorry if I am confusing you. I recommend you decide upfront if your installation will be per-user or per-machine. Don't try to make a package that is intended to be switchable. Then author the package based on your decision. MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make workable packages that can be switched during installation. However, the advice is still: don't do it. Make it one or the other and prevent the one you don't support. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Tuesday, November 03, 2009 9:28 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Blair, now I am more confused than before. On one hand you say, I shall write a .msi that is either perUser OR perMachine, on the other hand you say that it is very hard to do when not using MSI 5 (which is only available on Windows 7). So for me this reads like: For a MSI beginner it is impossible to write a correctly working setup on any OS before W7.;-( Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Montag, 2. November 2009 21:43 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine All resources (files, registry entries, etc.) can generally be divided into three spaces: those that live in administrator per-machine areas (C:\Program Files, etc.), those that live in the user profile, and those very few that live in shared document regions. If your installation requires access to administrator-controlled regions of the computer, it should be a pure perMachine and NOT place anything in perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is currently only available on Windows 7 AFAIK) it has been extremely difficult to author a package that can go either way, although it was somewhat easier before Vista/UAC entered the picture. Administrators are supposed to follow author's guidelines when using advertising to make a program available to users. /ju and /jm don't actually install the software and they don't set ALLUSERS. Also, personally, I haven't found /ju to be very useful: it doesn't provide a place to designate the user to advertise to, and if that user doesn't already have admin privileges, the command will fail while if the user does have those privileges, the command isn't needed. Then again, maybe I haven't found the magic incantation yet. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 11:01 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Per User / Per Machine Blair, in a different context you wrote: It is best to make your installations pure-perMachine or pure- perUser and never mix them There is one thing I do not understand in that context: I always had the impression that it is up to the *administrator* to decide whether to install a software Per User / Per Machine: Isn't that what msiexec's /ju and /jm options are good for? Now reading your above comment (and the MSDN chapter about the ALLUSERS property) I am a bit confused. If it is up to the .msi *author* to decide about Per User / Per Machine (using the ALLUSERS property), for what is /ju and /jm good then? And what will happen if my .msi file is for Per User, but the administrator is using /jm (or vice versa)? Thanks Markus - -- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why is the WiX manual using DirectoryRef
I disagree that structure and content are different concerns, they are the same (or do you separate files and folders on your harddisk, too?). The question was, why it is used in the *most simple* examples. Since it does *not* focus on the example at hand, but instead, makes that examples overly lengthy and complex, compared to the examples found in the WiX tutorial. In fact, I share the WiX tutorial author's opinion that DirectoryRef shouldn't get used unless it is *needed* (yes, these days we designers discuss topics like 'overdesigning' and 'overarchitecturing') to not provide lots of code overhead (which is hard to read and error-prone) -- what mostly will be the case only if Fragment is used. *That's* why I asked for a reason. If it would be optimal to *always* separate it, then it wouldn't make any sense to allow File inside of Directory at all, since virtually nobody will confess that he is writing a HelloWorld.msi... ;-) Regards Markus -Original Message- From: IFM Lists [mailto:jkli...@ifm-services.com] Sent: Mittwoch, 4. November 2009 01:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Why is the WiX manual using DirectoryRef did that complexity ... Why is the WiX manual separating content from structure Markus, I am a new WiX user, but based my gut reaction as a software engineer, and my thin experience so far with WiX, the answer is separation of concerns, which is a fancy way of saying because it's smart to do. Once you move past the most simple of projects, separating content from structure allows you to maintain your sanity. :) As far as the documentation is concerned (isolated from any project), I like the DirectoryRef use as (1) it illustrates appropriate use but more importantly (2) it does keep things focused on the example at hand. Just my two bits. --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] lit.exe -loc
Spent one hour, finally discovered my own fault: I wrote light x.wixlib y.wixOBJ instead of light x.wixlib y.wixLIB -- certainly there will be no resources found in the original .wixOBJ, but only in the .wixLIB...! :-( -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Dienstag, 3. November 2009 20:51 To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] lit.exe -loc I have modularized my WiX project into several small subprojects using fragments and wixlibs. Binding together the wixlibs (and such, the fragments with the main product) is working well. Now I want to modularize my translations (.wxl file). I am binding micro .wxl files into my wixlibs using lit's -loc parameter. But now when binding everything together, light says that it cannot find exactly those resources that I have just moved into the wixlibs. Is that a bug or am I doing something wrong? Here is the code: candle myFragment.wxs // prints no error lit -bf myFragment.wixobj -loc myFragment.wxl -o myFragment.wixlib // prints no error candle myProduct.wxs // prints no error light myFragment.wixlib myProduct.wixobj -cultures:de,neutral -loc myProduct.wxl // not finding content of myFragment.wxl Thanks Markus --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why is the WiX manual using DirectoryRef
I understand *your* reasons, but again, my question was: Why using DirectoryRef in the *most simple*, *very first* How-To (that HelloWorld-style one read first by every WiX beginner) printed in the WiX documentation? My question is *not* if anybody knows *any* reason for using DirectoryRef in general -- I can assume lots of them by myself and think separation is great -- but my question is *only* about the WiX manual sample. Regards Markus -Original Message- From: Zachary Young [mailto:zacharysyo...@gmail.com] Sent: Mittwoch, 4. November 2009 21:37 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Why is the WiX manual using DirectoryRef Hi Markus, I've been writing WiX installers for over a year now and started off relatively soon with using DirectoryRef/, putting solely my directory tree in one WXS (DirectoryStructure.wxs) and then having each File/ referencing the directory ID's in that file. This later became very valuable when we started selling one product to many customers--each customer needed a slightly unique look to their installer, but the underlying directory structure needed to be exactly the same for the application to run--so all the individual projects linked in this one directory structure. -Zach On Wed, Nov 4, 2009 at 11:02 AM, Markus Karg markus.k...@gmx.net wrote: I disagree that structure and content are different concerns, they are the same (or do you separate files and folders on your harddisk, too?). The question was, why it is used in the *most simple* examples. Since it does *not* focus on the example at hand, but instead, makes that examples overly lengthy and complex, compared to the examples found in the WiX tutorial. In fact, I share the WiX tutorial author's opinion that DirectoryRef shouldn't get used unless it is *needed* (yes, these days we designers discuss topics like 'overdesigning' and 'overarchitecturing') to not provide lots of code overhead (which is hard to read and error-prone) -- what mostly will be the case only if Fragment is used. *That's* why I asked for a reason. If it would be optimal to *always* separate it, then it wouldn't make any sense to allow File inside of Directory at all, since virtually nobody will confess that he is writing a HelloWorld.msi... ;-) Regards Markus -Original Message- From: IFM Lists [mailto:jkli...@ifm-services.com] Sent: Mittwoch, 4. November 2009 01:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Why is the WiX manual using DirectoryRef did that complexity ... Why is the WiX manual separating content from structure Markus, I am a new WiX user, but based my gut reaction as a software engineer, and my thin experience so far with WiX, the answer is separation of concerns, which is a fancy way of saying because it's smart to do. Once you move past the most simple of projects, separating content from structure allows you to maintain your sanity. :) As far as the documentation is concerned (isolated from any project), I like the DirectoryRef use as (1) it illustrates appropriate use but more importantly (2) it does keep things focused on the example at hand. Just my two bits. --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to know which InstallerVersion to use?
Markus I'd recommend setting InstallerVersion to 301 unless you want to either bootstrap the 4.5 installer before your MSI (or expect your users to manually install it) or you don't mind excluding users on certain O/S'es (this is sometimes desirable if your application has certain requirements). 3.1 is pushed to all versions of XP by Automatic Updates so you're quite safe to assume that's the minimum your users will be able to support (even Windows 2000 has 3.1 available). Thank you for this tip. But why not just keep the default (100), unless I need any particular feature of a higher version? -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fragments or Merge Modules?
Blair, thank you for your comments. If WiX makes using Merge Modules more complex than it should be, why not improving that issue? I mean, shouldn't WiX make dealing with MSI easier than harder? Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Montag, 2. November 2009 22:02 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Fragments or Merge Modules? More-or-less yes, you have it right. There are several servicing issues related to Merge Modules, and some of those issues are carried into the way that WiX incorporates Merge Modules (making them even harder to deal with than they already would have been, especially as relates to patching/patch generation). You can create binary wixlibs, which are compiled fragments that carry the files they otherwise incorporate by reference in the wixlib itself, making them have all the advantages of merge modules except the portability with other toolsets. The typical decision path is: prefer either fragments or wixlibs over merge modules when you don't need to incorporate the shared code with non-wix toolsets. Note that wix 3.5 and 3.0 can share the same wixlibs, while wix 2.0 can't share the same libs with 3.x (or the same source code without some transformation either). -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 12:07 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Fragments or Merge Modules? If I understand correctly, there are two ways to modularize my setup: Fragments and Merge Modules. So the question is: Which one to use? For me it looks like Merge Modules being a more heavy weight solution, but the benefit is that those are a product-independent standard (i. e. InstallShield or Wise can use them, too), while Fragments are more light weight, but can be used only by WiX. Is that correct? Or did I missed the point? Maybe there is a more essential difference (besides the fact that a Fragment is a *source object* while a Merge Module is a *binary (compiled and linked) object*)? What is the typical decision path (when to prefer Fragments over Merge Modules and vice versa)? Thanks Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to know which InstallerVersion to use?
Blair, thank you for this detailed information. It is a big help for me. Since I don't know anything about any of the mentioned features, I doubt that I ever will need a later version than 1.00 (100), as my software is not 64 Bit. :-) I just have filed a request to add your list to the WiX documentation, so people know what version put request. Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Montag, 2. November 2009 22:46 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? If you don't specify, WiX currently defaults to 1.0 (100). Very brief matrix: MSI 1.x - basic MSI support, 32-bit only. MSI 2.x - added 64-bit support. MSI 3.0 - improved patching. MSI 3.1 - improved external ui. MSI 4.0 - Vista/2008 only. Incorporates UAC-integration/restart-manager-integration/transaction-integration as well as embedded-UI/msi-chaining and some improvements to patch support (superseded components/patch removal custom actions. MSI 4.5 - some bug fixes, and a redistributable containing the embedded ui, msi chaining, and improved patch support (superseded components and patch removal actions) for supported pre-Vista platforms. The restart manager, UAC, and transaction integrations require platform support so they are not in the downlevel redistributable (although they are retained in the vista/2008 redistributable), but all the other improvements in 4.0 are in 4.5. MSI 5.0 - Windows 7/2008 R2 only (AFAIK). Big things are SDDL for configuring permissions, more control over services, finally some improvement to the internal UI (a hyperlink control, a print and a launch-app control events), along with a way to finally author packages that can be switched between per-user and per-machine during the installation. See the links off this page for more details: http://msdn.microsoft.com/library/aa372796.aspx for details after 2.0. This page details each released build from 2.0 on: http://msdn.microsoft.com/library/aa371185.aspx. MSDN no longer documents the changes that 2.0 added from 1.x apart from the 64-bit support, but no version of 1.x is supported anymore either (that was much more than a decade ago). Most of the info on 1.x I found was on Wikipedia. If you look to see in the lists of what wasn't supported to determine which version started supporting the things you use, you will then be able to determine which is your minimum version. Or, if you have a minimum platform (XP SP2, Vista, whatever) you can look to see what shipped with that platform and avoid anything that isn't supported in that release of Windows Installer. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 11:16 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] How to know which InstallerVersion to use? I am a beginner to MSI and WiX and have a question on the InstallerVersion attribute: How to know what version of WindowsInstaller my .msi will need to run correctly? Is there some kind of table that I did not discover so far, containing all WiX / MSI features plus the needed version number? And, if I do not use the attribute at all, what will happen then? Maybe this is a silly question, but I did not find any answer besides For 64-bit Windows Installer packages, this property must be set to 200 or greater.. Thanks! Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market
Re: [WiX-users] Per User / Per Machine
Blair, now I am more confused than before. On one hand you say, I shall write a .msi that is either perUser OR perMachine, on the other hand you say that it is very hard to do when not using MSI 5 (which is only available on Windows 7). So for me this reads like: For a MSI beginner it is impossible to write a correctly working setup on any OS before W7.;-( Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Montag, 2. November 2009 21:43 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine All resources (files, registry entries, etc.) can generally be divided into three spaces: those that live in administrator per-machine areas (C:\Program Files, etc.), those that live in the user profile, and those very few that live in shared document regions. If your installation requires access to administrator-controlled regions of the computer, it should be a pure perMachine and NOT place anything in perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is currently only available on Windows 7 AFAIK) it has been extremely difficult to author a package that can go either way, although it was somewhat easier before Vista/UAC entered the picture. Administrators are supposed to follow author's guidelines when using advertising to make a program available to users. /ju and /jm don't actually install the software and they don't set ALLUSERS. Also, personally, I haven't found /ju to be very useful: it doesn't provide a place to designate the user to advertise to, and if that user doesn't already have admin privileges, the command will fail while if the user does have those privileges, the command isn't needed. Then again, maybe I haven't found the magic incantation yet. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 11:01 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Per User / Per Machine Blair, in a different context you wrote: It is best to make your installations pure-perMachine or pure- perUser and never mix them There is one thing I do not understand in that context: I always had the impression that it is up to the *administrator* to decide whether to install a software Per User / Per Machine: Isn't that what msiexec's /ju and /jm options are good for? Now reading your above comment (and the MSDN chapter about the ALLUSERS property) I am a bit confused. If it is up to the .msi *author* to decide about Per User / Per Machine (using the ALLUSERS property), for what is /ju and /jm good then? And what will happen if my .msi file is for Per User, but the administrator is using /jm (or vice versa)? Thanks Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Why is the WiX manual using DirectoryRef
I have read both, the WiX manual and the WiX tutorial. While the WiX tutorial is putting content (Files) directly into structure (Directorys), the WiX manual is always separating it (Files are only used in DirectoryRefs). As Gábor didn't know why the WiX manual authors did that complexity, I'd like to ask this mailing list: Why is the WiX manual separating content from structure, even in the most simplest How-To documents? Regards Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] lit.exe -loc
I have modularized my WiX project into several small subprojects using fragments and wixlibs. Binding together the wixlibs (and such, the fragments with the main product) is working well. Now I want to modularize my translations (.wxl file). I am binding micro .wxl files into my wixlibs using lit's -loc parameter. But now when binding everything together, light says that it cannot find exactly those resources that I have just moved into the wixlibs. Is that a bug or am I doing something wrong? Here is the code: candle myFragment.wxs // prints no error lit -bf myFragment.wixobj -loc myFragment.wxl -o myFragment.wixlib // prints no error candle myProduct.wxs // prints no error light myFragment.wixlib myProduct.wixobj -cultures:de,neutral -loc myProduct.wxl // not finding content of myFragment.wxl Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fragments or Merge Modules?
Rob, thank you very much for this interesting insights. Using wixlibs seems to be the right solution unless external partners come into play. Thanks Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Dienstag, 3. November 2009 16:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Fragments or Merge Modules? Markus, This old blog post of mine might be useful as well: http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs- and-why-would-you-use-them. You've hit the high points already though. On Mon, Nov 2, 2009 at 1:01 PM, Blair os...@live.com wrote: More-or-less yes, you have it right. There are several servicing issues related to Merge Modules, and some of those issues are carried into the way that WiX incorporates Merge Modules (making them even harder to deal with than they already would have been, especially as relates to patching/patch generation). You can create binary wixlibs, which are compiled fragments that carry the files they otherwise incorporate by reference in the wixlib itself, making them have all the advantages of merge modules except the portability with other toolsets. The typical decision path is: prefer either fragments or wixlibs over merge modules when you don't need to incorporate the shared code with non- wix toolsets. Note that wix 3.5 and 3.0 can share the same wixlibs, while wix 2.0 can't share the same libs with 3.x (or the same source code without some transformation either). -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 12:07 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Fragments or Merge Modules? If I understand correctly, there are two ways to modularize my setup: Fragments and Merge Modules. So the question is: Which one to use? For me it looks like Merge Modules being a more heavy weight solution, but the benefit is that those are a product-independent standard (i. e. InstallShield or Wise can use them, too), while Fragments are more light weight, but can be used only by WiX. Is that correct? Or did I missed the point? Maybe there is a more essential difference (besides the fact that a Fragment is a *source object* while a Merge Module is a *binary (compiled and linked) object*)? What is the typical decision path (when to prefer Fragments over Merge Modules and vice versa)? Thanks Markus - --- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fragments or Merge Modules?
For me this more sounds like a bug in heat. IDs should be GUID -- *unique* IDs. Regards Markus -Original Message- From: Nick Ball [mailto:nick.b...@grantadesign.com] Sent: Dienstag, 3. November 2009 16:07 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Fragments or Merge Modules? I've had a problem using wixlibs in that auto-generated (heat.exe) libraries can end up having the same ID's for components, which then fails to build. This doesn't happen with merge modules - which is what I've ended up doing. -N -Original Message- From: Blair [mailto:os...@live.com] Sent: 02 November 2009 21:02 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Fragments or Merge Modules? More-or-less yes, you have it right. There are several servicing issues related to Merge Modules, and some of those issues are carried into the way that WiX incorporates Merge Modules (making them even harder to deal with than they already would have been, especially as relates to patching/patch generation). You can create binary wixlibs, which are compiled fragments that carry the files they otherwise incorporate by reference in the wixlib itself, making them have all the advantages of merge modules except the portability with other toolsets. The typical decision path is: prefer either fragments or wixlibs over merge modules when you don't need to incorporate the shared code with non-wix toolsets. Note that wix 3.5 and 3.0 can share the same wixlibs, while wix 2.0 can't share the same libs with 3.x (or the same source code without some transformation either). -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 12:07 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Fragments or Merge Modules? If I understand correctly, there are two ways to modularize my setup: Fragments and Merge Modules. So the question is: Which one to use? For me it looks like Merge Modules being a more heavy weight solution, but the benefit is that those are a product-independent standard (i. e. InstallShield or Wise can use them, too), while Fragments are more light weight, but can be used only by WiX. Is that correct? Or did I missed the point? Maybe there is a more essential difference (besides the fact that a Fragment is a *source object* while a Merge Module is a *binary (compiled and linked) object*)? What is the typical decision path (when to prefer Fragments over Merge Modules and vice versa)? Thanks Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CNDL0019
Blair, thank you very much for your detailed explanation. Now I understand what the problem is. :-) I just filed a proposal https://sourceforge.net/tracker/?func=detailaid=2890852group_id=105970ati d=642717 to add your explanation to the WiX documentation. Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Montag, 2. November 2009 10:09 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] CNDL0019 All advertised entries (CLSID, ProgId, Shortcuts) are implemented via a mechanism that places an encoded version of the ProductCode, ComponentCode, and FeatureId into the entry-point. A health check is made of the indicated feature, and after it runs (possibly repairing, if needed) the keypath of the indicated component is then called. TargetProperty doesn't point to the component's keypath. It points to some arbitrary binary instead. There is no place for Windows Installer to encode that into the three fields listed above. If you want to point to some arbitrary code (that you may not have installed) somewhere, you have to us an unadvertised entry. It would be up to the code at that entry to check for your code (using MsiProvideComponent()) to obtain the benefits associated with advertised entry points. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Sunday, November 01, 2009 10:05 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] CNDL0019 I have a question on Verbs. Error CNDL0019 : The Verb/@TargetProperty attribute cannot be specified because the element is advertised. The WiX manual does not say *why* I cannot use Verb/@TargetProperty with advertised ProgIDs. (1) Why can't I use this combination? (2) What program will the computer execute when invoking this verbs of adverties ProgIDs? (3) How to tell the computer that it shall execute a particular (already installed) EXE instead of anything that comes with my .msi file? Thanks Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Per User / Per Machine
Blair, in a different context you wrote: It is best to make your installations pure-perMachine or pure- perUser and never mix them There is one thing I do not understand in that context: I always had the impression that it is up to the *administrator* to decide whether to install a software Per User / Per Machine: Isn't that what msiexec's /ju and /jm options are good for? Now reading your above comment (and the MSDN chapter about the ALLUSERS property) I am a bit confused. If it is up to the .msi *author* to decide about Per User / Per Machine (using the ALLUSERS property), for what is /ju and /jm good then? And what will happen if my .msi file is for Per User, but the administrator is using /jm (or vice versa)? Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to know which InstallerVersion to use?
I am a beginner to MSI and WiX and have a question on the InstallerVersion attribute: How to know what version of WindowsInstaller my .msi will need to run correctly? Is there some kind of table that I did not discover so far, containing all WiX / MSI features plus the needed version number? And, if I do not use the attribute at all, what will happen then? Maybe this is a silly question, but I did not find any answer besides For 64-bit Windows Installer packages, this property must be set to 200 or greater.. Thanks! Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Fragments or Merge Modules?
If I understand correctly, there are two ways to modularize my setup: Fragments and Merge Modules. So the question is: Which one to use? For me it looks like Merge Modules being a more heavy weight solution, but the benefit is that those are a product-independent standard (i. e. InstallShield or Wise can use them, too), while Fragments are more light weight, but can be used only by WiX. Is that correct? Or did I missed the point? Maybe there is a more essential difference (besides the fact that a Fragment is a *source object* while a Merge Module is a *binary (compiled and linked) object*)? What is the typical decision path (when to prefer Fragments over Merge Modules and vice versa)? Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] (no subject)
The WiX manual contains the following: The first is a RemoveFolder element, which ensures the ApplicationProgramsFolder is correctly removed from the Start Menu when the user uninstalls the application. The second creates a registry entry on install that indicates the application is installed. I have two question about this: (1) Why do I have to care about removing the start menu folder? I know, that this is some issue with the Windows Installer Server (even I actually do not understand the issue). But since it is a *general* issue that *any* Start Menu folder will suffer from, why does WiX not solve the problem on it's own but instead forces the .wsi author to remind this in each and every .wsi file? (2) If I (as an MSI beginner) understood correctly, the idea of the key file is to have one unique thing that Windows Installer will check to see if the component is installed currently. What I do not understand here is, why the the abovementioned example is using an artifical (not further needed) registry key to remind itself about the need to remove the Start Menu folder? I mean, why isn't it possible to reference the start menu folder itself, or at least, why not referencing the installation's main file instead of introducing an artificial registry entry? Sorry for my silly questions, but I want to really understand this, and MSDN does not really say why but only what. Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] CNDL0019
I have a question on Verbs. Error CNDL0019 : The Verb/@TargetProperty attribute cannot be specified because the element is advertised. The WiX manual does not say *why* I cannot use Verb/@TargetProperty with advertised ProgIDs. (1) Why can't I use this combination? (2) What program will the computer execute when invoking this verbs of adverties ProgIDs? (3) How to tell the computer that it shall execute a particular (already installed) EXE instead of anything that comes with my .msi file? Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question on Multi Language Installer
Blair, no need for sarcasm or treating me like an Open Source beginner, just because there was a misunderstanding. I am also an Open Source enthusiast (see http://wikis.sun.com/display/GAP/GAP+Winners there if you like), but in the area of Java, so I am pretty aware of the circumstances. My intension is to improve the documentation, since only thing I could provide - as an MSI beginner - is docs improvement and bug reports. I thought it would be useful to improve things. Isn't it? About the obviously email: Actually I misunderstood his answer since I thought with each page he means the postings in the mailing list. Yes, I know, I am the only one suffering from misunderstandings. Everybody else here certainly is perfect. ;-) Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Dienstag, 27. Oktober 2009 22:08 To: 'General discussion for Windows Installer XML toolset.'; d...@tramontana.co.hu Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Importance: Low The mailto link in the footer of every page looks just like this: mailto:d...@tramontana.co.hu?subject=wixtutorial;. That very link is captioned Gábor DEÁK JAHN. That [o]bviously means he wants it to go to him personally. It also means that the subject of the email message should be WixTutorial, which lets him know that someone is commenting on said tutorial (offering praise, advise, corrections, requesting help to understand, whatever). That way he can sort it or whatever he does to manage the huge number of emails he gets on a daily basis so that he can better maintain that labor of love he contributes to this community (and for which he (hopefully) gets much praise for doing a very good job describing a technology area few understand). Imagine what he could do writing a tutorial on how to author applications in Java or C++ or Ruby on Rails and explain using those technologies to the same degree. He could make money. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Tuesday, October 27, 2009 12:30 PM To: d...@tramontana.co.hu; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Obviously my question was targeting whether I shall sent it to THIS mailinglist, to a different place like an issue tracker or possibly to you personally. Regards Markus -Original Message- From: DEÁK JAHN, Gábor [mailto:d...@tramontana.co.hu] Sent: Dienstag, 27. Oktober 2009 00:09 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Beginner's Question on Multi Language Installer On Mon, 26 Oct 2009 19:42:13 +0100, Markus Karg wrote: Markus, What is the best way to send it in? Using the mailto link in the footer of every page. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: d...@tramontana.co.hu - -- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year
Re: [WiX-users] Beginner's Question on Multi Language Installer
Obviously my question was targeting whether I shall sent it to THIS mailinglist, to a different place like an issue tracker or possibly to you personally. Regards Markus -Original Message- From: DEÁK JAHN, Gábor [mailto:d...@tramontana.co.hu] Sent: Dienstag, 27. Oktober 2009 00:09 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Beginner's Question on Multi Language Installer On Mon, 26 Oct 2009 19:42:13 +0100, Markus Karg wrote: Markus, What is the best way to send it in? Using the mailto link in the footer of every page. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: d...@tramontana.co.hu --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question on Multi Language Installer
Thank you for picking up my issue. If I would have known earlier that active interest is there, I would have noted my issues with the tutorial when reading it. Unfortunately I did not. But if I will find some more, I will let you know. What is the best way to send it in? Regards Markus -Original Message- From: DEÁK JAHN, Gábor [mailto:d...@tramontana.co.hu] Sent: Montag, 26. Oktober 2009 12:17 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Beginner's Question on Multi Language Installer On Wed, 21 Oct 2009 20:18:00 +0200, Markus KARG wrote: Markus, Well, frankly spoken that (really huge) tutorial is in part outdated, false and overly complex to understand, Well, it had been updated to v3 just a couple of months ago, I hope it couldn't have become that outdated since. And if you find anything downright false, I'd be happy to hear the specifics so that I can correct it. As for the complexity, I can't do justice: first, the subject is complex enough. Second, some criticize it for not going deep enough into details... :-)) Lesson 9 deals with your problem specifically, this is the most minimalistic solution MSI can offer today. You build a base installer (in most cases this will be the English one), the language transforms (these are small files, not repeated copies of the same MSI) and embed the transforms into the original MSI. But yes, you will need a bootstrapper of any kind that selects the language appropriate for the actual installation and calls Windows Installer and the MSI with the language transform specified. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: d...@tramontana.co.hu --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question on Multi Language Installer
If you tell me where and how to do this I would be glad to file all of them. :-) -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Montag, 26. Oktober 2009 04:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Great, specifics. Can you capture them in a bug (or multiple bugs) so we knock them down and not lose them in email. On Sun, Oct 25, 2009 at 1:32 AM, Markus Karg markus.k...@gmx.net wrote: Rob, my suggestions to improve the documentation are below. If you think that this information is *explicitly* found in the existing documentation, I would be glad if you could post the particular excerpt here (maybe I just missed them). :-) (1) wix.chm shall contain a note how to author a .wxl file for the neutral culture (WixLocalization/@Culture= using an *empty* string). (2) wix.chm shall contain a note that a .msi file will *ever* only contain exactly *one* culture (It is impossible to author a .msi file containing more than one culture.), which is the one defined in the .wxs file using *Product/@Language*. Also it shall be noted that light.exe's - cultures option has no influence on this. (3) wix.chm shall contain a note that the *sole* use of light.exe's -cultures option is to tell light.exe the *fallback sequence* of cultures to link into the .wsi. It shall be clearly noted that the -cultures option does *not* tell the target computer's Windows Installer which language is contained in the .msi file (see (2) and (4)). (4) wix.chm shall contain a note that the target computer's Windows Installer doesn't care for the culture contained in the .msi at all, since e. g. a German target computer will install an Italian .msi file. *The culture defined in the .wxs / .msi file, is purely informative and has no impact on any technical outcome.* (4) It shall contain a note that light.exe makes no difference between comma and semicolon: *All* provided cultures are specifying the fallback sequence for light.exe, *independent* of the used separation character. *Only* Votive will make such a difference. (5) It shall contain a note what light.exe will do when *no* -culture option is provided. Using these five improvements I think it will be clear to beginners what the cultures stuff is good for and how it works like. Would be glad to find it contained in the next release of WiX (which, BTW, is a great product but just expects people to be MSI experts to use it *correctly*). :-) Regards Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Samstag, 24. Oktober 2009 23:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer There is an entire page dedicated to this topic in the WiX.chm called Specifying Cultures to Build. Can you provide suggestions as to what is not clear? On Sat, Oct 24, 2009 at 5:02 AM, Markus Karg markus.k...@gmx.net wrote: Thank you for this explanation. I wish this would be told in this clarity in the WiX documentation. -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 22. Oktober 2009 02:25 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Depending on where you read the information, different things come into play. In Votive (or anywhere else you are using the msbuild support), if you supply the string de,en;en for the cultures setting (I don't remember the casing or exact spelling of the property), you will get two MSIs built: one that uses German with English fallback (for any missing German strings) and English. Votive will call light.exe two times. In the light.exe command-line snipits as you list them below, in that third example, you get German, falling back to English, falling back to English. In other words, there is no real difference at all between the three command-lines. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Wednesday, October 21, 2009 11:09 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Blair, but what is the difference then between: -culture:de,en -culture:de;en -culture:de,en;en ??? Thanks Markus It looks for the strings in all of the .wxl files sorting them in order of Culture, based on the order of the -Cultures parameter followed by the order the wxl files appear in the commandline. Example without using cultures, but placing the wxl files in numbered order: One.wxl
Re: [WiX-users] Beginner's Question on Multi Language Installer
Rob, my suggestions to improve the documentation are below. If you think that this information is *explicitly* found in the existing documentation, I would be glad if you could post the particular excerpt here (maybe I just missed them). :-) (1) wix.chm shall contain a note how to author a .wxl file for the neutral culture (WixLocalization/@Culture= using an *empty* string). (2) wix.chm shall contain a note that a .msi file will *ever* only contain exactly *one* culture (It is impossible to author a .msi file containing more than one culture.), which is the one defined in the .wxs file using *Product/@Language*. Also it shall be noted that light.exe's -cultures option has no influence on this. (3) wix.chm shall contain a note that the *sole* use of light.exe's -cultures option is to tell light.exe the *fallback sequence* of cultures to link into the .wsi. It shall be clearly noted that the -cultures option does *not* tell the target computer's Windows Installer which language is contained in the .msi file (see (2) and (4)). (4) wix.chm shall contain a note that the target computer's Windows Installer doesn't care for the culture contained in the .msi at all, since e. g. a German target computer will install an Italian .msi file. *The culture defined in the .wxs / .msi file, is purely informative and has no impact on any technical outcome.* (4) It shall contain a note that light.exe makes no difference between comma and semicolon: *All* provided cultures are specifying the fallback sequence for light.exe, *independent* of the used separation character. *Only* Votive will make such a difference. (5) It shall contain a note what light.exe will do when *no* -culture option is provided. Using these five improvements I think it will be clear to beginners what the cultures stuff is good for and how it works like. Would be glad to find it contained in the next release of WiX (which, BTW, is a great product but just expects people to be MSI experts to use it *correctly*). :-) Regards Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Samstag, 24. Oktober 2009 23:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer There is an entire page dedicated to this topic in the WiX.chm called Specifying Cultures to Build. Can you provide suggestions as to what is not clear? On Sat, Oct 24, 2009 at 5:02 AM, Markus Karg markus.k...@gmx.net wrote: Thank you for this explanation. I wish this would be told in this clarity in the WiX documentation. -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 22. Oktober 2009 02:25 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Depending on where you read the information, different things come into play. In Votive (or anywhere else you are using the msbuild support), if you supply the string de,en;en for the cultures setting (I don't remember the casing or exact spelling of the property), you will get two MSIs built: one that uses German with English fallback (for any missing German strings) and English. Votive will call light.exe two times. In the light.exe command-line snipits as you list them below, in that third example, you get German, falling back to English, falling back to English. In other words, there is no real difference at all between the three command-lines. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Wednesday, October 21, 2009 11:09 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Blair, but what is the difference then between: -culture:de,en -culture:de;en -culture:de,en;en ??? Thanks Markus It looks for the strings in all of the .wxl files sorting them in order of Culture, based on the order of the -Cultures parameter followed by the order the wxl files appear in the commandline. Example without using cultures, but placing the wxl files in numbered order: One.wxl: ...String Id=oneThis is the override/String... Two.wxl: ...String Id=oneThis is an override/String... ...String Id=twoThis is the second/String... ...String Id=fourThis is the fourth/String... Three.wxl: ...String Id=oneThis is the original/String... ...String Id=twoThis is another one/String... ...String Id=threeAnd yet another one/String... Then: Property Id=ONE Value=!(loc.one)/ Property Id=TWO Value=!(loc.two)/ Property Id=THREE Value=!(loc.three)/ Property Id=FOUR Value=!(loc.four)/ Results: ONE: This is the override TWO: This is the second THREE: And yet another one FOUR: This is the fourth If each of the above .wxl files had a culture of en-US and you added a fourth .wxl file with a culture of en-HK containing the following
Re: [WiX-users] Beginner's Question on Multi Language Installer
Just answered to this implicitly in my answer to Rob's request for doc improvements. :-) Thanks for all Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Samstag, 24. Oktober 2009 23:18 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer The Specifying Cultures to Build topic in wix.chm (and on the web site) differentiates between command-line (light.exe) and Visual Studio/MSBuild) usages by section. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Saturday, October 24, 2009 5:01 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer As a suggestion for both, the WiX manual and the WiX tutorial, I want to suggest to clearly point out this, and to make a clear distinction between votive interpretation and command line interpretation. I read it several times and did not find any hint that only votive is making a difference between command and semicolon, while the command line tool does not. Thanks for clarification. :-) Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 22. Oktober 2009 02:28 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Votive (actually the MSBuild scripts) differentiates between semicolon and comma. It assumes the list separator is a semicolon and uses that to split the list into separate invocations of light.exe, ignoring the comma. If you change the default list separator character you may or may not break this implementation, I don't remember and I'm not taking the time to look it up right now. Light.exe doesn't care, it recognizes both the semicolon and the comma as separators and treats them identically. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Wednesday, October 21, 2009 11:04 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Markus KARG wrote: What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? It uses all of them to support fallback from available localization files. The WiX MSBuild targets use the list of cultures to generate one MSI per culture. I still don't get it. I always understood fallback in the sense of: -cultures:de,en what mean: If you don't find a word in German, then print the English word. But what I am talking about is: -cultures:de;en (semicolon but not comma). So what acutally will light do when I provide de,en;en? I mean, one must understand the details to correctly use it - and I WANT to correctly use it. :-) Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from
Re: [WiX-users] Beginner's Question on Multi Language Installer
Oops, forgot one item: -- SNIP -- light.exe myinstaller.wixobj -cultures:en-us;en -loc mystrings_en-US.wxl -loc mystrings_en.wxl -ext WixUIExtension -out myinstaller-en-us.msi This will cause light to build an en-us installer first using localization variables from the en-US localization file (mystrings_en-US.wxl), then the en localization file (mystrings_en.wxl), then finally WixUIExtension. -- SNIP-- The above is a bit misleading. One could read it as: This will cause light to build an installer using en-us, then building another installer using en, ... what apparently is what votive would do. To clearly point out that the capability of producing multiple installers using a single execution is *only* a feature of votive, I would replace the phrase by This will cause light to build one installer which uses strings from en-us. If any string is not found in en-us, it looks it up in en. If it still is not found, it looks it up in WixUIExtension.. That is more waterproof. As you see, there is a huge difference between it *is* written in the docs and even a bloody beginner will understand the docs *correctly*. :-) Regards Markus -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Sonntag, 25. Oktober 2009 09:33 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Rob, my suggestions to improve the documentation are below. If you think that this information is *explicitly* found in the existing documentation, I would be glad if you could post the particular excerpt here (maybe I just missed them). :-) (1) wix.chm shall contain a note how to author a .wxl file for the neutral culture (WixLocalization/@Culture= using an *empty* string). (2) wix.chm shall contain a note that a .msi file will *ever* only contain exactly *one* culture (It is impossible to author a .msi file containing more than one culture.), which is the one defined in the .wxs file using *Product/@Language*. Also it shall be noted that light.exe's -cultures option has no influence on this. (3) wix.chm shall contain a note that the *sole* use of light.exe's -cultures option is to tell light.exe the *fallback sequence* of cultures to link into the .wsi. It shall be clearly noted that the -cultures option does *not* tell the target computer's Windows Installer which language is contained in the .msi file (see (2) and (4)). (4) wix.chm shall contain a note that the target computer's Windows Installer doesn't care for the culture contained in the .msi at all, since e. g. a German target computer will install an Italian .msi file. *The culture defined in the .wxs / .msi file, is purely informative and has no impact on any technical outcome.* (4) It shall contain a note that light.exe makes no difference between comma and semicolon: *All* provided cultures are specifying the fallback sequence for light.exe, *independent* of the used separation character. *Only* Votive will make such a difference. (5) It shall contain a note what light.exe will do when *no* -culture option is provided. Using these five improvements I think it will be clear to beginners what the cultures stuff is good for and how it works like. Would be glad to find it contained in the next release of WiX (which, BTW, is a great product but just expects people to be MSI experts to use it *correctly*). :-) Regards Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Samstag, 24. Oktober 2009 23:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer There is an entire page dedicated to this topic in the WiX.chm called Specifying Cultures to Build. Can you provide suggestions as to what is not clear? On Sat, Oct 24, 2009 at 5:02 AM, Markus Karg markus.k...@gmx.net wrote: Thank you for this explanation. I wish this would be told in this clarity in the WiX documentation. -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 22. Oktober 2009 02:25 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Depending on where you read the information, different things come into play. In Votive (or anywhere else you are using the msbuild support), if you supply the string de,en;en for the cultures setting (I don't remember the casing or exact spelling of the property), you will get two MSIs built: one that uses German with English fallback (for any missing German strings) and English. Votive will call light.exe two times. In the light.exe command-line snipits as you list them below, in that third example, you get German, falling back to English, falling back to English. In other words, there is no real difference at all between the three command-lines. -Original Message- From: Markus KARG [mailto:markus.k
Re: [WiX-users] Beginner's Question on Multi Language Installer
Sascha, thank you for this tip. I will get the book. :-) Regards Markus -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Freitag, 23. Oktober 2009 02:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Pretty much all WiX documentation in general assumes a basic knowledge of Windows Installer technology. This isn't something immediately obvious to those new to WiX, since pretty much all other commercial installation software doesn't require this type of knowledge. I still have yet to find a better reference book than The Definitive Guide to Windows Installer - it's short (less than 300 pages), very simple and full of useful information. A lot of people jump straight into WiX without understanding how MSI works and get very confused very quickly, if you're familiar with how Windows Installer packages are put together WiX is pretty straightforward. If something isn't supported by Windows Installer, chances are it's not supported by WiX (with the exception of a few standard custom actions - http://wix.sourceforge.net/manual-wix3/standard_customactions.htm) Generally I refer to the Windows installer documentation (msi.chm) when I'm trying to figure out *what* it is I'm trying to accomplish, and then the WiX documentation for *how* to code it. There's a steep learning curve with Windows Installer and WiX, but it's definitely worth the effort :) Sascha On Thu, Oct 22, 2009 at 5:18 AM, Markus KARG markus.k...@gmx.net wrote: Well, frankly spoken that (really huge) tutorial is in part outdated, false and overly complex to understand, and it does things without explaining their intension or details in some chapters (what really confuses beginners). So after reading it two times I gave up and posted my question here... Thanks Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Mittwoch, 21. Oktober 2009 16:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Unfortunately, no. Have you read through the WiX tutorial http://wix.sf.net/tutorial? I thought it had a nice section on languages in MSIs. virtually, Rob Mensching - RobMensching.com LLC http://robmensching.com On Wed, Oct 21, 2009 at 3:13 AM, mrtn mrtn.frederik...@gmail.com wrote: In stead of a bootstrapper - selecting the wanted transform - is it possible for the .msi file itself to select a transform file? Maybe in a C++ CA? Blair-2 wrote: You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate
Re: [WiX-users] Beginner's Question on Multi Language Installer
I think the problem is that I have no knowledge with MSI before, so the tutorial expects things that MSI experts will know, but I just do not know (like what advertise means etc.). Regards Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Donnerstag, 22. Oktober 2009 02:51 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Interesting. I've never heard that feedback before. Thank you. On Wed, Oct 21, 2009 at 11:18 AM, Markus KARG markus.k...@gmx.net wrote: Well, frankly spoken that (really huge) tutorial is in part outdated, false and overly complex to understand, and it does things without explaining their intension or details in some chapters (what really confuses beginners). So after reading it two times I gave up and posted my question here... Thanks Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Mittwoch, 21. Oktober 2009 16:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Unfortunately, no. Have you read through the WiX tutorial http://wix.sf.net/tutorial? I thought it had a nice section on languages in MSIs. virtually, Rob Mensching - RobMensching.com LLC http://robmensching.com On Wed, Oct 21, 2009 at 3:13 AM, mrtn mrtn.frederik...@gmail.com wrote: In stead of a bootstrapper - selecting the wanted transform - is it possible for the .msi file itself to select a transform file? Maybe in a C++ CA? Blair-2 wrote: You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate that it is the neutral culture. I found out that by trial and error when adding the neutral fallback to each culture). What I expect to get from light.exe is one single .msi file containing all four language packs: German, French, English and Neutral. Light provides a single .msi so from the outside it seems to work. My target is that the Windows Installer at install time picks German, French or English strings automatically, depending on the user's current Region and Language Settings or instead picks neutral strings when the current user's local setting is neither German, French nor English (for example, Polish / Poland). While light v3 accepts the above line and does not complain in any way (not even ICE warnings), the Windows Installer picks Germany
Re: [WiX-users] Beginner's Question on Multi Language Installer
As a suggestion for both, the WiX manual and the WiX tutorial, I want to suggest to clearly point out this, and to make a clear distinction between votive interpretation and command line interpretation. I read it several times and did not find any hint that only votive is making a difference between command and semicolon, while the command line tool does not. Thanks for clarification. :-) Regards Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 22. Oktober 2009 02:28 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Votive (actually the MSBuild scripts) differentiates between semicolon and comma. It assumes the list separator is a semicolon and uses that to split the list into separate invocations of light.exe, ignoring the comma. If you change the default list separator character you may or may not break this implementation, I don't remember and I'm not taking the time to look it up right now. Light.exe doesn't care, it recognizes both the semicolon and the comma as separators and treats them identically. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Wednesday, October 21, 2009 11:04 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Markus KARG wrote: What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? It uses all of them to support fallback from available localization files. The WiX MSBuild targets use the list of cultures to generate one MSI per culture. I still don't get it. I always understood fallback in the sense of: -cultures:de,en what mean: If you don't find a word in German, then print the English word. But what I am talking about is: -cultures:de;en (semicolon but not comma). So what acutally will light do when I provide de,en;en? I mean, one must understand the details to correctly use it - and I WANT to correctly use it. :-) Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question on Multi Language Installer
Thank you for this explanation. I wish this would be told in this clarity in the WiX documentation. -Original Message- From: Blair [mailto:os...@live.com] Sent: Donnerstag, 22. Oktober 2009 02:25 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Depending on where you read the information, different things come into play. In Votive (or anywhere else you are using the msbuild support), if you supply the string de,en;en for the cultures setting (I don't remember the casing or exact spelling of the property), you will get two MSIs built: one that uses German with English fallback (for any missing German strings) and English. Votive will call light.exe two times. In the light.exe command-line snipits as you list them below, in that third example, you get German, falling back to English, falling back to English. In other words, there is no real difference at all between the three command-lines. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Wednesday, October 21, 2009 11:09 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Blair, but what is the difference then between: -culture:de,en -culture:de;en -culture:de,en;en ??? Thanks Markus It looks for the strings in all of the .wxl files sorting them in order of Culture, based on the order of the -Cultures parameter followed by the order the wxl files appear in the commandline. Example without using cultures, but placing the wxl files in numbered order: One.wxl: ...String Id=oneThis is the override/String... Two.wxl: ...String Id=oneThis is an override/String... ...String Id=twoThis is the second/String... ...String Id=fourThis is the fourth/String... Three.wxl: ...String Id=oneThis is the original/String... ...String Id=twoThis is another one/String... ...String Id=threeAnd yet another one/String... Then: Property Id=ONE Value=!(loc.one)/ Property Id=TWO Value=!(loc.two)/ Property Id=THREE Value=!(loc.three)/ Property Id=FOUR Value=!(loc.four)/ Results: ONE: This is the override TWO: This is the second THREE: And yet another one FOUR: This is the fourth If each of the above .wxl files had a culture of en-US and you added a fourth .wxl file with a culture of en-HK containing the following: ...String Id=oneWelcome to Hong Kong/String... ...String Id=threePlease come again/String... And then rebuilt using a -Cultures:en-HK,en-US parameter Results: ONE: Welcome to Hong Kong TWO: This is the second THREE: Please come again FOUR: This is the fourth In other words, in culture-order, search each WXL that exactly matches that culture until you find a matching string. Any given single MSI in the end understands just one language, based on the ProductLanguage tag (comes from produ...@language) and the content (a single value for each and every string). Everything else we do is intended to change that MSI's content so that a different language becomes apparent. That is where we re-link with different languages in order to generate the transforms that set our base MSI to those different languages. At that point, you can vary just the Cultures parameter and all WXL files that don't match the culture are ignored, so the command-line variation between the different links is minimal and easily controlled for. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 3:01 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Blair, thank you for your kind help. To sum up, multi-language support actually (or: officially) is not possible with a single .msi (or at least, not without either patching or transforming it before installation). What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Dienstag, 20. Oktober 2009 21:53 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues
Re: [WiX-users] Beginner's Question on Multi Language Installer
Markus KARG wrote: What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? It uses all of them to support fallback from available localization files. The WiX MSBuild targets use the list of cultures to generate one MSI per culture. I still don't get it. I always understood fallback in the sense of: -cultures:de,en what mean: If you don't find a word in German, then print the English word. But what I am talking about is: -cultures:de;en (semicolon but not comma). So what acutally will light do when I provide de,en;en? I mean, one must understand the details to correctly use it - and I WANT to correctly use it. :-) Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question on Multi Language Installer
Blair, but what is the difference then between: -culture:de,en -culture:de;en -culture:de,en;en ??? Thanks Markus It looks for the strings in all of the .wxl files sorting them in order of Culture, based on the order of the -Cultures parameter followed by the order the wxl files appear in the commandline. Example without using cultures, but placing the wxl files in numbered order: One.wxl: ...String Id=oneThis is the override/String... Two.wxl: ...String Id=oneThis is an override/String... ...String Id=twoThis is the second/String... ...String Id=fourThis is the fourth/String... Three.wxl: ...String Id=oneThis is the original/String... ...String Id=twoThis is another one/String... ...String Id=threeAnd yet another one/String... Then: Property Id=ONE Value=!(loc.one)/ Property Id=TWO Value=!(loc.two)/ Property Id=THREE Value=!(loc.three)/ Property Id=FOUR Value=!(loc.four)/ Results: ONE: This is the override TWO: This is the second THREE: And yet another one FOUR: This is the fourth If each of the above .wxl files had a culture of en-US and you added a fourth .wxl file with a culture of en-HK containing the following: ...String Id=oneWelcome to Hong Kong/String... ...String Id=threePlease come again/String... And then rebuilt using a -Cultures:en-HK,en-US parameter Results: ONE: Welcome to Hong Kong TWO: This is the second THREE: Please come again FOUR: This is the fourth In other words, in culture-order, search each WXL that exactly matches that culture until you find a matching string. Any given single MSI in the end understands just one language, based on the ProductLanguage tag (comes from produ...@language) and the content (a single value for each and every string). Everything else we do is intended to change that MSI's content so that a different language becomes apparent. That is where we re-link with different languages in order to generate the transforms that set our base MSI to those different languages. At that point, you can vary just the Cultures parameter and all WXL files that don't match the culture are ignored, so the command-line variation between the different links is minimal and easily controlled for. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 3:01 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Blair, thank you for your kind help. To sum up, multi-language support actually (or: officially) is not possible with a single .msi (or at least, not without either patching or transforming it before installation). What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Dienstag, 20. Oktober 2009 21:53 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country
Re: [WiX-users] Beginner's Question on Multi Language Installer
languages in order to generate the transforms that set our base MSI to those different languages. At that point, you can vary just the Cultures parameter and all WXL files that don't match the culture are ignored, so the command-line variation between the different links is minimal and easily controlled for. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 3:01 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Blair, thank you for your kind help. To sum up, multi-language support actually (or: officially) is not possible with a single .msi (or at least, not without either patching or transforming it before installation). What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Dienstag, 20. Oktober 2009 21:53 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate that it is the neutral culture. I found out that by trial and error when adding the neutral fallback to each culture). What I expect to get from light.exe is one single .msi file containing all four language packs: German, French, English and Neutral. Light provides a single .msi so from the outside it seems to work. My target is that the Windows Installer at install time picks German, French or English strings automatically, depending on the user's current Region and Language Settings or instead picks neutral strings when the current user's local setting is neither German, French nor English (for example, Polish / Poland). While light v3 accepts the above line and does not complain in any way (not even ICE warnings), the Windows Installer picks Germany *always* when running the resulting .msi file on my laptop -- despite the current setting of Polish / Poland in the Region and Language Settings control panel. :-( Can anybody tell me what my fault is? Thanks Markus - - - - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from
Re: [WiX-users] Beginner's Question on Multi Language Installer
Well, frankly spoken that (really huge) tutorial is in part outdated, false and overly complex to understand, and it does things without explaining their intension or details in some chapters (what really confuses beginners). So after reading it two times I gave up and posted my question here... Thanks Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Mittwoch, 21. Oktober 2009 16:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Unfortunately, no. Have you read through the WiX tutorial http://wix.sf.net/tutorial? I thought it had a nice section on languages in MSIs. virtually, Rob Mensching - RobMensching.com LLC http://robmensching.com On Wed, Oct 21, 2009 at 3:13 AM, mrtn mrtn.frederik...@gmail.com wrote: In stead of a bootstrapper - selecting the wanted transform - is it possible for the .msi file itself to select a transform file? Maybe in a C++ CA? Blair-2 wrote: You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate that it is the neutral culture. I found out that by trial and error when adding the neutral fallback to each culture). What I expect to get from light.exe is one single .msi file containing all four language packs: German, French, English and Neutral. Light provides a single .msi so from the outside it seems to work. My target is that the Windows Installer at install time picks German, French or English strings automatically, depending on the user's current Region and Language Settings or instead picks neutral strings when the current user's local setting is neither German, French nor English (for example, Polish / Poland). While light v3 accepts the above line and does not complain in any way (not even ICE warnings), the Windows Installer picks Germany *always* when running the resulting .msi file on my laptop -- despite the current setting of Polish / Poland in the Region and Language Settings control panel. :-( Can anybody tell me what my fault is? Thanks Markus - --- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
[WiX-users] Beginner's Question on Multi Language Installer
Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate that it is the neutral culture. I found out that by trial and error when adding the neutral fallback to each culture). What I expect to get from light.exe is one single .msi file containing all four language packs: German, French, English and Neutral. Light provides a single .msi so from the outside it seems to work. My target is that the Windows Installer at install time picks German, French or English strings automatically, depending on the user's current Region and Language Settings or instead picks neutral strings when the current user's local setting is neither German, French nor English (for example, Polish / Poland). While light v3 accepts the above line and does not complain in any way (not even ICE warnings), the Windows Installer picks Germany *always* when running the resulting .msi file on my laptop -- despite the current setting of Polish / Poland in the Region and Language Settings control panel. :-( Can anybody tell me what my fault is? Thanks Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Beginner's Question on Multi Language Installer
Blair, thank you for your kind help. To sum up, multi-language support actually (or: officially) is not possible with a single .msi (or at least, not without either patching or transforming it before installation). What I do not understand under this circumstances is: Why can I add a LIST of cultures to light.exe? I mean, what does it actually do with all the cultures if actually always taking just the first in the list? Thanks Markus -Original Message- From: Blair [mailto:os...@live.com] Sent: Dienstag, 20. Oktober 2009 21:53 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate that it is the neutral culture. I found out that by trial and error when adding the neutral fallback to each culture). What I expect to get from light.exe is one single .msi file containing all four language packs: German, French, English and Neutral. Light provides a single .msi so from the outside it seems to work. My target is that the Windows Installer at install time picks German, French or English strings automatically, depending on the user's current Region and Language Settings or instead picks neutral strings when the current user's local setting is neither German, French nor English (for example, Polish / Poland). While light v3 accepts the above line and does not complain in any way (not even ICE warnings), the Windows Installer picks Germany *always* when running the resulting .msi file on my laptop -- despite the current setting of Polish / Poland in the Region and Language Settings control panel. :-( Can anybody tell me what my fault is? Thanks Markus --- - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
