If the solution has C++ projects, they must use Win32 rather than x86. (I
also tried to change them to x86 and found that C++ does not support x86).
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Requesting-assistance-with-two-build-errors-tp7592
I mean I found that VC C++ project does not support using x86. Win32 must be
used (or x64, etc.)
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Requesting-assistance-with-two-build-errors-tp7592664p7592672.html
Sent from the wix-users mailing lis
As Neil indicated you have to provide correct names in your Payload
attributes.
Here is another discussion about this issue:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-theme-in-Bundle-how-to-add-xml-and-wxl-td7588021.html#a7588026
http://windows-installer-xml-wix-toolset
In studying the source code I notice that the GamingExtension and the
IISExtension, among others, have a data\messages.xml in the wixext project
tree. I tried to add a similar file to my project, changing the namespace,
class name, and container name. However in the compiler extension code the
cl
Your call to dism has the path '[WindowsFolder]SysWOW64\dism.exe'. If you
open an Admin CMD box and type your full command you will get a better
explanation of the error. SysWOW64 specifies the 32 bit operating system
files. Error 11 is returned which indicates that you cannot service a
running
Did you type that command in a Admin CMD box and see what happens? It does
not work for me either.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Simple-MSI-failing-Error-3-2147287038-tp7592771p7592792.html
Sent from the wix-users mailing list ar
have you looked at the following file in the source tree?
src\ext\NetFxExtension\wixlib\NetFx451.wxs
And the help doc is here:
http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/check_for_dotnet.html
The help doc does not mention 4.5.1 but the support was add
Sounds like you got it, but you might also consider using dark.exe to
decompile your previous VS create msi and see how it would build the wxs
file. I found doing this in certain situations to be instructional as I
started to figure out wix.
--
View this message in context:
http://windows-inst
Thanks for the assistance. Got it working. I'm not sure that I fully
understand how the ContainerName and BaseContainerName attributes should be
set in the messages.xml file, but it seems to work with the strings I
provided. Thanks again for the assistance.
http://schemas.microsoft.com/genmsgs/
Actually it turns out that it is not actually "working". It was "working' in
the sense that the above changes allowed the Compiler Extension project to
compile succesfully. However in a nost project, if the compiler encounters
any message related to this XML file it throws the following exception
Thanks for the tip. ILSpy seems to be a very helpful tool. There were
several issues, but basically I had set the EmbeddedResource property on the
messages.xml file, when what was needed was to set that property to 'none'
and generate a 'messages.resources' file with MsgGen, which was added to th
I think (and I am not an expert) that the Component condition is only
evaluated the first time it is installed, unless you also mark the component
as Transitive. So if you add that Condition statement to the component, I
think you want to also add Component/@Transitive="yes".
--
View this mes
There are some ideas here:
http://superuser.com/questions/521175/determine-if-windows-hotfix-has-been-applied
A msu is a compressed (zip) package from which the deployed files can be
extracted. You can chain an msi or an exe, but not a 'zip' package.
wusa.exe can be used to install an msu
http:
I'm sure that is probably true.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detect-if-MS-HotFix-installed-during-Bundle-installation-tp7592971p7592998.html
Sent from the wix-users mailing list archive at Nabble.com.
---
A project that creates a bootstrapper (and uses the Bundle element) should
produce an EXE, and not an msi. An MSI does not have the appropriate 'entry
point' which is what the error indicates.
You might find it easier to use the built-in support for installing .Net
4.0. In my bootstrapper (exe)
You can certainly achieve the goal that you defined. What I do is a little
different and is based on the structure that I observed in the Wix src\Setup
(the source for the setup which deploys the tools).
There you will see a CommonLib wixlib project. I define my folder tree (for
many different
Is "ProgramFiles\App\bin" is a valid path in this situation? I have not
tried this but I am wondering if you intended to provide a path relative to
a directory ID. "[directoryID]\App\bin"
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-che
I agree with Pally. It would be best to use the feature as documented in the
chm.
In general when using the ExePackage/@DetectCondition the chm says "Burn
uses this condition to determine how to treat this package during a bundle
action; for example, if this condition is false or omitted and the
There is a FileSearch in the Wix schema:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/filesearch.html
In this thread it was suggested that the problem is probably that the path
does not evaluate to a valid file path, but that is a guess.
http://windows-installer-xml-wix-toolset.687559.n2.
More information:
http://blogs.msdn.com/b/astebner/archive/2008/03/11/8163455.aspx
You might run into this issue:
http://support.microsoft.com/kb/928636
I appreciated the information posted in another thread on this general issue
about the Wix::MsuPackage element.
--
View this message in conte
I do not really know the answer to your latest questions. In a wix context I
think I would use the Wix:MsuPackage and let it handle those details (but I
have not had the ocassion to do that yet). I have previously installed msu
packages in a non-wix setup using wusa.exe "package-name.msu" /quiet
I'm still pretty new to wix, msi, and C#/wpf also, having come from a
C++/Installscript background. I felt overwhelmed for the first several
months, but persistence pays off. As I study the source code and the
schemas things start to make more sense. I think it will be worth the
struggle.
--
FYI - One strategy to learn that I have used is, a) I download the Wix 3.8
source tree, and b) when trying to do a particular task, I use Notepad++
Find-in-Files pointed at the Wix 3.8 source tree to search for similar
details to what I am trying to learn. This has helped me understand both
the C#
I have a bundle with an mba and several nearly identical MsiPackages (which
install various printer drivers). So except for a different path to the msi
the bundle MsiPackage authoring is identical for each driver package. The
thing that I noticed is that when I set LOGVERBOSE on the command line
Here is info on one approach.
http://stackoverflow.com/questions/12846421/getting-display-name-from-packageid
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-read-an-MSI-s-Product-GUID-from-Bootstrapper-Application-tp7593246p7593265.html
Sen
Regarding how to use the DifxExtension if you have the driver files, create a
msi which installs the drivers files to a cache location. (At that point
you, in general for any driver prior to using the DifxApi, you should be
able to right click on the INF file and see the driver successfully instal
Here are the PrintUI commands that I use. I would test your parameters on a
target machine in a admin CMD box prior to integrating into a msi.
LPWSTR pwzAddPrinterCommand = L"\"%lsRunDll32.exe\"
PrintUI.dll,PrintUIEntry /if /b \"%ls\" /f \"%ls\" /r %ls /m \"%ls\" /u /q
/z /Gw";
LPW
I could tell that the Command object was a single bundle instance. I had
read somewhere that a mba needed to implement passing those values to a Msi
and I was trying to find where to add code to add the values to the msiexec
command line. In my chain I have a mixture of my MSIs and third-party MS
For looking at this in the future reference I should add that original post
was deleted because I discovered that I was delusional when I wrote "Bundle
Command line not passed to second MSI package". An errant line of code was
causing the specific behavior that one MSI had LOGVERBOSE set and the o
I think the error is because AppendFormat is not passing an object (test) to
the formatted string. You also need to use HTML entities in the XML or use
CDATA.
string test = "xyz.msi";
sb.AppendFormat(@"", test);
http://www.dotnetperls.com/appendformat
http://en.wikipedia.org/wiki/List_of_XML_an
The core problem is that the version value is needed by the compiler, but a
bind variable is not resolved until the second pass of linking, so a bind
variable cannot be used in the version field, as I understand it.
There are various approaches to adding a MSBuild task which gets (or
creates) a ve
I'm asking for advice on the best approach in the following scenario. As I
read about the 'Remember Property' pattern, the discussion seems to be
related to deploying a MSI and the various ways that a user might launch the
MSI (ie. Install, Repair, Repair from ARP, ...) with that property on the
c
I have used heat.exe in Wix 3.7 and Wix 3.8, so I don't follow your comments.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Stuck-using-3-5-till-harvesting-returns-to-WIX-tp7593455p7593467.html
Sent from the wix-users mailing list archive at Nabb
I am looking for a way to open the msi database, check and see if a specific
action exists in the InstallExecuteSequence table, and if it exists to
modify the Condition statement related to that action. I have been
considering doing this either at compile time but am concerned about the
fact that
Thanks Jacob and rw1017. I am aware of both of those approaches, but my
situation is a little more complex. Based on past testing if I author a
Component with the INF file of a printer driver, which needs to be
configured as 'print-to-file', I can call CAs with a Property in the CA, as
Jacob sugg
To clarify when I have two components with the same INF file, but different
elements related to whether I am using the difx extension or my 'print2file'
extension, then ICE30 warnings are in the build output. I did not actually
test the behavior of such a package on a target system as I was trying
Also in reference to:
"The error received complains the reference to the $(var.ProductTitle) in
the 2nd WXI file Configuration.wxi is "Undefined preprocessor variable
'$(var.ProductTitle)". therefore implying the 1st WXI file StaticDef.wxi
has not setup its defined variables for use when the 2nd C
>>Is it possible to use a variable you define in your 1st WXI file within
your 2nd WXI file?
Yes. Just include the first wxi in the second wxi
First.wxi
Second.wxi
http://schemas.microsoft.com/wix/2006/wi";
xmlns:util='http://schemas.microsoft.com/wix/UtilExtension'
xmlns:
Yes a Property element can be under a Fragment or under a Product (or several
other possibilities). Look at the schema in the chm.
If you put it in a Fragment (whether in the same wxs as your Product or a
different wxs) your Product, generally speaking, needs to have some
'reference' to something
FYI - the code I just posted is still in development and may have issues, but
it is an example of referencing code in a Fragment.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Referring-to-variables-in-2nd-WXI-from-1st-tp7593502p7593514.html
Sent
Look at ProductSearch in the chm.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Identify-installed-product-by-productCode-tp7593540p7593541.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Notice that there is a Util:ProductSearch (for use in Bundles) and a
wix:ProductSearch for use in an MSI.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Identify-installed-product-by-productCode-tp7593540p7593542.html
Sent from the wix-users maili
Typically you would create a Bootstrapper project which has a Bundle element
and a Chain element. In the Bundle element you could use the
util:ProductSearch and then use the result to notify the user in the BA or
condition whether an MSI gets installed. The MSI would be added to the
Bundle's Chai
http://msdn.microsoft.com/en-us/library/gg513929.aspx
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Making-64-bit-installer-from-32bit-wix-file-tp7593557p7593558.html
Sent from the wix-users mailing list archive at Nabble.com.
--
I also stopped using Win64, but you need to make sure that the -arch flag is
being passed on the command line to candle and light. One way to do this is
to add the InstallerPlatform MSBuild Property to your project file. You can
unload your project file, and edit it, adding the following statemen
Others have provided good advice which should allow you to resolve the
problem. From an application perspective I would collect the same files in
the same folder tree that your wix installer is collecting, and manually
copy them to a PC which has never been touched by Visual Studio (or Blend).
Pu
Those two dlls are part of the Expression Blend Studio (which I have very
little experience with). However so far as I am aware, Visual Studio and
Blend are only deployed to 32 bit environments (x86 or WOW64) and the .Net
applications which consume those dlls should be compiled in Visual Studio as
I'm sorry. I did not see the latest messages in this thread, so I am
probably confusing things.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Making-64-bit-installer-from-32bit-wix-file-tp7593557p7593690.html
Sent from the wix-users mailing list
I am in a similar boat, converting an old IS script project to Wix/msi. So I
am also learning, and very impressed with WIX. Most of my time so far has
been trying to sort out oddball configuration issues for drivers. In my
case in some scenarios I need to get printer drivers installed as
print-t
This process can also be implemented using MSBuild by overriding the
predefined Targets SignBundleEngine and SignBundle. There is more
information in the wix source at src\tools\WixTasks\wix200x.targets
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.
For scenarios that involve running the installer past the detect stage, I
moved code to a test box, and I tried to use WinDbg. I installed windbg as
the default debugger and got it to attach when the code hits a
System.Diagnostics.Debugger.Break(); line in the mba's Run() function, but I
did not f
In my particular situation the test pc and the dev pc are on different locked
down networks so I could not get the remote connection to work. But I hope
to solve that issue in the future.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Debugging-M
I suspect the issue is that you need to remember the values of your
properties and retrieve them prior to doing the uninstall.
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
http://www.nichesoftware.co.nz/node/633
--
View this message in context:
http://
I noticed a problem once. Not sure why. I also saw comments from others
that this can be problematic, so I set SuppressSignatureVerification="yes"
on my packages in the bundle chain.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-fails-to
I have been experimenting with and creating a project which uses heat to
harvest files. Initially I did the development by creating a batch (cmd)
file which calls heat. Now I am in the process of modifying my project file
to use the HeatDirectory task, and implement the equivalent of my batch
fil
I used the information from the following link to configure a project to
build either a 32 bit or 64 bit installer.
http://alekdavis.blogspot.com/2011/05/build-32-and-64-bit-installers-using.html
My projects are for drivers and I need to install the full driver tree
regardless of which platform is
I right-click on the project file, and 'unload' the project, then edit the
project and add InstallerPlatform as follows (to each Property Group
Condition= 'test for configuration'
...
x64
..
...
x86
..
--
View this message in context:
http://windows-
You can do it that way, but there are other approaches. For most of my MSIs
I use the EmbedTransforms tool as described here:
http://wix.tramontana.co.hu/tutorial/transforms/morphing-installers
Then I just deploy the the MSI without any payloads. MSI automatically
selects the embedded transform
I don't think this is a wix issue. When I build Wix toolset 3.8 this
variable is defined.
I think it relates to the version of VS, Windows SDK, and .Net being used.
http://connect.microsoft.com/VisualStudio/feedback/details/811986/-frameworksdkdir-value-in-vs-macros-post-build-event-references-in
Thanks for the info. I have been spinning wheels on this issue also.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Environment-variable-ProjectPath-is-expanded-possible-to-turn-off-tp7587463p7594051.html
Sent from the wix-users mailing list arch
I have a bundle with a number of msi pacakges, one of which has a feature
which is advertised. Recently (probably because I changed something in the
authoring) I am noticing a behavior where if I install the bundle, then
after that completes successfully, click on the advertised shortcut, then
the
I think I have used something like this in the past?
InstallCondition="RuntimeVersion <=vx.x.x.x"
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-for-Version-Numbers-tp7594059p7594060.html
Sent from the wix-users mailing list archive at Na
In the prior post I meant to have the entity display:
InstallCondition="RuntimeVersion <=vx.x.x.x"
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-for-Version-Numbers-tp7594059p7594061.html
Sent from the wix-users mailing list archive at
When:
1) A cmd prompt is opened (in this case using the VS2010 CMD prompt)
2) A batch file which has setlocal also has a "set
projectPath=some_path_to_a_folder" (case of the variable name does not
matter)
3) And at some point in the same batch file or a different batch file (also
using setlocal) bu
Yes, the MSI package has the following:
When this package is launched as part of the bundle chain the log indicates
that ALLUSERS is 1.
This package has been installing with the feature advertized, but without
complaining about this registry value for some time. However I recently
refactored s
I don't want to violate the security. The applications in the bundle were
installed on the first install in a per-machine install. Burn was elevated
at the UAC prompt. There are many other keys which are part of this app
which are also written under HKLM. (I am not intending to do a per-user
ins
In your MSI you might want to look at the 'remember property' pattern. I
have found these posts helpful:
http://www.nichesoftware.co.nz/node/633
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
I use the above pattern for properties which are passed to MSI pa
While this is a answer to changing a different file attribute
(File/@Keypath), you would need to do something similar.
http://stackoverflow.com/questions/8034798/wix-installer-using-xslt-with-heat-exe-to-update-attributes
--
View this message in context:
http://windows-installer-xml-wix-toolset
Thank you for your time and comments. I am still digging through the verbose
log captured during the on-demand install. I am also re-reading the
sections in your book related to on-demand installs.
One brief clarification is that I run the wix bundle (with multiple msi
packages), which I compile
That information is already in the log, typically in your %temp% folder.
But for the specific question on how to set a property using another
property, use the SetProperty element.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Property-Id-Value
I would like to thank Phil (and others on this list) for the assistance in
tracking down this problem. The core problem is related to the following
attempt to write this registry value when the value of the SDA property is
not an integer:
It was introduced several weeks ago when I changed how t
Did you uninstall wix toolset and reinstall it after VS2013 was installed. I
have read other posts to the effect that just doing a repair is not
sufficient to detect a new version of VS on a system.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/
As I understand it component conditions are only evaluated the first time the
component is installed. If you want them to be evaluated again later they
need to be marked as transitive.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Modify-Compone
Yes, I suspect Bob has explained it.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Modify-Components-w-Conditionals-tp7594143p7594155.html
Sent from the wix-users mailing list archive at Nabble.com.
--
We use VS2013 and heat to harvest files and registry information. I have not
used it to harvest a VS project file, as discussed in the bug. The bug also
does not indicate that the reported issue is related to missing MSBuild v120
PlatformTools. that seems to be a different issue, but I could be
I would give the two bundles a different Bundle/@UpgradeCode (using and $(var.UpgradeCode) ), and then add a Util:ProductSearch for the
other UpgradeCode. (Or rather than the Util:ProductSearch implement the
detect the other bundle in the BA with BAFunctions.dll, or in an mba.) If
you want to ke
If your msi package will always be launched by a burn bundle, then you could
initialize and set Persisted=yes" on the burn string variable, which is then
passed as a MsiProperty to the package. But if the msi package will be
launched by on-demand msiexec install due to advertising or a repair issu
>>Does that persist across an upgrade? (Last time I checked, admittedly in
v3.6, it didn't.)
I had thought the upgrade scenario was working using wix 3.8, but I switched
all of my projects to use the remember property pattern' some time ago. I
don't recall if there were upgrade issues using the
The MSI documentation for 'formatted' strings is here:
http://msdn.microsoft.com/en-us/library/aa368609(v=vs.85).aspx
If a substring of the form [#filekey] is found, it is replaced by the full
path of the file, with the value filekey used as a key into the File table.
The value of [#filekey] remai
Use something along these lines:
http://10.64.2.42/t/Products/{2}";
SourceFile='path_to_I1\I1.msi'
InstallCondition='evaluatetes_to_1 = 1'
>
SourcePath is the location of your package at build time.
DownloadURL is the location where you
iResult = MsiProcessMessage(hInstall, INSTALLMESSAGE_PROGRESS,
hProgressRec);
if ((iResult == IDCANCEL))
return ERROR_INSTALL_USEREXIT;
http://msdn.microsoft.com/en-us/library/aa367525(v=vs.85).aspx
--
View this message in context:
http://windows-instal
Wix 4.0 is early development with breaking changes. So unless you plan to do
development work on the wix 4.0 tools, you probably want to stay in the wix
3.x family. Wix 3.8 is stable. Wix 3.9 has latest updates.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559
Here are a couple of different approaches to this issue:
http://stackoverflow.com/questions/7970594/msi-reading-properties-from-custom-action-in-merge-module-msm
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/avoiding-GUID-decoration-in-merge-module-property-name-td5742531.html
I am in the process of doing a similar conversion, and am very happy with the
wix model of moving the UI to the bootstrapper application and having
smaller MSI packages for each application (or feature), chained. So I can
add my 2 cents, and others can provide more details.
When you use the Cha
If the bundle determines that a package should be installed, then it
downloads the package to a local folder and installs it. You can specify
whether you want the package cached locally, but the recommended practice
(as I have read elsewhere) is to leave the cache attribute unspecified and
let bur
If you have the old MSI, there are a couple of options (but I am no expert).
If the old mis supports doing a /a layout then you can extract the files of
the old msi to two folder tress, original and changed, change the files in
the 'changed' folder tree, and use torch to create a transform.
Or yo
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Output-Question-tp7594349p7594350.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Start Your Socia
While I have not used that process, my understanding is that you are creating
a 'small update' patch for the original version of the two MSI files (used
in that process). (The updated version of the two MSI files is not
distributed. Only the original MSI and the patch which targets only that
orig
I use wix 3.8.1228. Looking in the wix tools source at
src\ext\FirewallExtension\wixlib there are localized strings for en-us and
ja-jp.
For the other languages which I need to support, I copied the en-us strings
into each of my own wxl files for the specific languages that generate those
error m
Hi Steve;
If your comment is related to my post, there may be a misunderstanding. In
the WixFirewallExtension there are strings in a wxl file which are only
translated into japanese. My project needs those strings translated into
German, French, Spanish, etc to avoid the errors which were posted
In my experience, when the shortcut does not target an exe, (in my case a pdf
and in your example both txt and docx files), even though the
Shortcut/@WorkingDirectory value is set in the wxs, the 'Start In' field is
blank in the properties page for the shortcut. It is my understanding that
this is
In a burn bundle there are 'variables' (but it is not the same as a Property
which is an MSI concept). You can define a variable in the bundle, and you
can persist it.
(you can add the Persist="yes" to the above line if you want burn to do the
persisting.)
Note that even though I think of
If it is helpful the way I use it is:
While I did not look at the details of the Firewall CAs, the property
strings which you posted earlier looks correct, for a packed list of a
mixture of numeric, string, and identifier properties. This is typical of a
CustomActionData property.
--
View thi
Greetings;
I have a third-party msi which was branded at build time by the third-party
for my company. Since then we have changed our logo design, but for various
reasons the third-party cannot provide a new build of the package in our
time frame. The changes are limited to for files, two .confi
I modified my code to use two separate entries like you have. I got the same
error, like you did, I assume. The private rule worked but the domain rule
was not created. However notice that in that case the 'Name' attribute was
the same. I modified the Name attribute to use unique names and both
It sounds like you have a per-machine setup and you are trying to access a
per-user area (or if per-user trying to access a different users area). The
TempFolder is per-user.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd765197(v=vs.85).aspx
And in some situations the TempFolder chang
Yes your Ids are different and when my Ids were different but the Name
attribute was the same it did not work for me. But when I also modified
both the Name attributes to be distinct it worked. Change the
Name="[ProductName]" to be distinct in each line and see what it does. It
does not seem li
>>Torch for generating
transform + apply that transform...
This is where I had the problem. I created the two msi packages (a and
a.modified) and I created the transform (brand.mst). The difference between
the two MSI packages was that I used Orca to extract and then import a
changed Icon from
Thank you for pointing that link out. From reading the MSDN link I
understand why what I tried to do did not work. Thanks.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/torch-create-transform-tp7594463p7594633.html
Sent from the wix-users maili
Youmight want to look at src\ext\ca\wixca\dll\CloseApps.cpp in the Wix tools
source for an example of using WcaProcessMessage.
HRESULT hr = S_OK;
UINT er = ERROR_SUCCESS;
PMSIHANDLE hRecMessage = NULL;
DWORD *prgProcessIds = NULL;
DWORD cProcessIds = 0;
hRecMessage = ::Msi
201 - 300 of 790 matches
Mail list logo
