Hi Rob,
we do also have the need of an elevated BA. Our BA collects all the
information required for the installation in a kind of setup wizard.
robmen wrote
> Your BootstrapperApplication should not be modifying machine state at all.
The elevation is needed, because we want to check for the e
Hello Bob,
Bob Arnson-6 wrote
> Then please file a bug with sufficient detail to reproduce the problem.
There is already a bug filed: https://sourceforge.net/p/wix/bugs/3244/
Unfortunately it was marked as "expected behavior" although this scenario
was working in v3.5 and is not working any mor
Hi Guys,
we are using the way of building patches as described in WiX help "Patch
Building Using Purely WiX", meaning that we are building the delta from the
wixpdb's using torch.
The only difference to the sample is that the files for the different
versions are always in the same location during
Hello,
today I upgraded from WiX 3.6 Beta to version 3.6.2603.0. Now none of my
managed custom actions is compileable any more.
There are two problems:
1) the reference to Microsoft.Deployment.WindowsInstaller seems to be ok on
the first glimpse but none of it's types is available and in the pr
I faced the same problem with the .Net 4.0 prerequisite. It seems that the
package is actually downloaded, even though it is not uninstalled.
Here is my package declaration:
http://go.microsoft.com/fwlink/?LinkId=164193";
DetectCondition="Netfx4FullVersion AND (NOT VersionNT64 OR
Netfx4
Hi folks,
as I read in the WiX 3.6 Beta release notes, burn does support package
ref-counting now, which according to my understanding should guarantee, that
shared packages are uninstalled only if all bundles sharing the packages
were removed.
Here is a little example:
- install Bundle1(contain
Rob Mensching-7 wrote
>
> The BootstrapperApplication.xml should list all the payloads, so if you
> really want to do this upfront, your BA should be able to it (plus using
> the WixBundleOriginalPath variable).
>
In the temporary folder I found a file BootstrapperApplicationData.xml. I
guess t
In our MBA we implemented a setup wizard with a feature selection on the
first step. My intention was to give a hint to the user in case of missing
or invalid packages *before* he entered the necessary information and the
installation actually begins.
Rob Mensching-7 wrote
>
> 1. If a package ca
e packages relative to the bootstrapper. But in events like
BootstrapperApplication.DetectPackageComplete there is no such information.
2) Here it would be useful to know what burn does to check if the MSI file
is the one which was used during build. Is it a CRC check?
Best regards
Kryschan
--
t;
>
It would be great if any of the WiX developers can make a statement when
this bug will be solved. I contacted the assigned developer but got no
reply.
Best regards
Kryschan
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Hidden-Bundle-Var
Hi Rob,
Rob Mensching-7 wrote:
>
> You're supposed to display UI and only elevate when the user does an
> action that
> requires it.
>
I agree with that and I was searching for a while to find a programmatic way
to reqest elevation from .Net so that I can force the BA to elevate right
before i
Hi!
My bootstrapper application needs to gather some information from IIS and
therefore needs to be elevated.
Is it possible to embed a manifest requesting the level
"requireAdministrator" into the bootstrapper? If yes how would this be done?
Best regards
Kryschan
--
View this
logged in clear text (in arguments list).
Is there something else to do besides setting the hidden attribute to "yes"
on those variables?
Best regards
Kryschan
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Hidden-Bundle-Variables-tp66057
Sorry but I still don't know what to do now to make my bootstrapper build
again. Can you please give me a hint on that or do I have to wait for the
documentation update?
Best regards
Kryschan
Rob Mensching-7 wrote:
>
> Ug, sorry, I forgot to update the documentation about the brea
) is
unknown. ...
When using WixStandardBootstrapperApplication.RtfLicense instead, the
project builds.
It was working in version 3.6.1817.0. Do I have to change something in my
bundle or is this a bug.
Best regards,
Kryschan
--
View this message in context:
http://windows-installer-xml-wix
Kryschan wrote:
>
> I'm trying create a bootstrapper containing some 64bit MSI packages, which
> (of course) shall be installed on a x64 system. As the MSIs are installed
> in silent mode, my bootstrapper should gather the required information
> from the user, which also inc
16 matches
Mail list logo