Yes, on many fronts (of course, we've talked about bits of this list for a long time) plus a couple extras:
1. Yes, probably do #15 first? 2. Yes, and deprecate setting the properties directly. 3. Currently following MSI documentation, not sure what you're thinking here. 4. Yes, definitely the ConditionRef interested to discuss the other. 5. Agreed, would be nice to have a better design for this especially taking into account Bundles. 6. Yes, this I mostly consider a bug. Guys at FireGiant fixed a bunch of these but there are still more. 7. Yes, please. 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. 9. Yeah. 10. I care little for this MSI feature and would do everything on this list and other things before it, personally. 11. Shouldn't be exposed anyway. Probably should be deprecated in WiX v3.10. 12. Yes, we already warn when you set it too low. We could default to 310 since WinXPSP2 has that, right? 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). 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. 15. Yes, would be great to have that finished. 16. Please. It would make the gitsetup Bundle we use at FireGiant as small as the "official git release". <smile/> A couple more: 17. Turn "Info" classes in the Binder into proper "Row" classes. 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). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -----Original Message----- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Friday, August 8, 2014 4:42 PM To: WiX toolset developer mailing list Subject: [WiX-devs] 16 things I'd like to see in WiX v4.x Here's a quick list of things that would be nice to clean up as part of a new major release. Most of these are additive so could be done throughout the v4.x series. Anyone think any are a bad idea? I'll end up writing at least a few WIPs for these, though I might cheat and combine a few. 1. Provide bundle equivalents for locator properties in extensions (NetFx and VS especially). 2. Abstract ARP (i.e., no properties) -- with same(?) schema for bundles and packages. 3. Is there more we can do to expand generated GUID support? 4. Support conditions as things you can reference: e.g., ConditionRef for Products, @InstallConditionRef for MsiPackage. (Better reuse -v- preprocessor variables and include files.) 5. Consider what's necessary to create a "release" concept by re-binding: i.e., project-level method of creating DVD -v- Web layouts. 6. Generate @Id for everything that doesn't already do so. 7. BundlePackage element to handle detection and defaults. 8. Product/@Id="*" default. 9. Remove Package/@InstallPrivileges. 10. Cover MSI v5 mutable package scope in Package/@InstallScope. 11. Package/@AdminImage is misused as "please help my custom action elevate." Do we need it in 2014? (i.e., product/package distinction not terribly interesting; do we need the ability to create any package -- e.g., @ShortNames) 12. Can we automate Package/@InstallerVersion? 13. Can we default Package entirely? This is a commonly-overspecified element, since it's required and has lots of fiddly bits that show up in Intellisense. 14. Product/@UpgradeCode required. 15. Refactor Burn searches to also be usable as custom actions from packages (see also #1). 16. LZMA compression for Burn containers. (Better compression than CAB and some implementations offer multithreaded compression, which CAB does not and is a perf sink for bundles with an attached container). -- sig://boB http://joyofsetup.com/ ------------------------------------------------------------------------------ _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
