On 09-Aug-14 00:12, Rob Mensching wrote: > 3. Currently following MSI documentation, not sure what you're thinking here. Just wondering if there's more we can support and stay safe. Nothing comes to mind, but thought it worth the exercise.
> 4. Yes, definitely the ConditionRef interested to discuss the other. Given that *Package handle conditions as attribute values, we need some way to indicate a reference. Three things came to mind: 1. A new *ConditionRef[Id] attribute. Seems consistent with *Package and (almost) consistent with other *Ref elements, transmogrified a bit. 2. Child *ConditionRef elements. Less consistent with other *Condition attributes on *Package. Might want to do this anyway, and end up with DetectCondition[Ref] and InstallCondition[Ref] to use CDATA. 3. Magic syntax, such as InstallCondition="@FooInstallCondition" or some such. Lacks discoverability and if it's actually pulling in a whole section, seems too "soft." > 8. Actually, want to deprecate "*" and add a new attribute that tries to > generate the ProductCode based on properties (Manufacturer, UpgradeCode?) and > the appropriate part of the ProductVersion depending whether new > Product/@UpgradeScheme (or better name) attribute says to support minor > upgrades or not. Basically, the ProductCode changes appropriately as the > version number changes. Product/@UpgradeScheme could default to > "majorUpgrade" and change with ever version number change. Obviously, not a > fully thought out idea but this is the way I'd like to go. Nice. We'll need a WIP for this one. :) > 10. I care little for this MSI feature and would do everything on this list > and other things before it, personally. If you and Heath are both opposed, I have to support just to keep the universe in alignment. :) I don't actually care about the feature, I just want to make sure we can clean up things like @InstallPrivileges and still create a frankenpackage for those who want to do so. > 12. Yes, we already warn when you set it too low. We could default to 310 > since WinXPSP2 has that, right? That's 3.0; SP3 has 3.1. Maybe we make that the default and still support @InstallerVersion but support "vM.M" syntax? > 13. Yes. Default to per-machine and only have people use this to force a > per-user package? Maybe push per-user to the Product or new ARP element and > only have people set Package element to configure the strings in Summary > Information (where the default is almost always fine). +1 on both. > 14. Probably a good idea. Think anyone will scream if we force them to add a > GUID that technically isn't required by Windows Installer? It is already a > warning. Maybe we generate one if it's not present (and still warn). That way when they realize they're screwed, we swoop in and save their very souls. :) > 16. Please. It would make the gitsetup Bundle we use at FireGiant as small as > the "official git release". <smile/> Size matters not, except where it does. LZMA is slower but getting multithreaded compression could more than compensate for that. > 18. Re-implement ICEs in the WiX toolset (as Validators or more native > compiler/linker/binder checks) to remove dependency on .CUBs (that are slow > and error prone). Let's turn up the Heat and Melt the ICEs. I'd like to pull the existing validations out into a separate validator. I think the current extension interface needs some work to cover everything we have today. -- sig://boB http://joyofsetup.com/ ------------------------------------------------------------------------------ _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
