My condition is:
Again we are still at WiX 3.7 so will not be able to look at the 3.8
functionality until we move to that version in our build environment.
I have not yet looks into the registry keys, but I guess that I should if we
support 4.5, but most of the machines that we will be
Jacob, thanks for all of the information.
My code is exactly the same as the snippet that you posted (except I added a
couple of calls to Engine.Log to see what the Url is that was passed to
Engine.Setup.) I thought that this code snippet related to parsing the atom
feed for multiple entries,
2014-07-11 8:57 GMT-03:00 TimM timmay...@smarttech.com:
My condition is:
Again we are still at WiX 3.7 so will not be able to look at the 3.8
functionality until we move to that version in our build environment.
I have not yet looks into the registry keys, but I guess that I should if we
A related behavior that I am observing is that when a Bundle is installed on
a system, it is being cached under both:
C\ProgramData\Package Cache\guid
path to user's profile\AppData\Local\Package Cache\different guid
When a bundle is completely Uninstalled, the entries under C:\ProgramData
are
If it detects 4.5, it will detect 4.5.1.
From the log of one of my installers:
AppSearch: Property: NETFRAMEWORK45, Signature: NetFramework45
MSI (c) (AC:CC) [17:30:47:228]: PROPERTY CHANGE: Adding NETFRAMEWORK45
property. Its value is '#378758'.
Note the '#' symbol at the beginning of the
Is the concern with the leftover bundle in the user specific package cache, or
is the concern with the incremental upgrades instead of taking the largest leap
possible?
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, July 11, 2014 8:00 AM
To:
Okay now I am experiencing another issue with this.
Since I have set my Text to # so that I can accept values from 1 to
9 it is actually back filling my property with spaces if I enter less
than 5 numbers.
So if I enter '34' the property would end up being '34 ', meaning the
string now
1) author your launch conditions correctly;
2) use the remember pattern for key properties;
3) follow the Component Rules strictly;
4) ensure your assemblies, executables, MSI's, and bootstrappers are all
properly versioned;
5) test with MSIENFORCEUPGRADECOMPONENTRULES property set and remove
And don't forget about MajorUpgrade / and all the simplification it does for
you.
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Friday, July 11, 2014 8:09 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Upgrade Questions
1) author
That's the think though, I checked the install log after it failed to find
.NET 4.5 and the NETFRAMEWORK45 property was not generated at all. So if in
WiX 3.7 it will detect 4.5 and greater then it should have at least created
that property with the version that it found.
So why did it not do
My concern is with incremental upgrades instead of taking the largest leap
possible, which as I investigate seems to be related to the leftover bundle
in the user specific package cache.
When a user launches Bundle.exe 1.05 (and if 1.0.10 is available on the web
site, but if intermediate bundles
I just read the entire message on Nabble, and logs are kinda my thing,
so would you mind posting the log...
Carter
Quoting TimM timmay...@smarttech.com:
That's the think though, I checked the install log after it failed to find
.NET 4.5 and the NETFRAMEWORK45 property was not generated at
Do you have the netFx extension linked in?
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: TimM
So if you have bundels A,B,C, and D, where A is the installed version of
1.0.1.0, and B-D are 1.0.2.0-1.0.4.0, you are seeing a behavior where if A is
installed and B was cached previously, that when going to ARP and selecting
modify that the update check invokes B instead of downloading D?
Yes, I should have netfx linked in. It shows in my project References and it
is listed at the top of my wix project:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension;
Now we build through
The AppSearch is for the .NET Framework 4.5 is not running at all in your log.
NETFRAMEWORK45 is not being set to any value. That is most unusual. I presume
you have a PropertyRef Id=NETFRAMEWORK45 above your launch condition and you
do not re-define NETFRAMEWORK45 anywhere?
--
John
Sorry for the late response. I finally got around to watching the video,
and I'm wondering what you would recommend I do instead.
My knowledge of WiX and MIS is fairly limited, and our installer doesn't
really do anything fancy or unusual (all our upgrades are implemented as
major upgrades,
Well I feel like an Idiot I was declaring Property Id=NETFRAMEWORK45
/ and missed the Ref part of it and did not even noticed after all the
examples that I looked at
Sorry for all the hassles that I put you through. I'll give it another shot
and more than likely it will work now..
You sacrifice working repair and the ability to patch with that approach
(unconditionally installing older files over newer). That would be
unacceptable for any of my products.
Also, shared components would blow up in all sorts of unpleasant ways.
--
John Merryweather Cooper
Build Install
you are seeing a behaviour where if A is installed and B was cached
previously, that when going to ARP and selecting modify that the update
check invokes B instead of downloading D?
If the user goes to ARP and D is already installed, then D is launched.
However if the user does not use ARP, but
See Here:
http://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx
And According to your log, your MSI is functioning Properly:
Property(C): MsiNetAssemblySupport = 4.0.30319.33440. The 4.5 Version
Numbers start at:
378389 for the 4.5 DWORD. According to the Document Above your
After adding more logging statements that information is the same as above
but confirms that the DetectUpdateBegin and worker_DoWork detect the latest
version (on the web site if available).
But apparently prior to that event, when there are intermediate versions
cached locally (meaning a version
So A-D all have the same RelatedBundle GUID?
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, July 11, 2014 11:05 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior
After adding more logging statements that
Yes. It is just defined so that someday in the future I could, if needed,
deploy a patch, addon, or upgrade. But at this point A - D are all
MajorUpdate of A (and I did not redefine the ReleatedBundl_GUID between
then. Should I change that with each MajorUpgrade? (I have been dong this
for
Okay changing the property to PropertyRef fixed the issue.
The MsiNetAsseblySupport = 4.0.30319.33440
The NETFRAMEWORK45 = #378675
Which means that what is installed is: 4.5.51641
So I am good to go. Thanks for all the help.
--
View this message in context:
The company I work with has a utility tool for translating incoming data in
the HL7 format into DB operations. We used to support two applications,
which means our program was named HL7 for Product X and Product Y. For
the next release, we're only supporting Product X, so we want to rename the
Just to mention repair briefly, it does indeed repair broken
components where the key item is wrong or missing, but custom actions
seem to be a common unanticipated issue. If you have a CA that runs
when a component is installed (because it's an install custom
action) then it will also run during
Did anything in the first 3 parts of the version number change?
Also, posting the install log (and linking to it here) would tell us what it's
currently doing.
-Original Message-
From: Sean Duggan [mailto:sean.dug...@gmail.com]
Sent: Friday, July 11, 2014 2:53 PM
To:
FYI - I have confirmed (using a different project which has not been changed
for some time) that when the bundle is built using wix 3.8.1128 it does not
have the behavior observed when the bundle is compiled using 3.9.702.
Specifically:
Bundle A (built using 3.8.1128)
Bundle B (built using
What value are you passing to Plan? Is it BA.Plan(LaunchAction.UpdateReplace)?
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, July 11, 2014 3:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior
FYI - I have
Yes UpdateReplace is indicated in the verbose log.
Back when I used the WixStdBA and a BAFunction I could step into the Engine
functions using WinDbg (a long time ago now), but I have not found a way to
do that running my mba on a test box (which is network isolated from my
development system so
I have been reading the wix source code for ideas. I do not really
understand what a Forward Compatible bundle (in contrast to or in
relationship to a Relate bundle.)
--
View this message in context:
32 matches
Mail list logo
