Quantcast

Feature suggestion: Dynamic Burn bundle

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Feature suggestion: Dynamic Burn bundle

Jiri Tomek
I understand current Wix team statement that it's not possible to build Burn bundle with products A,B and C and then during execution get somewhere product D and install it in the bundle. The reason is security and I get it.

But, what about allowing dynamic bundle where security is provided by certificate used to sing individual MSIs?

Example: I create a bundle to which I provide a certificate that will be used for all packages that bundle can install. Bundle itself will have no payload. The MBA will contact download server and provides user the list of available products or updates to install. User selects items, MBA will download them and call Burn Engine to add these items to install chain. Burn checks signature of all these items and accepts them only if it's valid for the certificate used during compilation. This way it's secure and it allows to build really rich install/update platform that is fully data-driven.

Current limitation which allows only installation of packages that are known during build-time is so limiting in my use case that I'm not able to use Burn. I would have to build new bundle every few days, have multiple of them to cover different product combinations etc. Being able to leverage Burn install platform with dynamic data would be just awesome.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature suggestion: Dynamic Burn bundle

Phill Hogland
Did you file your Feature request here?

Did you consider using a "addon" bundle?  I currently create a bundle with A, B, and C.  Then later I create another bundle with D (which releases on a different schedule).  (And much later again I can add D into the original base bundle and not need the 'addon' bundle anymore.).

In the 'base' bundle I have:
<RelatedBundle Action='Detect' Id='A_GUID_Used_To_ID_This_Base_Bundle' />
(as a matter of practice I add the above to every bundle I produce, whether I plan to create an addon or not.)

Then in the "addon" bundle I have:
    <RelatedBundle Action='Addon' Id='The_Same_GUID_Used_To_ID_The_Base_Bundle' />

I did not need to add any code to the mba, although there are handlers if you need to do something special.  Once the 'Addon' bundle is installed it becomes a part of the base bundle and is uninstalled or repaired as part of that base bundle.  Using the RelatedBundle element seems like a simple solution to what you are trying to achieve.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature suggestion: Dynamic Burn bundle

Jiri Tomek
This post has NOT been accepted by the mailing list yet.
I will post request to mentioned page, thanks for pointing that out.

To your suggestion - that would mean that I need to build an addon package for every new release, patch, hotfix etc. That is little cumbersome. Having more control over install chain from within MBA and still keeping security high enough to not compromise it would be really handy.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature suggestion: Dynamic Burn bundle

TABleeker
This post has NOT been accepted by the mailing list yet.
I see mention of "security" as to reasons why this will not be done in Wix, but I cannot find the security discussions so I can understand the concerns.

I think what users, or at least me, are looking for is something like the Windows Platform Installer which uses a XML file loaded at run time from a safe location to completely define all the available packages to install.
Loading...