I believe so. Please test and report back (I'd like confirmation either way).
> Date: Wed, 26 Jun 2013 02:11:19 +0530
> From: chentala.srini...@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Require admin rights to msp
>
> Hi,
>
> The actual requirement is
> I have a
You could try to confirm it by running a "set" command in your build to measure
the size of your environment block, but it'd guess that is your issue (VS adds
to the environment block). I'd need to search again for the reference to the
bug to remember what the size limit was.
> From: kmo...@pr
Hey Alain,
Take a look at my answer to this problem on stackoverflow -
http://stackoverflow.com/questions/6913332/wix-installer-problem-why-does-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540
Basically, you can 'lie' about the custom action and mark it as
immediate instead of de
You could certainly create your own custom property and store it in the MSI
file after each build, and extract it to see what your internal version is,
but I would avoid ProductVersion because that's already the name of the
Windows Installer property, and could cause confusion anyway.
It won't he
Hi,
The actual requirement is
I have a msi which is having elevated rights(InstallPrivileges ="elevated",
Privileged Launched condition and digitally signed).
And simply created the patch by following the Link:
http://wix.sourceforge.net/manual-wix2/patch_building.htm with out adding
signing or a
Sorry, let me clarify: the Windows 7 machine is my development machine. I am a
local admin, and I can code and compile in .NET, and create and compile WiX
projects, etc. from this machine with my company network logon with no other
issue.
I have run installs, including Visual Studio and SQL
Good point;
Since I started this thread an engineer I work with suggested I use a new
attribute called ProductVersion that is not bound by the 255.255.65535.65535
limitation. I've started testing this approach to see if it will solve my
issues...
Thanks for your time and feedback...
Later,
I tried to use the Heat.exe to create the PayloadGroup, but the heat has just
generated components
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-a-ExePackage-with-many-payloads-tp7586808p7586843.html
Sent from the wix-users mailing l
Can you install an MSI from the same user account/environment? Are you an
interactive user or are you running from a service or a scheduled task?
Validation uses the same Windows Installer service that installation
transactions use.
Also I found a bug report that says that an environment bloc
Method #2 - apply from an elevated command prompt.
I'm a little unclear about the requirement. If the MSI requires elevation, any
applied MSP will prompt for elevation as needed and all non-impersonated
in-script actions will run elevated (same as the MSI, adding an MSP doesn't
change how that
I assume your bundle is a per-user bundle with a per-machine prereq. If so,
set ExePackage/@PerMachine = yes.
-Original Message-
From: Marco Tognacci [mailto:mark...@live.it]
Sent: Tuesday, June 25, 2013 12:20 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Burn setup set pr
I have a Burn setup, it correctly ask for privilege with UAC dialog if you
don't run it as administrator.I have an ExePackage in the chain and I want it
to be launched with administrative priviledge, I haven't found any property in
the ExePackage, what I need to do to pass the high priviledge to
Digitally sign the original MSI, include the public cert in the
MsiPatchCertificate table, and then sign the MSP with the same certificate.
And in the wixproj,
http://timestamp.digicert.com /a "%(SignCabs.FullPath)"" />
http://timestamp.digicert.com /a "%(Si
Hi,
I have a patch(.msp) file which will works fine only if it runs from
administrative command prompt on UAC on machine.
Can anyone please let me know how to give admin privileges to .msp.
Regards,
Srinivas.
--
This SF.n
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx
Symbol names and values are case sensitive.
Environment variable names are not case sensitive.
Literal text must be enclosed between quotation marks ("text").
Note Literal text containing quotation marks cannot be used
Simple question that I cannot find the answer to?
Are conditions case sensitive?
Thanks
Natalie Carr
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
I'm using VS 2010 SP1 on a Windows 7 machine. When I build in VS, I get a
message that I can't validate due to system policy. I tired to validate
through Orca, and got an error that the validation engine couldn't start.
Does anyone know what system policy has to be changed to let me run
validatio
Is the purpose of the CA simply to ensure that elevation is happening or is it
because you intend to make some changes to the system?
If you simply want set the package to always require elevation then include the
Package\@InstallScope set to "perMachine" and remove the
Package\@InstallPrivile
On 2013-06-25 5:23, Bob Arnson wrote:
> On 24-Jun-13 14:17, Lukas Haase wrote:
>>
> Custom actions after InstallFinalize cannot run elevated.
Thank you. What would be the best place to include this CA and ensure
that it runs elevated?
Luke
---
Does the file "lookserver.config" already exist before you run your
installation transaction? If not, it is expected that a rollback of it's
permissions would not be possible (the file itself will, however, be removed
upon rollback in that scenario so it isn't an issue that the rollback for the
The Id of a Directory is/becomes a property with the same Id and its value is
the full path of the directory. If that property already exists before costing,
its value is used as the directory's full path.
Thus, do a RegSearch into a public property, name the directory with the public
property
1. Use an immediate custom action to generate the "scrambled" registry value
into a property (C++ or .NET via DTF).
2. Encode the current ProductVersion property into that value as well. If the
value already exists in the registry (use a property initialized via RegSearch)
verify if the embedd
If your bootstrapper is able to extract the correct MSI file and the CAB file,
it only needs to place both into the same directory and install the MSI (which
will then find the external CAB in its same directory) and that way you avoid
any install-time manipulation of the MSIs (such as embedding
23 matches
Mail list logo
