WixStdBA should support same version upgrades.

[wixbot]

If you build and install a bundle and then rebuild it with the same version number and install it both versions appear in ARP.

I think in this scenario it should perform and upgrade or that option should be possible.

Originally opened by nsleigh from http://sourceforge.net/p/wix/bugs/3065/

[wixbot]

Ok I took the time to implement versioning so avoid the problem. In case anyone else can't wait for the fix here is how I achieved versioning with a simple PowerShell script:

http://codechief.wordpress.com/2013/03/24/versioning-visual-studio-solutions-the-easy-way/

Now it's easy I'll be versioning all my projects. But for WIX developers; please make this fix still because Burn should behave the same way as the rest of WIX tools and there will be people who still need it.

[wixbot]

Rob, would adding an attribute to the Bundle element to allow it to be optional be correct? E.g.: Bundle/@AllowSameVersionUpgrades=yes|no (with the default or no).

[wixbot]

@neil, I'm not thrilled about adding more attributes on to the already crowded Bundle element but I'm not sure there is a better option. The same attribute would be needed on the RelatedBundle element when the Action is "Upgrade".

[wixbot]

Probably best to following this up on wix-users but I saw something about related bundles that may address this, i.e. the Pro version would upgrade/remove the standard version.

[wixbot]

What happens if I have regular and pro editions of my application. It wouldn't be realistic to have the Pro a higher version just to enable upgrades. Or is there a way to do this?

[wixbot]

I need that too. It's very annoying. We don't increase the build number except towards the end of an iteration when the solution is ready for release. Before then, we will build the MSI and bootstrapper package many times to get the installation right and we have to run it on many different integration servers.

The problem with .NET applications is they don't version as easy as described in the MSDN documentation unless they are in the GAC. In practice any fully qualified references like you must provide in web.config and other places will throw errors when the version changes at any part (even minor/build/revision). We also want our MSI version and all assemblies to match the release version, because that is what gets reported when trouble occurs and from license audits.

That is why there is a requirement for same version installs in my opinion; because you may have a good reason for mostly static versions but need to build the MSI multiple times at least for testing.

In a perfect world the build number would change at each compilation, but that is a lot of effort to coordinate throughout the Visual Studio build and causes issues with check-outs of source controlled files just for an otherwise "read only" local developer build/test. You can't even say just edit the config files in the target directories during post build events either, because some projects like web applications run from the source directory (e.g. web.config cannot be edited without causing a checkout).

[wixbot]

For WiXStdba these changes allow same version upgrades.

BOOTSTRAPPER_RELATED_OPERATION m_Operation;

virtual STDMETHODIMP_(int) OnDetectRelatedBundle(
    __in LPCWSTR wzBundleId,
    __in LPCWSTR wzBundleTag,
    __in BOOL /*fPerMachine*/,
    __in DWORD64 /*dw64Version*/,
    __in BOOTSTRAPPER_RELATED_OPERATION operation
    )
{
    // If we're not doing a pre-req install, remember when our bundle would cause a downgrade.
    if (!m_sczPrereqPackage && BOOTSTRAPPER_RELATED_OPERATION_DOWNGRADE == operation)
    {
        m_fDowngrading = TRUE;
    }

    m_Operation = operation; // Save operation

    return CheckCanceled() ? IDCANCEL : IDOK;
}


virtual STDMETHODIMP_(int) OnPlanRelatedBundle(
    __in_z LPCWSTR /*wzBundleId*/,
    __inout_z BOOTSTRAPPER_REQUEST_STATE* pRequestedState
    )
{
    // If we're only installing prereq, do not touch related bundles.
    if (m_sczPrereqPackage)
    {
        *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_NONE;
    }
    else if (BOOTSTRAPPER_RELATED_OPERATION_NONE == m_Operation && 
        BOOTSTRAPPER_REQUEST_STATE_NONE == *pRequestedState && 
        BOOTSTRAPPER_RELATION_UPGRADE != m_command.relationType)
    {
        // Same version upgrade detected, mark absent so the install runs
        *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT;
    }

    return CheckCanceled() ? IDCANCEL : IDOK;
}

[wixbot]

Tony, consider changing the assembly file version. That allows you increment a build number every build and still maintain the assembly version for all the .NET reasons. This is how the WiX toolset does its builds.

