Upgrade logic is still on the server. The server decides what to serve back
at the url.
With this scheme it is harder to do your scenario if you have a static
file. Although, the straight forward fix with static URLs is to release a
1.9.1 that fixes the update url in the Bundle. Plus, that scenario *does*
feel a bit contrived. <smile/>
I'm just wondering if its easier to just push up a new bundle than to have
to push up a new bundle and update another file? Have to document another
file format, although maybe we could just put the URL in a text file... but
if we did that, that's the same as having the server just do a 302 itself.
Which is why I end up back at just pointing to the bundle. <smile/>
On Wed, Feb 20, 2013 at 7:36 AM, Neil Sleightholm <[email protected]>wrote:
> I think I get what you mean.
>
> The issue I see is that the upgrade logic is in the old bundle so you
> are not in full control when releasing updates. Say for example a v1.0
> could be upgraded to 1.5 but not 2.0 but 1.9 could update to 2.0 you
> wouldn't have that control (example is a bit contrived). I suppose in this
> case you should have changed the update URL in v1.9. It just feels like you
> need hindsight when deploying the releases – or I didn't understand.
>
> Also, can you get version information from a remote bundle via http? Or
> was I missing the point about the header?
>
> Neil
>
> I was toying with an even simpler design. Just point at the newer
> bundle on the web. The current bundle could range request the version
> number of the bundle (out of the header) and now if the web is newer. The
> range request would also tell the size of the new bundle. Any thoughts?
>
>
> On Tue, Feb 19, 2013 at 8:13 AM, Neil Sleightholm <[email protected]>wrote:
>
>> The full code is available in this fork
>> http://wix.codeplex.com/SourceControl/network/forks/nsleightholm/bundleselfupdates/changeset/232ffc24aa57
>> ****
>>
>> ** **
>>
>> Neil****
>>
>> ** **
>>
>> *From:* Neil Sleightholm [mailto:[email protected]]
>> *Sent:* 19 February 2013 15:34
>>
>> *To:* Windows Installer XML toolset developer mailing list
>> *Subject:* Re: [WiX-devs] WixStdBA and bundle self updates****
>>
>> ** **
>>
>> What I did was hook in to the OnDetectUpdateBegin() event and create a
>> thread to check a website, if the website reports that there is an update I
>> enable a link on the welcome page that calls
>> OnPlan(BOOTSTRAPPER_ACTION_UPDATE_REPLACE). I set the check link to include
>> the bundle version e.g. Update Location="
>> https://example.com/checkupgrade.asp?version=1.2.3.4” (this could do
>> with being a formatted value so that you can use [WixBundleVersion]). The
>> website returns the update URL and optionally the size of the download.**
>> **
>>
>> ** **
>>
>> Most of the code was already in place so I just had to join the dots.****
>>
>> ** **
>>
>> The thread code looks like this:****
>>
>> // Load the update XML from a location url and parse it for an
>> update.****
>>
>> //****
>>
>> // <?xml version="1.0" encoding="utf-8"?>****
>>
>> // <Setup>****
>>
>> // <Upgrade Url="https://somewhere.co.uk/download/Setup.exe";
>> Size="123" />****
>>
>> // </Setup>****
>>
>> ** **
>>
>> hr = XmlLoadDocumentFromFile(pThis->m_wzUpdateLocation, &pixd);**
>> **
>>
>> BalExitOnFailure(hr, "Failed to load version check XML
>> document.");****
>>
>> ** **
>>
>> hr = XmlSelectSingleNode(pixd, L"/Setup/Upgrade", &pNode);****
>>
>> BalExitOnFailure(hr, "Failed to select upgrade node.");****
>>
>> ** **
>>
>> if (S_OK == hr)****
>>
>> {****
>>
>> hr = XmlGetAttributeEx(pNode, L"Url", &sczUpdateUrl);****
>>
>> BalExitOnFailure(hr, "Failed to get url attribute.");****
>>
>> ** **
>>
>> hr = XmlGetAttributeLargeNumber(pNode, L"Size", &qwSize);****
>>
>> ** **
>>
>> pThis->m_fUpdate = (sczUpdateUrl && *sczUpdateUrl);****
>>
>> }****
>>
>> ** **
>>
>> if (pThis->m_fUpdate)****
>>
>> {****
>>
>> BalLog(BOOTSTRAPPER_LOG_LEVEL_STANDARD, "Update available,
>> url: %ls; size: %I64u.", sczUpdateUrl, qwSize);****
>>
>> pThis->m_pEngine->SetUpdate(NULL, sczUpdateUrl, qwSize,
>> BOOTSTRAPPER_UPDATE_HASH_TYPE_NONE, NULL, 0);****
>>
>> ThemeControlEnable(pThis->m_pTheme,
>> WIXSTDBA_CONTROL_UPGRADE_LINK, TRUE);****
>>
>> }****
>>
>> else****
>>
>> {****
>>
>> BalLog(BOOTSTRAPPER_LOG_LEVEL_STANDARD, "No update
>> available.");****
>>
>> }****
>>
>> ** **
>>
>> I’ll try and create a fork for this tonight.****
>>
>> ** **
>>
>> Neil****
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> WiX-devs mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wix-devs
>>
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> WiX-devs mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
