You are, "wrong and foolish." <smile/>
I see most people around here not recommending minor upgrades because most
people asking questions here aren't willing or able to do the work to stay
within the limitiations that minor upgrades require. If you've got it
working with MSIENFORCEUPGRADECOMPONENTRULES (see:
http://robmensching.com/blog/posts/2007/1/4/Doing-a-small-update-or-minor-upgrade-in-MSI-Use)
then Burn will support you.
You might have been confused that Burn doesn't support it because you don't
actually have to do anything special in your Bundle authoring. If your
package maintains it's ProductCode and increments any part of it's version
number then Burn will automatically detect you're doing a minor upgrade.
Burn will even tell you it's doing a minor upgrade during detection via:
// OnDetectRelatedMsiPackage - called when the engine begins detects a
related package.
//
// Return:
// IDCANCEL instructs the engine to stop detection.
//
// IDNOACTION instructs the engine to continue.
STDMETHOD_(int, OnDetectRelatedMsiPackage)(
__in_z LPCWSTR wzPackageId,
__in_z LPCWSTR wzProductCode,
__in BOOL fPerMachine,
__in DWORD64 dw64Version,
__in BOOTSTRAPPER_RELATED_OPERATION operation
) = 0;
The operation will be "BOOTSTRAPPER_RELATED_OPERATION_MINOR_UPDATE".
As for 64-bit Burn we don't currently drop a 64-bit version because there
are currently only disadvantages of using a 64-bit Burn instead of a
32-bit. Namely, 32-bit will run on both 32-bit and 64-bit Windows so you
can publish a single executable that installs the correct 32-bit and/or
64-bit packages and not require users to pick the correct bitness for their
machine. Picking is a very difficult problem for users. Trust me I lived
it:
http://robmensching.com/blog/posts/2007/2/4/The-Windows-Vista-64bit-upgrade-from-Windows-Marketplace-requires-a
Now in the not too distant future, it is possible the 32-bit subsystem will
not be shipped on 64-bit machines and we will have to ship 64-bit Burn
engine. We're prepared to do that (look back in the WiX v3.6 history and
you'll see a check-in from me that calls this out), it just hasn't been a
requirement yet.
Also, note that Burn was just released as a Beta. It is not production
ready. We are still fixing bugs and definitely taking feedback on what does
and does not work yet. Fortunately, in this case Burn already supports your
desire.
Finally, please remember that we are all volunteers here. You are welcome
to go use InstallShield and get all upset at them because they don't
support some feature as well as you like. They have to put up with that
better because you paid them a good chunk of change. Here however, I think
you'll find we're far more repsonsive if you respect the fact that we're
all just doing this because we want to provide the best tools possible so
you can build the best installation packages.
Keep coding, you know I am.
On Thu, Nov 24, 2011 at 8:06 AM, Michael Janulaitis <wix-u...@cornerbowl.com
> wrote:
> Well everyone out there seems to say minor upgrades are not desired.
> Our software has weekly updates, as do many other professional
> applications developed through the world. I think we can all agree that
> is normal behavior even though it is undesired. Simply saying an app
> should be designed so well that only releasing monthly patch updates or
> major upgrades is with out a doubt a statement made from newbie
> developers that do not produce high volumn professional, complex
> applications. OK with that said maybe I can start a fire under some of
> your alls feet. Minor upgrades are a major function of MSI which all
> of us should be using. First, requesting the user to re-select the
> installation location is unacceptable. Yes I agree all apps should be
> installed in their proper locations. But like the developers of Visual
> Basic know, the customer is always right, you can't just drop the
> language even through there is no point of it. I have created plenty of
> apps that install to the default location without user prompt but then I
> get bombarded with support calls about specifying an alternate
> location. So for those customers I must allow overinstalls that
> automatically re-install the previous options as they were previously
> selected. Next services require specific logon as credentials. If a
> major upgrade is deployed the service will be uninstalled losing the
> user's credentials. I can tell you this after talking with 1000s of IT
> systems admins that most of them have no clue what their domain admin
> username and password is when used to start windows services. Again
> asking the user to specify those credentials everytime a new build is
> released is out of the question. This means a minor upgrade is needed.
> Well obviously msi is flawed. Msiexe should be able to figure this out
> and apply the proper actions. But as we all know it does not. So
> instead we have to run bootstrappers just to fire the proper command.
> Well I don't see a way to do this with burn. Maybe there is but I don't
> see a way. Please tell me I am wrong and foolish. I write this email
> in hopes someone will step up and either admit Wix is not actually a
> professional product ready for prime time or show me how and prove me an
> idiot. I am a licensed user of IS 2011 and their bootstrapper handles
> all of this. I am really bummed I got my MSI mostly done and it works
> great. Now I need to spend a just a few hours and convert it all to
> IS. I don't want to use their software. Maybe in a few years burn will
> get this figured out.
>
> One other thing, burn doesn't run native 64-bit...haha that's funny. I
> think the stats say ~50% of all computers are now 64-bit. Dev should
> start on 64-bit then move backward these days.
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
