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

Reply via email to