Changing URLs in DetectUpdateBegin

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

Changing URLs in DetectUpdateBegin

Phill Hogland
In today's Wix Online powwow a question was raised:
3) DetectUpdateBegin, should we allow tweaking the update URL at runtime?

My view is 'yes' for the following reasons:

1) Very early in my wix journey I asked in the wix-users forum if it was possible to modify the URL at runtime.  It was suggested that either a native BA or mba could be used to address this issue.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Web-download-from-web-site-not-existing-when-compiled-td7586547.html#a7586550
2)  While I never did the implementation described in that thread, what we did implement is a way to fingerprint a development or test computer.  At runtime, when the fingerprint does not exist, the mba uses the download URLs as authored in wxs files.  But when the setup is run internally on a development or QA test system then both out build process and the mba at runtime changes the URL to a different hosting location.  (A poor man's version of:
http://msdn.microsoft.com/en-us/library/dn217874.aspx )
3) When Jacob kindly integrated the self-update functionality into Burn, I converted my mba to use the new functions and ran into the problem that DetectUpdateBegin did not allow for the URL to be changed at runtime.  I raised this concern and was told that wix did not want to allow a mba to change the url at runtime.
4) I went back to the implementation similar to the wix3.8 WixBA DetectUpdateBegin using a worker thread.  While this works for me, there have been times, earlier in 3.9, though not lately, when Burn would use the authored URL to do the self-update, creating a startup delay, and then my worker thread would also do the download using the modified URL.  I have not noticed this recently, but allowing a BA to modify the URL is desirable (or a way to preempt Burn from doing the download until a point certian).
5) IBootstrapperApplication.h for OnResolveSource comments say:
"// Notes:
    //  It is expected the BA may call IBurnCore::SetLocalSource() or IBurnCore::SetDownloadSource()
    //  to update the source location before returning IDRETRY or IDDOWNLOAD."
Since there is a 1 to 1 relationship between a bundle and the packages available at compile time, this comment implies that it is expected that a developer can modify the bundle update URL also.

I just wanted to share these views.  I appreciate the underlying support in Burn that allows me to meet the business goals, whether there is a decision to change DetectUpdateBegin or not.

Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Changing URLs in DetectUpdateBegin

Hoover, Jacob
I know in 3.x we can't change it, but since I'm making a few other changes in 4.x in this area, I'm willing to make the change if Rob and Bob thinks it's an ok design.

One other workaround you could have used would have been a URL with parameters in it, as I'm fairly certain that we'd handle URLs with burn variables as parameters.

> On Nov 13, 2014, at 2:04 PM, "Phill Hogland" <[hidden email]> wrote:
>
> In today's Wix Online powwow a question was raised:
> 3) DetectUpdateBegin, should we allow tweaking the update URL at runtime?
>
> My view is 'yes' for the following reasons:
>
> 1) Very early in my wix journey I asked in the wix-users forum if it was
> possible to modify the URL at runtime.  It was suggested that either a
> native BA or mba could be used to address this issue.
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Web-download-from-web-site-not-existing-when-compiled-td7586547.html#a7586550
> 2)  While I never did the implementation described in that thread, what we
> did implement is a way to fingerprint a development or test computer.  At
> runtime, when the fingerprint does not exist, the mba uses the download URLs
> as authored in wxs files.  But when the setup is run internally on a
> development or QA test system then both out build process and the mba at
> runtime changes the URL to a different hosting location.  (A poor man's
> version of:
> http://msdn.microsoft.com/en-us/library/dn217874.aspx )
> 3) When Jacob kindly integrated the self-update functionality into Burn, I
> converted my mba to use the new functions and ran into the problem that
> DetectUpdateBegin did not allow for the URL to be changed at runtime.  I
> raised this concern and was told that wix did not want to allow a mba to
> change the url at runtime.
> 4) I went back to the implementation similar to the wix3.8 WixBA
> DetectUpdateBegin using a worker thread.  While this works for me, there
> have been times, earlier in 3.9, though not lately, when Burn would use the
> authored URL to do the self-update, creating a startup delay, and then my
> worker thread would also do the download using the modified URL.  I have not
> noticed this recently, but allowing a BA to modify the URL is desirable (or
> a way to preempt Burn from doing the download until a point certian).
> 5) IBootstrapperApplication.h for OnResolveSource comments say:
> "// Notes:
>    //  It is expected the BA may call IBurnCore::SetLocalSource() or
> IBurnCore::SetDownloadSource()
>    //  to update the source location before returning IDRETRY or
> IDDOWNLOAD."
> Since there is a 1 to 1 relationship between a bundle and the packages
> available at compile time, this comment implies that it is expected that a
> developer can modify the bundle update URL also.
>
> I just wanted to share these views.  I appreciate the underlying support in
> Burn that allows me to meet the business goals, whether there is a decision
> to change DetectUpdateBegin or not.
>
>
>
>
>
> --
> View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Changing-URLs-in-DetectUpdateBegin-tp7597924.html
> Sent from the wix-devs mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Changing URLs in DetectUpdateBegin

Phill Hogland
Sounds fine with me.  In prior conversations I did not have the chance to provide the details.  Thanks for the URL parameter idea.  I have been creating setups with this approach since late 3.7 or early 3.8.  So at this point there are a bunch of folks expecting this to work.  At some point the idea of using URL parameters may be helpful.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Changing URLs in DetectUpdateBegin

Rob Mensching-7
In reply to this post by Hoover, Jacob
Seems reasonable for the BA to provide the update URL at runtime. Seems that setting the value would have to happen before returning from DetectUpdateBegin().

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Hoover, Jacob [mailto:[hidden email]]
Sent: Thursday, November 13, 2014 1:13 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] [SPAM] Changing URLs in DetectUpdateBegin

I know in 3.x we can't change it, but since I'm making a few other changes in 4.x in this area, I'm willing to make the change if Rob and Bob thinks it's an ok design.

One other workaround you could have used would have been a URL with parameters in it, as I'm fairly certain that we'd handle URLs with burn variables as parameters.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs