Hi,
I'm one step further.
The action setAccessRights is not involved - I had removed it for my
tests.
So I just found
DirectoryRef Id=Directory.ProgramData.Contest
Component Id=Component.Directory.ProgramData.Contest Guid=
{9AAF8540-6580-42A7-ACD0-F7806BAD12F5}
CreateFolder
Hello,
we are migrating from another chained MSI installation (in fact we used
ISChainer, but I do not think that matters) to Burn.
There are several bundles that may be installed in parallel and that share some
of their packages. With WiX 3.9R2, the dependencies among these Burn bundles
are
Hi Rob,
in the scenarion where the QA has reported this behaviour my
setAccessRights action had a bug and did not do anything, so no ACLs where
changed :-(
But how is setAccessRightsinvolved and what will this action do?
If I could find a way to set a condition for the setAccessRights action
I just added a false condition to my setAccessRights action so the action
was skipped., but still the ExecSecureObjects action does took much
longer with many files in my ProgramData folder. :-(
How can I control ExecSecureObjects?
Thanks,
Thomas
Von:
Hello, Phil.
Thank you for answer.
Here is the link to the source code and logs:
https://dropmefiles.com/3amOx
I have made simple minimal test project and same behavior occured.
In quiet mode:
MSI (s) (68:14) [00:37:40:531]: Feature: *Child1*; Installed: Absent;
Request: *Absent*; Action:
Hi,
In my Managed Bootstrapper, I tried to call
Engine.EvaluateCondition(MY_PROG_FOUND); in Run() method. But it never
evaluates and said something like: This requires a running thread. and it
never evaluates.
I'm trying to evaluate Bundle conditions in my managed bootstrapper but
still no luck.
I see the fix in wix39rtm.
WiX 3.9 and Bullseye appear to work better together. We're going to
recommend upgrading to WiX 3.9.
On Fri, Jul 3, 2015 at 8:54 AM, Rob Mensching r...@firegiant.com wrote:
I was looking at HEAD. Bug fix in WiX v3.9 or v3.10?
The error you are getting is: FDIERROR_NOT_A_CABINET
(This would go after your last call to light.)
http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html
Signing a package
insignia -ib Setup.exe -o engine.exe
signtool engine.exe (extra parameters excluded for simplicity)
Wouldn't the right way be to manifest the EXE declaring which version of
Windows it is compatible with, and let the newer OS's decide if they need to
shim the app?
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Monday, July 06, 2015 3:11 PM
To: General
Just a guess but...
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Clients\Media\QuickTime Result=exists
Variable=QuickTimeFound64 Win64=yes /
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Clients\Media\QuickTime Result=exists
Variable=QuickTimeFound32 Win64=no /
-Original Message-
Playing with fire writing to the Windows Installer's private data but I don't
have other ideas if old chainer doesn't have a sharing mechanism.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
I have a msi that has its InstallScope set to perMachine and it creates a
shortcut which is available to all the users:
Directory Id=ProgramMenuFolder
Directory Id=CompanyShortcutsDir Name=My Company /
/Directory
Component Id=CMP_MainExeShortcut
Directory=CompanyShortcutsDir
It might be works as designed. Raymond Chen appears adamant that it
shouldn't be done in an install anyway:
http://blogs.msdn.com/b/oldnewthing/archive/2010/03/11/9976571.aspx
---
Phil Wilson
On Mon, Jul 6, 2015 at 9:52 AM, Chris Moxon chris.mo...@eque2.com wrote:
I have a msi that
There appears to be something wrong with your test methodology. The
quiet log shows a run that finds an upgrade, but then you run the UI
install and that log says Product registered: entering maintenance
mode and Skipping FindRelatedProducts action: not run in maintenance
mode, and Skipping
Thanks very much, Jacob - it’s working!
In case it helps anyone else: it works to use kSignCMD.exe (free download from
K Software) in place of the 2 calls to signtool.
On Jul 6, 2015, at 4:13 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote:
The error you are getting is:
Hi,
I’m brand new to code signing. Just got my certificate through K Software, a
Comodo reseller. I tried adding a call to kSignCMD.exe at the end of my build
script, and it appears to work: the properties for my installer show my
certificate, and the UAC prompt when I install also shows me
I cannot get this to work correctly. Here is the log...
[08B4:040C][2015-07-06T10:50:14]i000: Registry key not found. Key =
'HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime'
[08B4:040C][2015-07-06T10:50:14]i000: Setting numeric variable
'QuickTimeFound64' to value 0
Hi Folks,
I have a query and hope someone would guide me properly.
If I run an exe in an msi through some custom action,it is run as an out of
process method.
That is to say the msiexec runs as process1 and the exe runs as process2.
Would it be possible to somehow run the exe within the
An executable will always be executed as a child process of the process which
launches it. Even if you ship a DLL as your custom action you'll need to call
RunDLL32.exe to actually execute the code.
I don't think this is the question you need to be asking. What are you actually
trying to
19 matches
Mail list logo
