Thanks for the detail in the bug reports. I’ll take a look at the right fixes soon.

Then I’m getting warning that the short file name ‘some name’ was generated for multiple files.

But if I will specify Component Id equal to File Id manually, then this warning is gone.

It seems to me generation of short file names happens before Component Id equals to resource Id.

And I got error message that: file with assembly=”.net” should specify KeyPath=”yes”, but it is only one file in component which should be by default key for that component. Is it an issue or by design?

All the language changes are at the WiX level; they don’t affect how MSI itself works, so you still have to follow all of its rules, like for policy files.

Overall thank you for your investment in Wix code!

I have a small question about previous simplifying in wix language(http://www.joyofsetup.com/2009/12/31/simplifying-wix-component-authoring/):
is it possible also to simplify components with publisher policy files? Because by msi rules config and assembly (policy) should be in the same component. Will “policy” components be treated as multi-file components?

You also have to specify a Product/@UpgradeCode attribute.

Just to make things a bit clearer for me.

In order for major upgrades to properly work, I need to do the following:

- Set the product Id to *
- Add the major upgrade section and add a Downgrade message.

This should be sufficient and should allow major upgrades to happen?

Thanks!

Marais

It’s actually consistent with other “shortcut” authoring, like SetDirectory and SetProperty, in the use of attributes rather than child elements.

I find unnecessary nesting to be one of the uglier XMLisms. An enumeration is the simplest way of expressing mutually-exclusive choices. It’s more discoverable and makes it impossible to create authoring that’s syntactically correct but semantically invalid (even if the compiler would discover it).