>>But i'd be happy to provide a unit test, and would appreciate some pointers.
>>Maybe also a comment on whether it's preferable to do all that in a vm than
>>on a real system?
I wouldn't mind some pointers as well. I was suppose to add a test case for
burn addons.
Wes
From: Jakob Ziegler [mailto:subscr...@gmail.com]
Sent: July-17-13 10:47 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] [SPAM] Re: fixing a bug (superseded patches are not
removed by bundle)
Hi Rob
I think the same way about engine changes.
So, I tried to break this approach and make it do something it should not, but
couldn't come up with a case :) I also still think the same way that a patch
should be removed by the bundle with which it was applied, unless of course
some other bundle is still clinging on to it.... that's something I didn't
test, actually...
1. I did try the patched engine on my local machine: bundle, patch bundle, 2nd
patch bundle, remove first patch bundle => msp patch was also removed. The
detect/plan message of the burn engine also looked like what i'd expect.
2. I thought about adding a unit test, and also started, but after I got a unit
test message that I need to set some special environment variable (and possibly
end up with a halfway installed bundle on my system), i stopped.
But i'd be happy to provide a unit test, and would appreciate some pointers.
Maybe also a comment on whether it's preferable to do all that in a vm than on
a real system?
I'll write an additional email about getting that assignment.
Thanks
Jakob
On Wed, Jul 10, 2013 at 4:42 PM, Rob Mensching
<r...@robmensching.com<mailto:r...@robmensching.com>> wrote:
So I've been thinking about this change. Engine changes are so challenging
since you have to think about all the different ways things could end up there.
You've already done a great job of this so I'm wracking my brain to think of
other things. <smile/>
1. It's a bit unclear from your comments but did this change actually fix the
issue you were seeing? It seems like it should but I don't have a repro
scenario in front of me so... <smile/>
2. A test case for this would be ideal. Are you interested in adding one of
those? If so, I can point you in the right direction to do that using the new
xUnit test infrastructure.
Finally, Jakob, I don't think we have an assignment agreement for you. Can we
get that paper work out of the way:
http://wixtoolset.org/about/assignment-agreement/
On Thu, Jun 27, 2013 at 8:10 AM, Jakob Ziegler
<subscr...@gmail.com<mailto:subscr...@gmail.com>> wrote:
Hi
I'd like to fix this bug: https://sourceforge.net/p/wix/bugs/3321/
It got started in this question:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/a-patch-bundle-uninstall-doesn-t-remove-superseded-msp-patches-td7586582.html
and I was told I could work on that myself.
The intention would be that a bundle removes the patches it has installed, even
though the patches are already superseded. Currently, the bundle leaves them on
the system and uninstalls itself, leaving zombies. That's the case with
FixPacks and superseding turned on, or all ServicePacks as I got the impression.
But i've never done that before on a community project, so i'm a bit unsure
about the proceedings.
Also, since I've never done anything for WiX i wondered if someone could throw
me a bone and tell me if starting in burns mspengine.cpp makes sense?
I had a look at the code and ended in the
mspengine::MspEnginePlanCalculatePackage method.
There it looks like BOOTSTRAPPER_PACKAGE_STATE_SUPERSEDED just isn't mentioned
and adding that (and treating it like ..._PRESENT) would kind of be a possible
first step in the solution.
I also see the problem that this would change the behavior of the engine and
some might not like that, so I don't know if there'd be a requirement to
configure that in the xml to retain backwards compatibility?
Or if that's totally the wrong direction to go...
Cheers
Jakob
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
