Ah! There seems to be some confusion on this point. I will see.
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-854-5589
Facsimile |
I am updating the WiX 3.8 to see the differences in the updated Bootstrapper
and therefore I am looking at the following page:
https://classicwixburntheme.codeplex.com/wikipage?title=Guide%201referringTitle=Documentation
Just to follow the example it states to download 1033.zip and extract the
I've now tried a small update. I've never fully understood why you’d use
these, but my co-workers wanted to use MSPs for some of our updating, so I
built a front end for making those and hence small updates. That all to say
that I may be doing something unusual or wrong with them. However, that
Sorry, Rob but I am still at a loss here as how what I would need to update
to be able to get the values of these environment variables into the WiX
burn bootstrapper that then get passed to my .msi installer. Again I am not
up to date with programming skills and therefore having to update code is
That's an independent project. You might ask them on their discussion board:
https://classicwixburntheme.codeplex.com/discussions
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
Okay so it is not as easy as adding a new control to the Success Page in the
theme because as stated I did that and it shows no problem, but have
basically no control over this and it's execution. So the actions that were
on the Launch button has to be switched actions that get triggered only if
Neither Burn nor wixstdba read environment variables so you'd need to write
code to do that. In WiX v3.8 you could maybe write a BA function (though I've
never tried that myself).
Although if you're just going to pass it to the MSI, why not have the MSI get
the variable. Windows Installer
I haven't been able to reproduce this using signed or unsigned MSIs deploying
in an Open or Closed Environment.
I would be very happy to take a look at some verbose logs of the failures.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Thanks Rob, I'll do that.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697p7596704.html
Sent from the wix-users mailing list archive at Nabble.com.
Yes I already do this, but I was trying to get the value so that it could be
appended to a property that gets passed to the main installer. Since what gets
passed to the install will override what defaults gets set in main install
those and therefore you lose the entries. I'll figure something
The issue is very easily reproducible for me when doing an upgrade from one
bundle to another one. I emailed Keith links to two installers that have
100% repro for me when upgrading from the one to the other while having
KB2918614 installed. Repros on any machine.
I'm happy to share some logs but
Let me introduce you to your new best friend: MsiZap
http://msdn.microsoft.com/en-us/library/aa370523(v=vs.85).aspx (
http://msdn.microsoft.com/en-us/library/aa370523(v=vs.85).aspx)
While I was doing custom BA development MsiZap helped me out of a few
botched installations where I was stuck in
I am sure that Microsoft will ultimately have to make a fix, but I have a lot
of installers out in the wild, and I feel very exposed when none of my testers
can replicate. I'm much more interested in understanding the mechanism of
failure--especially since I can't currently replicate.
Also,
Let me echo John here, I am trying to help us and also help the community. We
are worse off, too, than some, because the machines I deal with are
mostly-disconnected remotes which receive the vast majority of their tech
support via RDP if at all. It seems that most of the hypotheses around are
I can properly uninstall the MSIs via msiexec /x {GUID}. The problem is
removing the stuff left behind by Burn, such as the cached bundle and
packages. I doubt msizap knows anything about bootstrappers...
El lunes, 8 de septiembre de 2014, Sascha Sertel sascha.ser...@gmail.com
escribió:
Let me
Yes, my installer uses a bundle because I have .NET Framework 4.5.1 and
Visual C++ 12 runtime components as a prerequisite before running my actual
product MSI.
I haven't actually tried if the upgrade failure also repros using the
product MSI only instead of the bundle, I'll try that out today.
MsiZap will wipe out anything that is related to the product code. Run it
once and you will see the giant output of all the registry and file
locations it goes through.
As far as other bundle left-over go, you should be able to clear those out
yourself from paths like
I notice that Agent.Interop.dll, CefSharp.dll, and CefSharpt.Wpf.dll all are
completely unversioned (no version numbers at all). When an upgrade works,
what to does the log look like for these three files?
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications |
For what it is worth, I tried one of my investigation packages with a fake
exe (for the sake of ease of recognizing as a fake) which, needless to say,
has no version at all. It seems to upgrade fine with no trouble.
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A
MsiZap is evil.. DON'T use it. If you did have a borked MSI, fix the MSI and
then use Orca to match the needed ID's. From there you can recache the fixed
MSI and do a proper uninstall.
As for the borked bundle, I'm not certain if you can easily assign the bundle
Id, but that’s what I would try
In a successful upgrade AgentLib.Interop.dll gets replaced if there was a
newer version (which is the case going from 396 to 1079), looks like MSI
doesn't pay much attention to the version but looks at file properties like
size and hash code instead. I should fix the version on this, I remember
If a file is unversioned, the normal file versioning rules and process don’t
apply to it.
In the case of these three assemblies, they end up being entries in the
MsiFileHash table. However, file timestamps control whether the MsiFileHash
table is even entered.
Repairs are also going to be
Oh and one more thing about customizing the burn bootstrapper theme files. I
figured that if it was too much work to simply add a checkbox on the success
screen and have it set to launch the app on finish, I figured that maybe
just add a text control at the bottom that then informs the user what
Classification: Public
Tim,
Once again I am confused why you are trying to reinvent the wheel. Burn already
does this!
Check out the LaunchTarget event...
http://wixtoolset.org/documentation/manual/v3/xsd/bal/wixstandardbootstrapperapplication.html
Steve
-Original Message-
From:
It doesn't replicate for me in the NOT installed case for the 1709 version of
the product. I'll get the earlier product tonight and test the upgrade case
tomorrow.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry
Right, fresh install works fine for me, it's only the upgrade case that is
borked.
// Sascha
On Mon, Sep 8, 2014 at 3:07 PM, John Cooper jocoo...@jackhenry.com wrote:
It doesn't replicate for me in the NOT installed case for the 1709 version
of the product. I'll get the earlier product
I think there is a feature request open for this.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
--
Want excitement?
Manually
27 matches
Mail list logo
