The verbose log will explain the 'why'. Look in your %temp% folder at the
log files. If the failing msi signaled a failure it will be in the log. If
using a custom BA, an example of how to handle the error is in the wix
source under Setup/WixBA/InstallationViewModel.cs in the ExecuteError
any ideas someone?
shouldn't this be relatively simple?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ExePackage-SourceFile-How-to-set-to-a-dynamic-path-tp7598962p7599001.html
Sent from the wix-users mailing list archive at Nabble.com.
When I get a 'strange' error, I use Notepad++ to search the wix source. In
this case I did not fince that string. I think that LGHT0001 is a catch-all
error message and the actual message is bubbling up from .Net, but I could
be wrong.
However the problem is probably related to the following
Hi Phill,
Thanks for your answer.
what do you mean by 'custom action' type behavior?
the only thing I'm trying to do is run an exe, and the exe's path depends on
2 variables (windows folder, and versionNT).
Why can't I do this in Burn? why does the path have to be predefined?
I don't understand
It looks like you are trying to do 'custom action' type behavior in the
bundle chain, which is not really what the ExePackage is for. The
ExePackage must be available at build time, so that a thumb print of the
package can be embedded in the bundle for security reasons, as I understand
it.
In another thread last week, I tried to extend util:User by adding an
attribute. I eventually determined in the code that adding an attribute is
not allowed for this element. So I assumed that I could add a child
element, but also does not work. UtilCompiler.cs has the following code
I am also learning these details, but I have seen this come up previously in
the forum.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-config-file-Answer-file-td7593918.html#a7593920
On 26-Jan-15 10:38, Phill Hogland wrote:
I want to extend the behavior of the util:User element to hide the service
account from the logon screen. If I am going at this the wrong way, what is
the correct approach?
The best approach is probably the custom attribute. In WiX v3.x,
extensibility
Maybe I posted this too soon. I am working on adding the custom element as a
child of Component and passing in a key to the specific user entry in the
User table.
--
View this message in context:
+1 for this method.
The BA can do initial validation, pass the valid key to the MSI as a property.
Your application still needs to do a sanity check on startup to ensure it's
valid, but at least application startup checks are a bit harder to defeat.
-Original Message-
From: Pally
I think that this was pointed out earlier, but mapped network drives are User
resources and may not be defined for another user, and would not be
available to localSystem.
--
View this message in context:
I have changed the code for using XmlConfig instead of XmlFile, but the result
is the same:The file is installed correctly but when the XmlFile or the
XmlConfig try to access the file to change an elment of the xml fileit report
an error that say that it can't find the Drive on network, and the
A very simplistic way to do it would be to add a LaunchCondition to your MSI
which the bootstrapper provides.
Something like
Condition Message=[ProductName] can only be installed using the
executable. Exit and run the executable to
install![CDATA[VALIDPRODUCTKEY]]/Condition
In your MSI and
Is this a per-user or per-machine install?
If it's per user, the install should not be elevated and it should run in the
same context as the logged in user. If it's a per-machine install, then it
will be elevated but it shouldn't be writing out required files to a per-user
Documents folder.
14 matches
Mail list logo
