True I am scoping this for the initial update but for me there is quite a big
disconnect between the build process and when the sales/test teams release the
update. I think updating an installed application is a completely different
problem but my solution works for that too, your app can send the same
information to the server and download the new install (in fact I do use this
process for both, I am just applying this to the bundle code).
One could easily modify the build process to generate a static feed file. Then
the details of adding more info would be up to the techies. I wouldn’t expect
the end user to read RSS, and I was hoping to abstract away its implementation
via the DLL I spoke of. It could be as simple as providing a Bundle UpgradeCode
to the DLL. I’d think of having a few API’s exposed to check for updates,
enumerate updates, download update, and launch update.
I would guess the disconnect we are having is you are only scoping this to the
initial install, and I am scoping it to an install or update via a
modify/repair or more importantly application integration.
From: Neil Sleightholm [mailto:[email protected]]
Sent: Wednesday, February 20, 2013 4:06 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] WixStdBA and bundle self updates
Personally I think the feed approach is too complicated. The environment I work
in there is either a new version or there isn’t, details about what is in the
update is for techies! Ok so I am being a bit flippant but I would hope the
solution can be run by someone without detailed knowledge of a process as
complex as RSS feeds. My end users have a copy of the application and just want
to be sure they have the latest version before they install it.
From: Hoover, Jacob [mailto:[email protected]]
Sent: 20 February 2013 21:46
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] WixStdBA and bundle self updates
The one thing I liked about a feed based updater was the ability to include
other meta information. The application or the BA could then display the “newer
version is available” message with an optional details button to show some
revision history and some “reasons for upgrading”. In a perfect world, the
internal lib that the BA is using could also be linked into a DLL so the
application could consume the same information.
From: Rob Mensching [mailto:[email protected]]
Sent: Wednesday, February 20, 2013 3:40 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] WixStdBA and bundle self updates
The HTTP request from Burn would include information about the currently
running Bundle. At least the Bundle and Burn engine version should be sent. The
ASP page could use that to send a 302 to the location of the new Bundle.
Eventually, the HTTP request would just get the bundle executable. So, for
really simple scenarios, just put your Bundle on a server, and when there is an
update, just copy the new thing over the old bundle.
Really, really simple was the goal.
On Wed, Feb 20, 2013 at 1:21 PM, Neil Sleightholm
<[email protected]<mailto:[email protected]>> wrote:
I probably didn’t explain, my idea is not a static page but an asp page (or
something more modern) that reads the version and decides what to return.
The contrived example is actually based on a real scenario, the sales/marketing
people still called the application v1 but we had to drop Windows XP support in
a point release so not all versions could be upgraded. I could have changed
version under the covers but it was easier not to.
In my scenario I have to allow less-techy people to handle the release and
upgrade process and they seem happy to edit an asp page (this is based on a
home grown upgrade process before bundles).
I am still not totally sure what you are suggesting, what would you put on the
server?
Neil
From: Rob Mensching [mailto:[email protected]<mailto:[email protected]>]
Sent: 20 February 2013 20:45
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] WixStdBA and bundle self updates
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/>
------------------------------------------------------------------------------
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]<mailto:[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
