Anecdotally, we have a release based on 3.8 and I tried a patch using 3.9
(the release just prior to 3.9r2) and ran into some odd problems which were
resolved by sticking with 3.8. I think I posted something about it to the
list a while back.
Rob Mensching-7 wrote
It will probably work but you
The fact that it works when used from the MSI instead of the bootstrapper
means that application contexts are not the problem. In the meantime I
found a conversation on wix-devs which implies that this won't be
implemented any time soon. Fine.
What I ended up doing for now is writing a
Hi all -- dumb question here. I've noticed that util:CloseApplication works
within an MSI, but when that MSI is used within a bundle, we are simply
prompted to reboot instead of the nice prompt.
Is there a cheap dirty way to get the MSI-only behavior in the bundle
without writing our own
This worked fine for us inside OnDetectComplete on Wix 3.8 (released
version). For example :
// Check if Acrobat is installed by reading variable.
LPWSTR sczAcrobatValue = NULL;
BalGetStringVariable(LAcrobatInstalled, sczAcrobatValue);
BalExitOnFailure(hr, Failed
.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: roberthyang [mailto:
robert_yang@
]
Sent: Tuesday, March 17, 2015 12:32 PM
To:
wix-users@.sourceforge
Subject: Re: [WiX-users] Xpath Expression
When developing
When developing a custom action, it's usually a good idea to try the
important logic in something easier to debug first, like a console app.
Trying to debug both the custom action stuff AND the application-specific
logic at the same time can be daunting otherwise, not to mention
time-consuming.
You can do string comparisons, eg. REGVAL = #12300 but of course it will
be a bit brittle. If your expected values are say, 11200 through 9 then
it's probably fine, but once it reaches 10 then there will be problems
:)
Kevin Palmer wrote
Hi,
I've searched and cannot find a suitable
Thanks for the hint Nick. Here is my torch cmdline :
%WIX%\torch -ax %PATCH_ADMIN_INSTALL% -p -xo
%BASE_ADMIN_INSTALL%\setup%BASE%.msi %PATCH_ADMIN_INSTALL%\setup.msi -out
%PATCHDIR%\diff.wixmst
I tried both -ext UtilExtension and -ext
I tried this, and also '-ext %WIX%\WixUtilExtension.dll', and while
torch/pyro didn't complain, I also didn't see an XmlFile table added by the
.msp. The XML file was not modified when I ran the resulting patch, though
the log did indicate that the enclosing component was installed.
Same result
Hi all -- we are using Wix 3.8 in both our released product and service pack
1, created via torch/pyro as a .msp. We need to be able to conditionally
modify an XML file installed with the released product.
I was able to get the patch bootstrapper to show a couple of radiobuttons
using a custom
In order to do this you need to run as a user identity that has network
privileges and access to the network location you need to access. If you
have Impersonate=no and Execute=deferred in your custom action, then you
will be running as LocalSystem, which does not have network privileges.
Hi all -- we have a requirement for our service pack patch (using Wix 3.8) to
show a dialog that isn't shown in the base MSI. Is there a way to make this
work, outside of a custom bootstrapper application ? I noticed this item :
http://wixtoolset.org/issues/2430/
I ran a quick test and noticed
That worked great. For future reference of folks who are perusing the
archives, the SP1 RelatedBundle points back to the original bundle's upgrade
code, and has a new guid as its upgrade code.
I also learned that problems result if the SP1 bundle is built with 3.9 (the
original bundle is built
Hi all -- things have gone well with our product and Wix 3.8. We are using
the stdba and now I'm working on service pack 1, using torch/pyro/etc. via a
.msp file.
When I create a bundle to install the .msp, a new entry is put into the ARP.
Let's say the original bundle is called My App. The
Aha ! This would explain what we have been seeing: if the install is done
after KB2918614, then the repair is successful. If the install was done
prior to KB2918614, then the repair for SQL Server CE 3.5 SP2 x64 fails.
The difference in the log is as follows :
MSI (s) (50:CC) [12:30:26:258]:
in Wix 4.0.
One of my user is getting the same error message after uninstalling the
windows update. Did you find any way to make it work Robert ?
-Original Message-
From: roberthyang [mailto:robert_yang@]
Sent: Friday, 29 August 2014 5:53 AM
To: wix-users@.sourceforge
Subject: Re: [WiX
Logs are created in the user's temp folder: open a command shell and type
set, then look for the TEMP environment variable to see where this is
(C:\Users\roberyan\AppData\Local\Temp, for example). The bootstrapper
generates a log, and there should also be logs for each item in the bundle
that
We just started seeing a possibly-related error recently. We have a burn
bootstrapper in Wix 3.8 and among the bundle MSI's is SQL Server Compact SP2
x64 (SSCERuntime-ENU-x64.msi). When the bootstrapper attempts to repair the
application, the repair of SQL Server Compact SP2 x64 fails with Error
to read from the file
C:\ProgramData\Package
Cache\{D4AD39AD-091E-4D33-BB2B-59F6FCB8ADC3}v3.5.8080.0\SQL Server Compact
Edition\SSCERuntime_x64-enu.msi
Any thoughts ?
roberthyang wrote
We just started seeing a possibly-related error recently. We have a burn
bootstrapper in Wix 3.8 and among
Hi all -- we have a bundle containing MsiPackage entries for SQL Server
Compact 3.5 SP2. There are actually two MSI's: x86 and x64. The latter
seems to have problems being repaired via our bootstrapper (standard burn
bootstrapper application, no custom code). I don't want to further hijack
Thanks everyone for the advice ! SuppressSignatureVerification=yes worked
for this user.
Another tidbit is that he was running the EXE as admin, and interestingly
the UAC prompt showed unknown for the publisher name. When I try the same
thing I see a prompt with our company name.
I'm tempted
No takers ? The bundle installs just fine on most Windows 7 machines, but
for whatever reason not on this particular user's laptop.
The bundle simply installs .Net 4.0 and then the product MSI. I gave the
MSI to the user and it installed no problem. Then I rebuilt with Wix 3.7
and let the user
Hi all -- we've got an installer built with Wix 3.6 stable (3.6.3303.0) and
burn (using the standard BA). On one particular machine it is failing with
the following error displayed to the user :
0x80096005: The timestamp signature and/or certificate could not be
verified or is malformed
Here is
Also look into Package/InstallScope, which might be more appropriate.
Gerry Reno wrote
It looks like adding this to Package may do the trick:
|InstallPrivileges=elevated|
I'll try it and see.
On 01/21/2014 08:21 PM, Gerry Reno wrote:
I have a WIX installer built that installs fine
Preferred solution is to harvest the registration info from the DLL's using
heat.exe (see 'file' harvest type) at installer build time.
Tony Jose Mampilly wrote
Hi,
For one of our application after installation, 4 dlls are needed to be
registered using REGASM.exe. Earlier when we were
For some of our builds we have a post-processing step which modifies
heat-generated WXS files and also coalescesces multiple components into a
single file (one build in particular has ~100 harvested components). For
example, we insert an appropriate Directory attribute into the generated
I'll try narrowing the scope of my question a bit. Suppose I have the
following code in my bundle.wxs :
Fragment
lt;!-- check if B installed, for uninstallation --gt;
util:RegistrySearch
Id=B_InstallCheck
Root=HKLM
Sorry, I must be having an RTFM day :) This seemed to work :
bal:Condition Message=B is installed. Please remove it first.NOT
(B_Installed AND WixBundleAction=3)/bal:Condition
This way the bundle only uninstalls if B has already been uninstalled. Hope
this helps.
--
View this message in
Hi Rob -- I sent an email from my work address a while back, but I guess it
didn't get through.
Anyhow, yes I am interested. Probably better to use this address: wix at
rhysw dot com. Thanks !
-Rob Y.
Rob Mensching-7 wrote
If you can wait a few more weeks, this might be an interesting thing
29 matches
Mail list logo
