19. Something like MajorUpgrade for the RememberMe pattern. 20. Support in thmutil for using variables when laying out the UI. 21. Somehow give managed BAs access to balutil.
On Sun, Aug 10, 2014 at 6:18 AM, Neil Sleightholm <n...@x2systems.com> wrote: > +1 for 18 > It would be nice to have finer grained support for disabling warnings, for > example, disabling ICE61 to allow same version upgrades means that some of > the other useful tests are disabled. > > -----Original Message----- > From: Rob Mensching [mailto:r...@firegiant.com] > Sent: 09 August 2014 05:12 > To: WiX toolset developer mailing list > Subject: Re: [WiX-devs] 16 things I'd like to see in WiX v4.x > > 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
