Re: [WiX-users] Merge existing MSIs into a single MSI as features
If you are going to use a hybrid approach, then merge modules will get you what you want. If you can implement Wi across the board, then you should use .wixlibs. They're much better for your mental health, and more capable to boot. Give us more information, and there are plenty of people here who can give you advice. Chris On Tue, Sep 2, 2008 at 4:18 AM, si <[EMAIL PROTECTED]> wrote: > Hi Troy, > > > Each tool will be independently updated, and versioned, sometimes needing > to > > be installed individually, sometimes as part of a package. When installed > as > > a package, they may need to be updated individually, as part of that > > package... > ... > > I'm not completely clear on merge modules and how those work, but I > imagine > > that's what I want to do here. > > Yes, that seems the correct approach. We use merge modules for our > various components (framework, terminology, reporting, etc) and then > add them as features to our products. The tools are maintained and > versioned separately from the products themselves. > > For the scenario where the tool itself is installed separately, you > will need an installer for the tool, but that just has to reference > the tools merge module. > > There is some work converting an MSI to an MSM, but not a lot; change > the project type in WiX properties and wrap the > Package/Directory/Component elements up in a Module. > > Since you're using .NET and new to WiX, if I can offer some advice; > ensure you understand the difference between AssemblyVersion and > AssemblyFileVersion attributes. WiX uses AssemblyFileVersion - well, > at least the Major.Minor.Build parts, but if you strong name your > assemblies and reference the full binding path, you probably wont want > to change the AssemblyVersion value as often as you change > AssemblyFileVersion (even if the process is automated). Otherwise > you'll be needing to update configuration files a lot more often than > is probably necessary. We learnt the hard way :) > > - > 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 existing MSIs into a single MSI as features
Hi Troy, > Each tool will be independently updated, and versioned, sometimes needing to > be installed individually, sometimes as part of a package. When installed as > a package, they may need to be updated individually, as part of that > package... ... > I'm not completely clear on merge modules and how those work, but I imagine > that's what I want to do here. Yes, that seems the correct approach. We use merge modules for our various components (framework, terminology, reporting, etc) and then add them as features to our products. The tools are maintained and versioned separately from the products themselves. For the scenario where the tool itself is installed separately, you will need an installer for the tool, but that just has to reference the tools merge module. There is some work converting an MSI to an MSM, but not a lot; change the project type in WiX properties and wrap the Package/Directory/Component elements up in a Module. Since you're using .NET and new to WiX, if I can offer some advice; ensure you understand the difference between AssemblyVersion and AssemblyFileVersion attributes. WiX uses AssemblyFileVersion - well, at least the Major.Minor.Build parts, but if you strong name your assemblies and reference the full binding path, you probably wont want to change the AssemblyVersion value as often as you change AssemblyFileVersion (even if the process is automated). Otherwise you'll be needing to update configuration files a lot more often than is probably necessary. We learnt the hard way :) - 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 existing MSIs into a single MSI as features
All, First -- I'm new to the list, so, nice to meet you. My question, in a nutshell, is what is the best way to go about dealing with this situation I have? The situation its, that I've got a bunch of tools which are related to each other as part of a software platform. They are all various utilities, and each one currently has it's own MSI installer. I want to package a bunch of them up into a single MSI with each install as a feature in that MSI. The overall goal is to be able to flexibly deploy the tools in various groups. The first step is to make one big installer with lots of features, then in the future make various packages with certain subsets of the tools. Each tool will be independently updated, and versioned, sometimes needing to be installed individually, sometimes as part of a package. When installed as a package, they may need to be updated individually, as part of that package... So, that's the problem... If I were starting fresh, writing it from the ground up in WiX, I know enough about it to include each program's install as it's own feature, and put it all together in the a big package. I think I understand enough about fragments that I could keep each "highest level" fragment (ie, each top level feature/seperate program install), in it's own fragement file, then have one wxs file that has a the big package, and a wxs file for each seperate package, then build them all at the same time... That doesnt' quite seem like what I want to do though. I'm not completely clear on merge modules and how those work, but I imagine that's what I want to do here. Would I want to compile each current installer to a MSP, instead of an MSI, then some how link each MSP in as a feature in a big package? Can that be done? If so, how do I convert the MSI to a MSP without completely decompiling it with dark? Would I be better served to just re-create the installs in WiX (the MSIs were made with either .Net Setup projects or an old version of InstallShield) as merge module projects, generating the MSPs up-front? What would a package that used MSPs as features look like? Sorry if my message is lengthy and showing my obvious lack of experience with this matter. I promise to pay attention and learn from your responses, so that I can get back to work cleaning up our company's installer mess, instead of sending lengthy emails to mailing-lists. Thanks, Troy - 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