[wixbot]

We haven't scrubbed the WiX v3.8 bugs yet. It will only get done if someone helps get hte fix done correctly. The quick fix Neil provided above breaks the current behavior which some people will want (they don't complain because they have the "right" behavior now :).

[wixbot]

Thanks for the quick reply.

Yes I think that has to be the long term solution anyway. Plus it's easier now with VS 2012 "local" TFS workspaces to avoid hard check-outs, because checked-in files are not set read-only and can be modified without checking in, unless the developer does it by accident. But they still appear as changes and I can imagine a few other developers checking nothing but a build number increment just to be safe.

I know the continuous build/increment is the right solution and strongly promote that best practice myself. Just in the real world it gets skipped all to often due to cost constraints. Guess this is a good nudge to get that done.

Still Burn should support the same behaviour as the rest of WIX and there are enough people who see that as a requirement. I see you already it queued-up for the next release and it is not urgent (any public release is always incremented manually anyway). The test servers will have to be left a bit messy (duplicate Add/Remove Programs entries) until either WIX 3.8 comes out or I get enough time to improve the build system here :-)

[wixbot]

Originally changed by barnson
Release changed from v3.8 to v3.x
Type changed from Bug to Feature

[wixbot]

For our project I implemented the fix bosted above. It works fine. But think that burn should behave like packages allowing same version upgrades.

Originally posted by janh

[wixbot]

I would like to upvote this issue. This one is really bugging our testers!

Originally posted by bwehking

[wixbot]

Please give us this feature. It would be a tremendous help. It's bugging our QA staff significantly as well. We want to not have to always increment revision numbers and want to keep the same bootstrapper revision as our end MSI package.

Originally posted by alexandru

[wixbot]

Any updates on this change? Was there some sort of stumbling block that made it so a new attribute enabling same-version upgrades wasn't feasible? This addition would be of great interest!

Originally posted by elcortez

[wixbot]

Don't want to add "just another attribute". We have enough of that. We're still considering whether to change the design.

Originally posted by robmen

[wixbot]

Just like to comment, that because of this and other hardcoded aspects of wixstdba (like the UI, if you want to work without an MBA), I've had to impliment IBootstrapperApplication - not a great experience for first dip, especially when the documentation of that interface is so poor (as far as I can tell). An experience more like the WiX MSI authoring one would have been prefereable - wixstdba takes a lot of pulling apart, mainly because it involves a single huge class.

Regarding the docs - it's not clear to me in what cases some of the various On... methods will be called, and what effect the return values or __out params will cause (setting to ..._ABSENT I would not have guessed in the above to get an install execute action...)

Originally posted by david

[wixbot]

This issue is a little more problematic for us than just a nuisance for the QA group. We create two installers with the same version and upgrade code the only difference is one acquires the packages from the web while the other acquires them from the exe. We have a case where a user might install one package from the web installer and a different package from the stand alone installer. It doesn't happen often but it happens. When the user does this, we get two entries in the Add/Remove programs control panel. Since we didn't name the installers differently, it looks like the installer is installed twice.

Originally posted by serg
Status changed from Open to Untriaged

[paul-palmer]

We are experiencing the same pain as serg (June 17, 2015) We also have a web and offline bundles for the same build and experience these double install scenarios. If there is not a fix for this, please at least recommend reasonable workarounds.

[jchoover]

I won't be on this Friday, but if you want to make your case we have weekly meetings. If you can convince us that this is needed, I'd be willing to take a stab at it. If you need something faster, FireGiant would certainly do it for you.

[paul-palmer]

If we could set the Product Code GUID for the bundle explicitly like we can for an installer (via <Product Id=), could we then set the Product Code to be the same for our web and offline installers and avoid this problem?

[paul-palmer]

Will you please tell me how to participate in the weekly meeting?

