And regarding #10, if you've ever tried to make such an MSI you'll find it
can't pass ICE validation and do anything useful. It's a pretty lame feature,
honestly. Seems combo 32- and 64-bit package support would've been a better use
of resources, but it didn't play out that way.
- Heath from his Surface Pro
From: Rob Mensching
Sent: Friday, August 8, 2014 11:17 PM
To: Windows Installer XML toolset developer mailing list
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