Hi Steven,
Kindly find the below code, please help me
Thanks and Regards
Ravi
When i selected the Radio button the property INSTALL_VERSION changes
accordingly to 1 or 0
The value o
I have an installation which consists of around 7,000 files. Each file is in
it's own Component. The WXS file is auto generated during build time (via heat)
so names, guids, etc. are auto generated. The MSI is started from an External
UI via the Deployment SDK's Installer.InstallProduct() method
Meanwhile, I can confirm that PowerShell v3.0 and WMF 3.0 both installs this
assembly.
Errata on the AppFabric references. That should be AppFabric 1.0 and 1.1
respectively. ADFS 2.1 uses an assembly,
Microsoft.IdentityServer.Powershell.dll, which is linked against this
System.Management.Aut
Hello,
I'm in need of some suggestions on how to do this. The problem is I have a
package that wipes out a registry key on upgrade/uninstall (I only do major
upgrades), call it "package A". So when I upgrade to "package B" with
MajorUpgrade element scheduling RemoveExistingProducts after
InstallI
Can I mitigate the effect on Repair by enabling checksums and having the
install forcibly verify them?
I'm sure my managers will be trigger their Microsoft support contracts, but I
have to deal with it.
Installing in a different location will require significant code changes as
this thing hang
Wow, that's beginner mistake. Get them to fix the file version or rename
the file. Or you can install to a new location (which essentially renames
the file). DefaultVersion basic lies to the Windows Installer and it will
never be certain the file that is on disk is the right one (because the one
I have fixed the problem of multiple instace, as I didn't close the setup on
ApplyComple when running in silent mode.
How can I avoid to have multi instace on the ARP when running different builds
of the same setup versions? I have Collected in the DetectRelatedBundle the
bundle ProductCode tha
Interesting problem:
One of our products uses the System.Management.Automation.dll assembly from
AppFabric 2.0. It has AssemblyVersion 1.0.0.0 and AssemblyFileVersion
6.1.7600.16385.
The System.Management.Automation.dll assembly that appears to come with
AppFabric 2.1 or PowerShell v3.0 has A
By default the newer version of the Bundle will remove older versions of
the Bundles that share the same UpgradeCode. Bundles do not suffer from the
same 3 field version issues that MSI packages do. Forcing the e.State for
RelatedBundles to absent could have other side-effects (like removing
add-on
Classification: Public
No I don't sorry,
This is from our Server product which supports Win7/8, Win Server 2008R2/2012
Steve
-Original Message-
From: John Lalande [mailto:johnlala...@rocketmail.com]
Sent: April-11-13 1:19 PM
To: 'General discussion for Windows Installer XML toolset.'
Sub
That works perfectly for Win7, but not XP.
Do you have a corresponding entry for XP?
Thanks
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Friday, March 22, 2013 9:20 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
Yeah, okay, it is entirely possible that v3.8.401 would contain all the
fixes for the first time and was also the compression bug I introduced.
Let's see if the next build on Monday makes everything correct. Cool?
On Thu, Apr 11, 2013 at 8:22 AM, Sergey Yukhno <
sergey.yuk...@visutechsystem.by> w
Note there are more things than the file date that change with every build
(namely the PackageCode). File date will not affect the file hash.
On Thu, Apr 11, 2013 at 8:47 AM, Spud wrote:
> I think I've been having a few blonde moments. (sigh)
>
> My build is re-creating this "static" msi file e
It's not a Windows Update check. Burn is pausing WU because data shows that
installation contention with WU creates significant install failures.
On Thu, Apr 11, 2013 at 7:49 AM, Michael Ogilvie <
michael.ogil...@pixelink.com> wrote:
> It looks like when the system got up to date with all of its
That looks like an error from my extended BA, is that correct? If so remove the
element from your bundle if you are not using it. If you have any
follow up questions can you post them to the extended BA codeplex discussion.
Neil
-Original Message-
From: Michael Ogilvie [mailto:michael.
I ran into the same issue. Everytime the msi is built its check sum is
indeed different and the bundle stores this information. What you can do
is skip the msi build step unless it has actually changed and copy it the
desired location so that when the bundle builds it picks the same msi
everytime
I think I've been having a few blonde moments. (sigh)
My build is re-creating this "static" msi file each build, so that the file
date is changing. If I just build the thing and include the file as a static
resource instead then it *will* be the same hash value.
I need to get out more...
--
Vi
OK.
I should have known - rob was right all along (smile)
*Assuming* that WiX generates it's hash values the same way as the ms "File
Checksum Integrity Verifier"
(http://download.microsoft.com/download/c/f/4/cf454ae0-a4bb-4123-8333-a1b6737712f7/windows-kb841290-x86-enu.exe)
then the hash values o
v3.8.309.0 and early.
On 4/11/2013 17:18, Bruce Cran wrote:
> On 11/04/2013 14:23, Sergey Yukhno wrote:
>> Can't install Wix 3.8 on Windows XP.
>> "Wix38.exe is not valid Win32 application."
> That looks like a problem with the VS 2012 settings. I thought we'd
> fixed them all - what build are you
v3.8.309.0 and early. I can't setup v3.8.401.0 and later on Win 7 x64
like in "[WiX-users] latest weekly build fails to update".
On 4/11/2013 17:44, Rob Mensching wrote:
> Probably related to recent fixes WiX v3.8 to get native code working
> correctly on WinXP. What version of WiX toolset are yo
Thanks Rob,
Yep, my MSI isn't changing. I don't seem to be able to determine why it
thinks the hash doesn't match.
If build 153 created the MSI, and builds 153, 154, 155 etc are looking at
the same DownLoadURL location (and presumably the same target hash values),
why do Bootstrappers 154 and 155
Hello,
Does anybody know why this error keeps popping up?
Error 0x8007006e: Failed to load version check XML document.
Thank you,
Michael Ogilvie
--
Precog is a next-generation analytics platform capable
It looks like when the system got up to date with all of its updates the
issue went away.
Is there any way to bypass this windows update check?
Thank you,
Michael Ogilvie
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Thursday, April 11, 2013 10:42 AM
To: Ge
If the hash doesn't match then the Bundle expects a different MSI than the
one you are putting on the URL. You can't change the MSI without updating
the Bundle's that reference it.
The WiX toolset shares the ProjectAggregator.msi across many versions of
the Bundles because the ProjectAggregator.ms
Probably related to recent fixes WiX v3.8 to get native code working
correctly on WinXP. What version of WiX toolset are you using?
On Thu, Apr 11, 2013 at 2:10 AM, Sergey Yukhno <
sergey.yuk...@visutechsystem.by> wrote:
> Hello.
>
> Error at creating user on Windows XP with error dialog "...Set
I've changed my mind re separate question :)
Unless I'm understanding this incorrectly so long as it does not change, the
sharedcomponents.msi (which holds a number of third party dll's that will
not change) only needs to be in one place (i.e. the DownloadURL in the
MsiPackage element will not cha
I've had the same experience with Windows 7, but the explanation seems pretty
clear--setting the System Restore Point (by the OS) can take several minutes.
I've even added ProgressText to warn of this, but it is plain from the logs
that a lot of time is spent churning waiting for the OS to save
Usually indicates that Windows Update is busy or unhappy on that machine.
If the problem persists check out Windows Update and see that it is
behaving well.
On Thu, Apr 11, 2013 at 7:23 AM, Michael Ogilvie <
michael.ogil...@pixelink.com> wrote:
> On one of our Vista test boxes I am getting a ver
I think it's because of this: "[0CBC:086C][2013-03-25T11:46:44]w308: Automatic
updates could not be paused due to error: 0x80080005. Continuing..."
It is due to something wrong with Windows Update. I got that on a Windows XP
computer once where windows update was not run for a long time but when
On one of our Vista test boxes I am getting a very slow install
[0640:0DCC][2013-03-25T11:40:31]i299: Plan complete, result: 0x0
[0640:0DCC][2013-03-25T11:40:31]i300: Apply begin
[0640:0B60][2013-03-25T11:40:34]e000: Error 0x8007006e: Failed to load
version check XML document.
[0CBC:086C][20
On 11/04/2013 14:23, Sergey Yukhno wrote:
> Can't install Wix 3.8 on Windows XP.
> "Wix38.exe is not valid Win32 application."
That looks like a problem with the VS 2012 settings. I thought we'd
fixed them all - what build are you trying to install?
--
Bruce Cran
--
Classification: Public
Looks like your custom action is trying to run on uninstall (LaunchApplication)
which properly is NOT a good idea?
If you only want your custom action to run during installation perhaps you
should have a condition:
NOT
Installed
You can turn on verbose logging for the MSI
Hello.
Can't install Wix 3.8 on Windows XP.
"Wix38.exe is not valid Win32 application."
Best regards,
Sergey Yukhno.
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data
I've found the following entry in the verbose logs:
MSI (s) (F0:E4) [05:36:30:999]: No System Restore sequence number for this
installation.
MSI (s) (F0:E4) [05:36:30:999]: Unlocking Server
MSI (s) (F0:E4) [05:36:30:999]: PROPERTY CHANGE: Deleting UpdateStarted
property. Its current value is '1'.
On 08-Apr-13 09:50, David Steadman wrote:
> Ok I am not sure what I am doing wrong but following the guide and it
> still will not create the keys, what am I doing wrong:
A verbose log will tell you.
--
sig://boB
http://joyofsetup.com/
-
Thanks again Bob, in many ways you're my only hope!
I've found the logs in %temp%. If I remove the directory contents and use
control panel to uninstall, the result are 3 log files, 2 are verbose and 1
is the Burn summary we get in the log file link on the bootstrap failure
link.
The problem is I
On 11-Apr-13 08:28, penderi wrote:
> Thanks so much for the response. The MSI, when I install/uninstall on it's
> own works fine.
> How can I get a verbose log from uninstalling the bootstrap EXE ?
Burn generates a log for each package, next to the Burn log and with the
same base name.
--
sig://
Hi Bob,
Thanks so much for the response. The MSI, when I install/uninstall on it's
own works fine.
How can I get a verbose log from uninstalling the bootstrap EXE ?
Sorry if I'm being a dumb a??
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.
On 11-Apr-13 05:00, Ian Pender wrote:
> [0F30:0F50][2013-04-11T00:29:59]: Applying execute package: x86, action:
> Uninstall, path: C:\ProgramData\Package
> Cache\{129A003A-2370-4378-B0FA-10509C76FE2E}v1.0.0.0\App.Net.msi, arguments:
> ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" AUTOUPDATEE
What if the filename changes at some point in the future? Then I need to
remember to change it in 2+ places, rather than only one.
But yeah, using Properties or preprocessor variables seems to be the solution.
Thanks.
-Original Message-
From: Peter Marcu [mailto:peter.ma...@microsoft.c
Hello.
Error at creating user on Windows XP with error dialog "...Setup wizard ended
prematurely". Wix version 3.8.
Thanks Dave.
Luckily for us the items we want to store can reside in an unsecured folder,
so I don't need to jump through that hoop.
I'm getting failed installs due to hash match failures, but in the scheme of
things its probably best I create another topic. Thanks for your feedback :)
--
View
-Original Message-
From: Ian Pender
Sent: 11 April 2013 10:04
To: 'wix-users-requ...@lists.sourceforge.net'
Subject: RE: confirm 61359b3ef0e495a8c4245c43ba4be59c42d9fb85
-Original Message-
From: wix-users-requ...@lists.sourceforge.net
[mailto:wix-users-requ...@lists.sourcefor
I've been trying to produce a bootstrapped EXE of our MSI installer with .Net
4.0 from the web for a few days now and I need some help.
We've a simple MSI and need to Bundle it with .Net4. We've 2 variants of the
MSI - x64/x86 and that's handled in the Bundle in the usual way.
The MSI installs
44 matches
Mail list logo
