be deleted.
Fabrice
-Message d'origine-
De : Michael Turner [mailto:
mcturner319@
] Envoyé : jeudi 9
octobre 2014 17:59 À :
wix-users@.sourceforge
Objet : Re:
[WiX-users] How to hide a file in WXS configuration file ?
Fabrice,
The CopyFile element is kind
Fabrice,
The CopyFile element is kind of an oddball, particularly in the use-case
where it points to another File in the same installer. Sure, the CopyFile
element exists, and it supports copying a file that you're already
installing, but I've never found a good reason to use it in this way; it
Try adding Secure=yes on the Property. This means that the Property can
be passed to the server side when doing a managed installation with elevated
privileges. I don't fully understand what the server side is, but I
think it has something to do with the transactional part of the
installation,
Chris,
This looks like a bad design choice in the previous version. Most of the
time, you're going to want to embed your custom action DLL as a Binary in
the MSI package rather than installing it on the target machine as a File in
a Component. I.e., put the custom action DLL on a Binary rather
further adjustments to the custom action
DLL to ensure that it is fully self-contained for use in subsequent versions
(e.g., if it's a C# or VB.NET DLL, make sure you're using the one whose name
ends with .CA.dll).
Regards,
Mike
Michael Turner wrote
If you are in this situation, here's a workaround
From http://msdn.microsoft.com/en-us/library/aa371634.aspx
Note: Services that rely on the presence of an assembly in the Global
Assembly Cache (GAC) cannot be installed or started using the ServiceInstall
and ServiceControl tables. If you need to start a service that depends on an
assembly in
Uma,
Apologies for the delayed response. If you haven't figured it out already,
you only need to remove the parent 'SnippetDir' node, and all of its
children will be removed with it. However, you will need to be clever with
your XPath to make sure you select the correct 'SnippetDir' node for
Chris,
Is your new version a Major Upgrade
(http://msdn.microsoft.com/en-US/library/aa369786.aspx), as opposed to a
Small Update or Minor Upgrade
(http://msdn.microsoft.com/en-us/library/aa370579.aspx)? Also, if it is a
Major Upgrade, then when is your RemoveExistingProducts action scheduled?
Dileep,
Theoretically, there are other ways to utilize the WiX Toolset without
formally installing it on a machine, but none of them work very well with
Visual Studio Integration. If you're using Visual Studio Integration and
you only need to work with one version of the WiX Toolset at a time,
Chris,
Well, it looks like you've found a workaround for now: just uninstall the
old version before installing the new one. It isn't pretty, but it seems to
be working for you. Sometimes, that's just what you have to do when you're
migrating from one toolset to another.
But if you want to
I'm not sure what you are expecting $(FrameworkSDKDir) to point to in a
.wixproj. Which version of the framework? There is no clear answer to this
question within the context of a WiX project, because WiX projects do not
target .NET Framework versions and do not use the .NET Framework SDK.
Have you tried running the application without going through the shortcuts?
It is possible that the application may be crashing, and your machine may be
configured to go straight to the debugger when a crash occurs. Usually when
this happens, something is logged in the Application Event Log, so
Uma,
First of all, I don't think you can insert XML before a given node using
XmlConfig; you can only append a new child to a given parent node.
(http://stackoverflow.com/q/8224918)
Also, there are two nodes that match your XPath expression, and XmlConfig
only uses the first match. Since you
Scott,
Is your product using conditional Features? One way that components can get
orphaned is if they belong to a Feature whose Level is 0 at time of
uninstall. Usually this happens when the intent is to install the feature
only if a certain prerequisite software is present, and if the
I have encountered this also. This a defect in light.exe 3.0.5419, which I
confirmed by downloading the WiX 3.0.5419 source code and searching for the
error message. (I did this a few months ago, so I can't remember the exact
location off the top of my head.)
This is what the linker does in
Does anyone have experience using 3.5-built wixlibs with light.exe in WiX 3.6
and 3.7? For purposes of this discussion, I'm only concerned with the
official RTMs (3.5.2519.0, 3.6.3303.0, 3.7.1224.0).
My objective is to use wixlibs for inter-project collaboration, so that one
project can produce
Condition Level=0 is tricky. There's a warning about this buried in the
MSDN documentation for the Condition Table
http://msdn.microsoft.com/library/aa368014.aspx : Conditions should be
carefully chosen so that a feature is not enabled on install and then
disabled on uninstall. This will orphan
The syntax rules for ComponentGroup and FeatureGroup IDs seem to be fairly
liberal: just about anything goes, including embedded spaces and
backslashes (i.e., characters that are not allowed in traditional
identifiers). Of course, $(...) and !(...) are still special and can be
expanded (if
Dirk Ziegelmeier wrote
here is a minimal mergemodule showing the error:
?xml version=1.0 encoding=UTF-8 ?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Module Id=MergeModule Language=1033 Version=1.0.0.0
Package Id={SomeGUID} Manufacturer=ACME InstallerVersion=200 /
Nirmalraj,
I have implemented something similar, and I ran into the same problem that
you did. In my implementation, I created additional custom dialogs to
display messages if the Password and Confirm Password entries did not
match or if either the user name or password was empty. Then I keep
I am using WiX 3.5 RTM (3.5.2519.0). I have several x64 products that
depend on a COM+ application, and they may be installed either concurrently
or separately, so I am using a Wixlib to include the COM+ application in
the main feature of each product. I use a custom dialog to prompt for a
user
21 matches
Mail list logo