From: jchoover [mailto:notifications@github.com]
Sent: Thursday, January 28, 2016 3:50 AM
To: wixtoolset/issues issues@noreply.github.com
Cc: Paul Palmer paul@ionicsecurity.com
Subject: Re: [issues] WixStdBA should support same version upgrades. (#3746)

I won't be on this Friday, but if you want to make your case we have weekly meetings. If you can convince us that this is needed, I'd be willing to take a stab at it. If you need something faster, FireGiant would certainly do it for you.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3746#issuecomment-176064290.

[robmen]

Meeting invites are sent to wix-devs@lists.wixtoolset.org

PS: Bundles don't have ProductCodes. That have a Bundle Id that acts more like the PackageCode.

[jnm2]

This is causing us pain as well.

[patrycjapico]

I have the same problem, as I would like to build a CD installer and a web one. The web does not have the necessary resources build in the installer as we can rely on the fact that they can be downloaded from the internet, where the CD installer should work offline.
Two bundles being exactly the same, apart from the chain part where the resources are being included or excluded depending on the build character, switched by conditional statements. Although they are the same, they do not recognize themselves as the same product, hence being installed separately (as bundles). It is not an intended behavior and I think it is caused by bundles having different BundleId being set underneath the hood.

Is it something that is being looked at currently and is going to be fixed ?

[jnm2]

What will it take to fix this?

[dmm4WiX]

Please add another voice in the woods to the list of folks who would like to see this fixed ... and preferably made consistent with the AllowSameVersionUpgrades logic already in WiX.
Thanks!

[thx1200]

Five years and this is still an issue... :-( I really would like to see this fixed.

[robmen]

@thx1200 perhaps you'd like to do the work to implement the feature? If not, then you'll want to work towards finding someone who is interested in implementing the feature.

[jchoover]

Propose a workable solution... You have 2 different install methods with two different bundles. You could have related bundle and a tweaked StdBA to do this, but there is no universal logic to start off with one flavor and magically transition to either in an install/upgrade/remove situation. Even without 2 bundles, you could make everyone a web bundle, and repackage your offline bundle as a self extracting zip of the web bundle w/ the vendor determined payload to accomplish this.

…

On Thu, Oct 19, 2017 at 12:40 AM thx1200 ***@***.***> wrote: Five years and this is still an issue... :-( I really would like to see this fixed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3746 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACmlRR2Dx9LT9jXLK04c0ZgL08x0aa9Rks5stuC9gaJpZM4HN_ob> .

[thx1200]

Granted, I am no MSI expert by any means, but the solution seems simple enough and aren't there proposed solutions already above?

• Version is older: perform upgrade / uninstall older, install newer
• Version is newer: "A newer version is installed., sorry!"
• Version is same (preferred for me): run the "modify" action on the existing installed bundle in add/remove programs.
• Version is same (just fine secondary option for me): "Sorry user! The same version of this product is already installed, please go to add/remove programs."
• Version is same (Op's suggestion): Perform upgrade

[robmen]

@thx1200 Here's how to go about contributing: http://wixtoolset.org/development/

[BMurri]

Or, just like most other OSS projects, if your not able to contribute a needed fix yourself, and you can't wait for the project to produce the fix, you could employ someone else. I know FireGiant performs that service. I also know that I perform that service.

[patrycjapico]

It sounds like this is something that is hard to change otherwise it would be done already by one of the collaborators or the owner. Well, if I find time I may have a look on the implementation myself to see whether I can even nail where the problem is and how to fix it.
Don't get me wrong, your installer is great, it is just missing that one thing which would make my life so much easier. In the circumstances I described above it looks like it is a bug rather than intended behaviour hence I contributed to the wixbot bug report.

[thx1200]

100% agree with patrycjapico. WiX is flipping amazing. This is honestly my only frustration. Keep up the good work. I haven't looked at the source at all, but I'll take a peek once my current workload settles down and EOY deadlines pass.

[jnm2]

They already have the test written for us and commented out. One of us just has to find the time to learn WiX internals and make their test pass.

https://github.com/wixtoolset/wix3/blob/87f84b40fdd4fa1578887eb9ed1381b982ee6717/test/src/IntegrationTests/Burn/BasicTests.cs#L175-L207

[RefaelP23]

I'm experiencing this with WiX v3.11.2.
Was this resolved and I'm doing something wrong or is it still a limitation?

[jnm2]

It's still a limitation.

[rseanhall]

We are changing the default for all bundles to support same version upgrades in v4.0 - #4808. Doing the same in v3.x would be a breaking change so we can't do it there. Adding the ability to configure wixstdba to support it is not something we would take in v3.x. So I'm closing this as obsolete.