[WiX-users] Questions about WiX V3
I installed the latest beta of WiX 3 because I want to use the Visual Studio
integration. I've run into some problems getting started. I'm hoping that
I can get some assistance.
1) The text of error messages are not being displayed in VS 2005. When the
build fails, I have to build from a command line to actually read the build
error. This is a known bug that I read about in other messages in the list
archive, but it is extremely frustrating for someone trying to get started
with WiX.
2) I'd like to have a UI in my installer. To get started, I was going to
use the WixUI. Following the samples for WiX 2, I included the following:
Light outputs:
Product.wxs(45) : error LGHT0094 : Unresolved reference to symbol
'WixUI:WixUI_InstallDir' in section
'Product:{6D829382-8D41-43C9-AC80-7B98DA1BBD72}'.
How do I reference WixUI? Or has it been removed?
I suppose I could build my own dialogs in an RC file and then use Tallow to
create WiX dialogs. Which brings me to #3.
3) Is Tallow still a part of WiX 3? The executable is not anywhere in the
installation. Are its features now included somewhere else?
-Jamey
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Questions about WiX V3
> James Minnis wrote: > > 1) The text of error messages are not being displayed in VS 2005. When > the > > build fails, I have to build from a command line to actually read the > build > > error. This is a known bug that I read about in other messages in the > list > > archive, but it is extremely frustrating for someone trying to get > started > > with WiX. > > > > You can also see it in the output window. Not in VS 2005 see bug #2009076 > > 3) Is Tallow still a part of WiX 3? The executable is not anywhere in > the > > installation. Are its features now included somewhere else? > > > > Heat.exe. Thanks. -Jamey - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Questions about WiX V3
> James Minnis wrote: > > 1) The text of error messages are not being displayed in VS 2005. When > the > > build fails, I have to build from a command line to actually read the > build > > error. This is a known bug that I read about in other messages in the > list > > archive, but it is extremely frustrating for someone trying to get > started > > with WiX. > > > > You can also see it in the output window. Not in VS 2005 see bug #2009076 > > 3) Is Tallow still a part of WiX 3? The executable is not anywhere in > the > > installation. Are its features now included somewhere else? > > > > Heat.exe. Thanks. -Jamey - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX with Visual Studio 2008 Isolated?
I just installed the Isolated edition of VS 2008 to use IronPython. Will WiX V3 work with that? If so, how would I configure it to do so? -Jamey - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Merge Module Help
I'm working on a fairly large installer. It contains roughly 7000 files in 165 folders and a total of 670 MB of uncompressed data. Needless to say, I'm generating the files, components, and directories using Heat. Right now, I'm generating a merge module WXS file using Heat and then using the Merge and MergeRef elements in my main installer. This is all working correctly. I have several questions related to this: 1) I want to create shortcuts to several of the files in the merge module. I'm doing this currently in a start menu shortcuts component in the main installer. However, I cannot figure out how to reference the directories in the merge module in the main project (I get an empty string when I try to reference them like I do the directories in the main installer project). How do I reference the directories? Or is there a better way to do this? 2) The components in the merge module are generated with GUIDs. If I regenerate the merge module WXS file using Heat (e.g. if I add files), those GUIDs change. How will this affect patches? Will the patch recognize the files as being the same, or will it consider all of the files changed and overwrite everything? Will I need to add files manually to the merge module WXS file to make patching work correctly? -Jamey - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
For major updates, changing the GUIDs should not matter as it does an uninstall of the old version then an install of the new version. I just won't provide a patch to make that leap. This should be acceptable because it will be infrequent. For smaller changes, a minor upgrade via patch should be doable with hand updates, but it is very much not ideal. The biggest problem with this is the lag in the Visual Studio IDE when dealing with a roughly 3 MB XML file for the merge module. I can mitigate this to some extent by breaking it into several smaller projects by subdirectory, but I'm unfortunately dealing with a directory and file structure that cannot be changed (this installer is for a mod for a video game). I'm surprised that Heat doesn't have the functionality of leaving the existing GUIDs in place. I just presumed I wasn't seeing how to do it. I'm familiar with merge modules from developing MSIs for work, so that was my first thought when looking at Heat's options. I haven't been able to find any documentation on how to create a wixlib with Heat or how to include a wixlib in a primary project. A sample project featuring a wixlib would be even better. Do either documentation or a sample project exist somewhere? -Jamey > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Christopher Karper > Sent: Friday, July 18, 2008 5:52 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > I can't really answer intelligently to question #1, as to question #2, > I'll > do my best. > > Heat is really built for initial import functionality, not continual > maintenance. You do not want your GUIDs changing on your components with > each build, it will turn upgrades into a nightmare, and will make patching > just about impossible, IMO. The "suggested" method, is to use heat.exe > to > build your .wxs up front, then manually maintain the .wxs file as part of > your development process from there on out. If someone adds an artifact > to > a project in a future version, they need to add it to the installer > definition as well. > > If you have the ability to go pure Wix with your installers, then you can > break this into manageable chunks using a .wixlib project for each major > subsystem, and having one parent .msi project link them all together. > This > is similar, but superior, to building .msm files and importing those in. > If your "parent" project is not Wix, then you're stuck in the same boat I > am, building .msm's. > > Either way you're stuck making manual changes to the .wxs files to keep > them > in sync with your project's outputs and required support files. I > *really* > wish this wasn't the case, as the whole point of using an IDE (for me) is > to > manage all the grunt work like that, but there are some pretty substantial > complexities making it a pretty large undertaking that the team just > hasn't > gotten to yet. > > Chris > > On Fri, Jul 18, 2008 at 7:53 PM, James Minnis <[EMAIL PROTECTED]> > wrote: > > > I'm working on a fairly large installer. It contains roughly 7000 files > in > > 165 folders and a total of 670 MB of uncompressed data. Needless to > say, > > I'm generating the files, components, and directories using Heat. > > > > Right now, I'm generating a merge module WXS file using Heat and then > using > > the Merge and MergeRef elements in my main installer. This is all > working > > correctly. I have several questions related to this: > > > > 1) I want to create shortcuts to several of the files in the merge > module. > > I'm doing this currently in a start menu shortcuts component in the main > > installer. However, I cannot figure out how to reference the > directories > > in > > the merge module in the main project (I get an empty string when I try > to > > reference them like I do the directories in the main installer project). > > How do I reference the directories? Or is there a better way to do > this? > > > > 2) The components in the merge module are generated with GUIDs. If I > > regenerate the merge module WXS file using Heat (e.g. if I add files), > > those > > GUIDs change. How will this affect patches? Will the patch recognize > the > > files as being the same, or will it consider all of the files changed > and > > overwrite everything? Will I need to add files manually to the merge > > module > > WXS file to make patching work correctly? > > > > -Jamey > > > > > > ---
Re: [WiX-users] Merge Module Help
That's unfortunate. I could probably write something to keep the GUIDs standardized, but it would be more work than it's worth for a hobby project I'm doing in my spare time. Most of our updates will only involve changes to text files rather than adding or removing files. That implies a patch to me. If we have to add or remove more than a small number of files, I guess we'll bite the bullet and do a major upgrade. It isn't ideal but it will work. I submitted a feature request (#2022259). Hopefully it will get some attention. -Jamey > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Luke Bakken > Sent: Saturday, July 19, 2008 8:09 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > >> I'm surprised that Heat doesn't have the functionality of leaving the > >> existing GUIDs in place. I just presumed I wasn't seeing how to do it. > > > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > > managing GUIDs. I've never used it so I can't vouch for it, but it may > > be what you're looking for. > > > > Hm. On re-reading that article it appears that Paraffin doesn't > actually manage your GUIDs. You could accomplish something custom for > your app using heat.exe and a database of some sort. It's definitely a > missing part of the toolset. > > Where I work, teams that deal with large numbers of components just do > major upgrades all the time. We figured that we would cross the GUID > bridge when we had to for patches. > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
I couldn't find a feature request for that with a couple of quick searches, but it is possible that I missed it. This is definitely not a trivial problem to solve, but I don't see why it would be an intractable one. For a first pass, I'd generate a fragment WXS file where one element is a hash or CRC of the rest of the file. As long as the existing file generates the same hash/CRC, the file is unmodified and you can safely import the existing autogenerated XML structures. You can then do a diff with the existing file/folder structure and only modify where necessary. I'd make doing a merge with the existing file a new command line switch for Heat. Obviously, there are a lot of implementation details I'm sweeping under the rug, but conceptually I don't see why the problem is really hard, assuming that the first pass can only work with unmodified output of the Harvester. It wouldn't make everyone happy, but it is a method which most people could work with. -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Rob Mensching > Sent: Saturday, July 19, 2008 11:01 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > This is a constant feature request (I'm surprised there isn't a feature > request already). Generating Component GUIDs that follow the Component > Rules is an *extremely hard* problem to solve perfectly. The auto- > generated Component GUIDs is pretty good (assuming it doesn't have any > bugs) but has a number restrictions. Heat already supports those with the > "-ag" switch. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of James Minnis > Sent: Saturday, July 19, 2008 09:15 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Merge Module Help > > That's unfortunate. > > I could probably write something to keep the GUIDs standardized, but it > would be more work than it's worth for a hobby project I'm doing in my > spare > time. > > Most of our updates will only involve changes to text files rather than > adding or removing files. That implies a patch to me. If we have to add > or > remove more than a small number of files, I guess we'll bite the bullet > and > do a major upgrade. It isn't ideal but it will work. > > I submitted a feature request (#2022259). Hopefully it will get some > attention. > > -Jamey > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Luke Bakken > > Sent: Saturday, July 19, 2008 8:09 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > >> I'm surprised that Heat doesn't have the functionality of leaving the > > >> existing GUIDs in place. I just presumed I wasn't seeing how to do > it. > > > > > > There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for > > > managing GUIDs. I've never used it so I can't vouch for it, but it may > > > be what you're looking for. > > > > > > > Hm. On re-reading that article it appears that Paraffin doesn't > > actually manage your GUIDs. You could accomplish something custom for > > your app using heat.exe and a database of some sort. It's definitely a > > missing part of the toolset. > > > > Where I work, teams that deal with large numbers of components just do > > major upgrades all the time. We figured that we would cross the GUID > > bridge when we had to for patches. > > > > > - > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with M
Re: [WiX-users] Merge Module Help
Based on what people said in earlier messages, I'm migrating to using a wixlib with a fragment generated by Heat. A lack of samples or useful documentation had left me doing trial and error to figure how. If you think that there is a better method, please let me know what it is. :) -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Bob Arnson > Sent: Saturday, July 19, 2008 10:22 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > James Minnis wrote: > > Right now, I'm generating a merge module > > Do you have a specific need for a merge module? (i.e., are you sharing > it with others so they can create installers?) If not, avoid merge > modules. They needlessly complicate things, as you're finding out with #1. > > > 1) I want to create shortcuts to several of the files in the merge > module. > > I'm doing this currently in a start menu shortcuts component in the main > > installer. However, I cannot figure out how to reference the > directories in > > the merge module in the main project (I get an empty string when I try > to > > reference them like I do the directories in the main installer project). > > How do I reference the directories? Or is there a better way to do > this? > > > > You can't. Merge modules are supposed to be self-contained, so if you > want shortcuts, define them in the merge module. Or don't use merge > modules. > > > 2) The components in the merge module are generated with GUIDs. If I > > regenerate the merge module WXS file using Heat (e.g. if I add files), > those > > GUIDs change. How will this affect patches? Will the patch recognize > the > > files as being the same, or will it consider all of the files changed > and > > overwrite everything? Will I need to add files manually to the merge > module > > WXS file to make patching work correctly? > > > > You won't be able to patch. The WiX approach is to use stable GUIDs > (heat's -ag switch). But with 7000 files, that's going to cause some > long pauses during costing. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
That's an excellent point. The devil, as always, is in the details of when someone screws up. Since Murphy is looking out for us, it never manages to work ideally. :) -Jamey [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of Rob Mensching > Sent: Saturday, July 19, 2008 1:15 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module Help > > I think you've over-simplified the Component Rules. Once a Component > contains a set of Resources, those Resources must ship in that Component > with that GUID forever. Resources are files, registry keys, shortcuts, > etc. (basically almost everything that can be a child of the Component > element). > > The case that gets really tricky is to have one build where a Resource > disappears (usually accidentally) then the next build where the Resource > comes back. It needs to get the same Component and GUID. > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:wix-users- > [EMAIL PROTECTED] On Behalf Of James Minnis > Sent: Saturday, July 19, 2008 13:08 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Merge Module Help > > I couldn't find a feature request for that with a couple of quick > searches, > but it is possible that I missed it. > > This is definitely not a trivial problem to solve, but I don't see why it > would be an intractable one. For a first pass, I'd generate a fragment > WXS > file where one element is a hash or CRC of the rest of the file. As long > as > the existing file generates the same hash/CRC, the file is unmodified and > you can safely import the existing autogenerated XML structures. You can > then do a diff with the existing file/folder structure and only modify > where > necessary. I'd make doing a merge with the existing file a new command > line > switch for Heat. > > Obviously, there are a lot of implementation details I'm sweeping under > the > rug, but conceptually I don't see why the problem is really hard, assuming > that the first pass can only work with unmodified output of the Harvester. > It wouldn't make everyone happy, but it is a method which most people > could > work with. > > -Jamey > > [EMAIL PROTECTED] > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of Rob Mensching > > Sent: Saturday, July 19, 2008 11:01 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Merge Module Help > > > > This is a constant feature request (I'm surprised there isn't a feature > > request already). Generating Component GUIDs that follow the Component > > Rules is an *extremely hard* problem to solve perfectly. The auto- > > generated Component GUIDs is pretty good (assuming it doesn't have any > > bugs) but has a number restrictions. Heat already supports those with > the > > "-ag" switch. > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:wix-users- > > [EMAIL PROTECTED] On Behalf Of James Minnis > > Sent: Saturday, July 19, 2008 09:15 > > To: 'General discussion for Windows Installer XML toolset.' > > Subject: Re: [WiX-users] Merge Module Help > > > > That's unfortunate. > > > > I could probably write something to keep the GUIDs standardized, but it > > would be more work than it's worth for a hobby project I'm doing in my > > spare > > time. > > > > Most of our updates will only involve changes to text files rather than > > adding or removing files. That implies a patch to me. If we have to > add > > or > > remove more than a small number of files, I guess we'll bite the bullet > > and > > do a major upgrade. It isn't ideal but it will work. > > > > I submitted a feature request (#2022259). Hopefully it will get some > > attention. > > > > -Jamey > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:wix-users- > > > [EMAIL PROTECTED] On Behalf Of Luke Bakken > > > Sent: Saturday, July 19, 2008 8:09 AM > > > To: General discussion for Windows Installer XML toolset. > > > Subject: Re: [WiX-users] Merge Module Help > > > > > > >> I'm surprised that Heat doesn't have the functionality of leav
