I am trying to learn WiX (and MSI, with a background in non-MSI setup
development). I hope to contribute to the WiX community at some point, but
for now I am experimenting with heat.exe and dark.exe as I learn.
There are various examples of using heat.exe which have command line
switches that
Well Bob is correct those switches are documented. I am not sure now what
document I was looking at yesterday which seemed to be missing this
information. I have 3.7.1224 installed on several systems as I experiment
and learn the details and I thought I had checked the CHM carefully prior to
If you know basic information about the child process (such as a window
title), then after your setup launches the exe package, and the package
returns successfully, launch a tool which calls FindProcess (or equivalent)
and get the PID, and then wait on that PID until the child process
terminates,
I came across this broken link in the help, both on the web and in the
3.7.1224 chm, on the page titled Code Pages the link named 'localization
files'.
I tried to go to the bugs link on SourceForge but did not understand how to
report this bug. Sorry. (I want to get up to speed and help out on
Using Wix 3.7.1224 I created a setup and localized it. I can build it in
each language based on the string(s) that are entered into the Project
properties 'Cultures to Build' text entry. When the 'Release' configuration
is built, light.exe is called multiple times, for each culture, appending
I have been studying the Setup source code for WiX 3.7 and working on the
payload packages for a bundle which will do web downloads. However the
payload will not be hosted on a web site that exists when the package is
created. Rather the bundle package and all related files will be included
in a
That is the challenge I am trying to understand.
The setup which creates the web site could write URL information to a file
that in with the bundle exe, and maybe generate a self-extracting exe. Then
the user might download the two files or something along that line, and the
bundle exe would
Or the BA is downloaded and launched presenting a dialog to a user (or a
command line property) allowing the user to specify a URL to look for the
payloads. Is this possible, I assume with a custom BA?
--
View this message in context:
Thanks very much for the information and the various ideas. Knowing that it
is possible to change the URL at run time is a big help. I will work
resolving the 'known unknowns' issue and may be able to take advantage of
another feature of our product to discover the web site. I am having a lot
I realize that this question is probably more a MSI question rather than WiX.
I have searched but did not find discussions of this specific issue that I
am sure is a common issue. Say I do a release of a product that has a
number of dependencies, some of which have a version number in the name
After posting the above question, I thought maybe I should post the 'answers'
that I have been contemplating based on the research I have done.
Assume will always do Major Upgrade
1) in Release 1.0 create a component for dll_ver1.dll.
2) In Release 1.1
a) delete the component for dll_ver1.dll
I have been following this thread, and while I am pretty new I decided to
play with this problem as a learning experience. I created the following
modules, which are slightly different from your code, which compile and do
not generate any warnings or errors. I think the main change I made was to
This list is for WiX related question and not InstallShield. Why don't you
post your question in the Flexera InstallShield community (and if I see it I
will answer the issue over there).
--
View this message in context:
I'm sorry I was probably out of place. The issue is that the setup is
expecting a particular code page which is not available at the time it was
run. This is what happens when a dialog translated for Japanese (or a Near
Eastern language) is run on a PC that does not have Near Eastern language
Thanks for your comments. Yes I had thought about leaving the old DLL when
patching and deal with it on the next MajorUpgrade. I think in most cases
we should be able to take that approach, if we use a patch.
--
View this message in context:
Today while working on another issue, I added the paths to the WiX source and
pdbs to the Visual Studio options and found that I could launch my setup,
attach to it, and debug into the WiX code. Also for developing CAs there is
a good tool called catest which I have not used with WiX yet. I have
As Rob indicated the dependency loop would not exist by default. It
depends on how the designer implemented the MyClient service. A Windows
Service should have a control handler thread that processes events from the
Service Control Manager and separate worker thread(s) that implement the
I have a bundle based on WixStdBa which installs .Net 4.0 and my MSI. I need
to add a third party MSI which requires .Net 3.51. So at this point I am
only trying to add .Net 3.51 to my chain. Not finding a built-in way to do
this like I did for .Net 4.0 ( 'PackageGroupRef Id='NetFx40Web' /') I
I had wix doing the .Net 4.0 for me. I had seen Neil's blog some time ago
but did not find it when I needed the .Net 3.5 info. Thanks for the info!
--
View this message in context:
I am relatively new to WiX 3.7 and MSI (and having lots of fun with the great
WiX documentation and information available in the forum). As I get my
BA/msi functional I am trying to review best practices and I came across a
post at:
http://stackoverflow.com/questions/471424/wix-tricks-and-tips
I think your right. I had noticed that phrase, but was not certain of my
interpretation of it. I agree that I don't know why I would ever deploy a
subset of changed files in a ComponentGroup. So in that case I guess I am
ready to move on in testing my new setup.
Thanks.
Phil
--
View this
Thank you for the response. It is very helpful.
Phill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-Best-practice-using-fragments-tp7587660p7587722.html
Sent from the wix-users mailing list archive at Nabble.com.
VS2010/Votive displays bal:Overridable as an attribute option for
Bundle/Chain/MsiPackage. While I did not find this attribute documented in
the Schema for MsiPackage (as it is for the Variable element) I wondered if
I could set it and then (just guessing) pass a property on the command line
to
This is VERY COOL.
I am working on my first WiX bundle and was just getting to the point where
I need to get it working in JEFIGS +Ch Simplified. I quickly implemented
the steps you posted with the one exception that I created a Payload entry
for a 1033 sub folder, which it uses by default
The WixBA at src\Setup\WixBA is the C# managed BA that is used by the
installer that installs the toolset. The Bundle does not have a
bal:Condition in it and as far as I can tell there is nothing directly
related to Bal:Condition in WixBA. However I think what folks have
suggested is that one
My experiments so far do not work. I added:
Payload Id=themeXml_de_de Compressed=yes
Name=1031\HyperlinkTheme.xml SourceFile=theme\1031\HyperlinkTheme.xml/
And made various changes to only that xml file, but so far it has not picked
it up. I was just starting to read through the source code,
It looks like the answer to loading a localized xml file is here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Localized-bundle-Picking-up-the-right-files-td7265208.html
I have not tried it yet, but he is correct that I did not have the png file
in each localized folder.
--
I'm sorry, I have looked at the bug tracking page (and other tabs) and I
don't see how to file the bug. I would like to understand how to do it.
--
View this message in context:
Well I got it working. As posted earlier I added a modified
HyperlinkTheme.xml to my 1031 subfolder, and originally I added this Payload
statement:
Payload Id=themeXml_de_de Compressed=yes Name=1031\thm.xml
SourceFile=theme\1031\HyperlinkTheme.xml/
The bundle project builds but when run it
Bug created. Thanks for the help. Someday I hope to help fix the bus.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Chain-MsiPackge-bal-Overridable-yes-yeilds-strange-error-tp7587767p7587800.html
Sent from the wix-users mailing list archive at
This is related to:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-td7208949.html
but I thought it best to start a new thread.
Using VS2010 3.7.1224 WixStandardBootstrapperApplication.HyperlinkLicense
project, I added the following
I saw a prior post and created a Sorceforge account and then created the bug.
But it is different from the one I was logged into the forum with. In the
future I can use the forum login. Sorry for the confusion.
--
View this message in context:
The implication that I take from your questions is that you are trying to
write something to the Program Files area from the bootstrapper. Generally
I think folks would encourage you to rethink the security implications of
doing this and use the msi server to make any changes to the PC. However
Sorry for the misinformation. Thanks for the clarification.
Phill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-BURN-wpf-and-UAC-promt-tp7587811p7587834.html
Sent from the wix-users mailing list archive at Nabble.com.
I have a bundle which has three EXE and 1 MSI, all third-party, and then my
MSI for a total of five packages. This is my first bundle and it has been
installing on a Win 8 x64 test system successfully. I install and uninstall
on this test box, rather than going back to a clean OS as I have
I'm sorry, I do not quite understand what you mean by 'provided targets'. I
used the following command in the Post Build event for the bundle project:
(The certificate was previously imported into a local catalog. This is the
same command that I also use in the Post Build event for my MSI
I just read the doc for Insignia more carefully and I think I see what I am
doing wrong. I had originally not used insignia because it seemed to be
needed for signing 'external CABs' and I am not using an external CAB. But
I now see how it is use to extract the engine.exe from a bundle. I will
Mission accomplished! thanks for the assistance.
Phill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Unspecified-Error-after-signing-bundle-tp7587845p7587864.html
Sent from the wix-users mailing list archive at Nabble.com.
I have a bundle with an MsiPackage. The MsiPackage has certain LCID.mst
transform files. I pass the TRANSFORMS property using a MsiProperty. But
in the case where the user is using English (or one of the 'unsupported' by
this package, LCIDs) how do I not pass th TRANSFORMS proiperty?
I have
I just started working with the
WixExtendedBootstrapperApplication.HyperlinkLicense yesterday, and there is
some functionality that I do not understand yet. But it seems like you
could use the BAFunction.dll template.
In the bundle you would do something like:
Variable Name='EULA1'
If I do this:
MsiProperty Name='TRANSFORMS' Value=''/
I get a build error that says that the Value attribute cannot be empty. .
MsiProperty Name='TRANSFORMS' Value=''/
The bundle compiles but the package rolls back.
The MSI packages command shows TRANSFORMS=
What I really want to do is
Well I think I found a solution (although I did not fully implement the
BAFunction yet).
If I declare the variable with an empty value, that is acceptable, and then
when I use that variable in the MsiProperty, the MSI command line gets
TRANSFORMS=, and the install succeeds. So now all I need to
I am trying to solve that same issue, so I do not have a solution yet. I was
in the process of importing the 'extended bootstrapper' and writing a
BAFunction.dll to try and get the language of the UI to be the same as the
OS UserLanguageID and also address an issue where I need to restrict which
Yes, we support seven languages. If I pass UserLanguageID or
SystemLanguageID in my var LCID and then pass it as a property to the MSI
package in the form of TRANSFORMS=LCID.mst all is well for the supported
languages, however an unsupported language results in an error because the
transform does
Thanks for the idea. I will try that.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-tp7208949p7587954.html
Sent from the wix-users mailing list archive at Nabble.com.
I assume that your (Neil's) description of the WiX language detection
behavior applies to 3.8, because I have not observed that behavior with WiX
3.7. For me with 3.7 I always have to use -lang LCID to see any of my
supported bundle translated strings. So far I have only tested using
Windows 8
When I started with WiX I downloaded the WiX source code and used the
src\Setup tree of files as an example. I found CommonLib and CoreMsi to be
helpful in building my MSI. I used Bundle as a model and initially got a
MBA similar to WixBA working. The web download stuff is not operational
yet.
Tim, I'm still working on it, but with other responsibilities here at work
have not made much progress yet. I do not have my project building under
3.8 yet. Last week I went down the route to change from using
WixBootstrapperApplication.HyperlinkLicense to
I have my bundle building under WiX 3.8 and yes on Windows 8 Professional
with German selected as the default language, the bundle showed my localized
German strings without the need for the -lang switch.
I have yet to implement Neil's suggestion to create a localized variable in
my wxl files
I don't mean to side-track Tim's question but to clarify I was (and I think
Tim is) running under Wix 3.7 and for me under Wix 3.7 on Windows 8 I never
saw it select one of my wxl languages without me using the -lang switch.
Neil said earlier that there was a bug in Wix 3.7 so I updated to Wix
Too clarify my comment about not being able to see what the result is for:
langid = GetUserDefaultLangID() (in locutil.cpp)
The issue is that LANGID langid is a type that WinDbg cannot interpret,
however when I step into the call with the disassembler I can see that
Windows 8 is returning
OK I unravelled the Windows 8 configuration issue. This test system I
thought was configured for German and English and I thought that I was
setting both the System Default and the User Default to 1031 for these
tests. I would change the order of the list under Language Preferences
(based on
I was using WixExtendedBootstrapperApplication.HyperlinkLicesne and I
upgraded to Wix 3.8.722 and am using
WixStandardBootstrapperApplication.HyperlinkLargeLicense. I had perviously
(in 3.7) captured the thm.xml file from the \ba1 folder and added it to my
project, and then edited it. Prior to
I am doing this in my WixStaBA. The error implies that your project file
structure is not:
Project Dir\Resource\RtfTheme.xml and RtfTheme.wxl
One thing that caused a problem for me initially was that I used a folder
name Resources but used Resource in the Wxs file. A simple typo as some
Regarding this comment:
I was looking at wixstdba.vcxproj in WiX source and these files are
included as None and with flag CopyToOutputSubDirectory, but we don't
have this option in C# (or we do?).
My bundle project is a WiX bootstapper project,, not C#. Originally I did
not add any of these
Also I am using Wix 3.8.722, which I assume from your question you are also
using 3.8. The concept in 3.7 is the same, but it has an issue detecting
the correct language, and the syntax of these statements is a little
different.
--
View this message in context:
A windows service always has an associated registry key under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services
Then use the method detailed here:
http://wix.sourceforge.net/manual-wix3/read_a_registry_entry.htm
--
View this message in context:
As I step through the Wix 3.8.722 code I observe in:
src\ext\BalExtension\Wixstdba\WixStandardBootstrapperApplication.cpp
at line 916
LoadBootstrapperBAFunctions();
if (m_fPrereq)
{
hr = ParsePrerequisiteInformationFromXml(pixdManifest);
I do not feel qualified to answer your question, which is why I did not
comment earlier. I am not using heat (or rather I used it to make my first
wxs and then decided to do a lot of editing) and I got the file association
stuff working a few weeks ago, for the first time. I started from a
Question ?
Extension Id=galileoGlobalProject
Is galileoGlobalProject your file extension like .doc or .png (without
the period)?
--
View this message in context:
Yes, you are correct. It is documented in the 3.8 help. I missed the idea
that I needed to add
bal:WixStandardBootstrapperApplication
LicenseUrl=http://example.com/license.html;
LogoFile=path\to\customlogo.png
ShowVersion=Yes
/
As a child of
Just to clarify, I'm not setting the m_fPrereq variable. I was just stepping
through the code to learn how it works, and I can see that m_fPrereq is set
to zero in the constructor of the class, but under WinDbg I can see that it
unexpectedly changes in the call to LoadBootstrapperBAFunctions();
A simple repo was create which has the same behavior. Bug 3357 was created.
I also had another thread at wixextba.codeplex.com which ended up discussing
this issue. I'm sorry for the double post and appreciate all comments.
--
View this message in context:
I am realativly new also, but I posted my file association code in answer to
another question, here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Use-a-TargetProperty-in-a-Verb-in-a-ProgId-for-file-association-td7588039.html
--
View this message in context:
Look at the log file that typically gets created in %temp%. For the
situation were it does not display any dialog my guess is that the that the
dialog could not be created due to some problem with the theme file. This
is not a 3.7 or 3.8 problem. I had this problem when I incorrectly edited
the
While I am not clear on what you want to do, this thread may help:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-Burn-driven-installer-in-quiet-mode-command-line-parameters-td5913001.html
If you are writing the BA you can get the command line and then set a
variable, which
Thanks for looking at this. I am still researching how to use git to get the
source code to make a debug build. I can also setup a XP test box next
week. I was working on localization issues using ProcessMon. I observed
some behavior where it would load my renamed logo.png file then it would
Here is my code:
lt;BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.HyperlinkLargeLicense
lt;bal:WixStandardBootstrapperApplication
LicenseUrl=http://www.company.com/license.html;
LocalizationFile=Resources\QDthm.wxl
ThemeFile=Resources\QDthm.xml
Tim, I'm sorry. You are correct that I did not read down far enough.
I looked it over more carefully and I do not see a problem with your code.
I guess I would study a ProcessMon log or setup WinDbg.
--
View this message in context:
Or one could disable optimization in the Release build. We do this
frequently so that we can debug released code at a user's site using WinDbg
(with Release build dependencies). I am familiar with the effects of
optimization on debugging code. I also had my in-house WinDbg expert double
check
Tim; I took your wxs file and added it to a new WiX bootstrapper setup
project (in VS2010). I tried to recreated your file tree as closely as
possible and I stripped out the code that was not related to testing whether
the localized files were displayed, without needing to provide the -lang
In my experiments, I observed the Failed to load loc file from path: ...
\.ba1\1031\thm.wxl when I edited my German thm.wxl incorrectly or if I copy
a English .wxl file (like RtfTheme.wxl) to my 1031 folder, but do not edit
the culture, language, and code page attributes properly for the
Yes I had a similar problem setting a breakpoint, but I did not realize it
was due to the pdb. When WinDbg launches the exe it breaks and gives me a
chance to set a breakpoint. I would not show the breakpoint that I tried to
set with F9 after placing the cursor at LoadBootstrapperBAFunctions()
I know that there are a number of different approaches that one might take to
address this question. One approach might be to use something similar to
Example #11, at:
http://wixextba.codeplex.com/releases/view/105895
Which involves a bundle that displays radio buttons and then use that
It seems like you would want to use DetectCondition to determine if the
package already exists and InstallCondition to determine when you want to
launch the exe.
--
View this message in context:
Well I was told that there is a bug that affects this issue in WiX 3.7 (which
you can resolve by adding the WixExtendedBootstrapperApplication from
http://wixextba.codeplex.com/releases/view/105895) or by switching to WiX
3.8. My development box is configured so that by changing an environment
No, but I had a similar issue and determined that Symantec is assuming that
if the package does not have a valid Code Signing signature it is a virus.
There is no virus, it is a FALSE Positive which many others have also had
issues with. If you use your code signing certificate to sign the
After doing this experiment with your code and demonstrating that
automatically detecting languages works using WiX 3.7, even without
specifically using the WiXExtenededBootstraperApplication, I switched my
main project (seven languages) back to Wix 3.7. I did limited testing on my
Windows 8 test
Well, I am sorry to hear that it is not working for you. Since I can build
it with 3.7 and it works, I think I would try to use ProcessMon or WinDbg to
figure out what the issue is, focusing only on the German Wix 3.7 exe which
I complied for you and your compilation of the same thing.
When I added the WixExtendedBootstraperApplication to my Wix 3.7.1224
installation, I downloaded the zip package from:
http://wixextba.codeplex.com/releases/view/105895
And I put the one DLL in that package into my Wix Toolset 3.7.1224\bin
folder.
At a later point I did what I described in
I thought I had the 3.7.1224 with the
WiXExtendedBootstraperApplication.RtfLicense stuff working in the test
package that I uploaded to another thread. Folks in that thread said that
it did not work for them, so I went back to the same project again and when
I compile it under Wix 3.7.1224 with
What I have done in this situation, is to comment out the theme file that is
causing the problem and get your setup to the point where it will display
dialogs using the internal default files. Then as the setup is running
displaying the first dialog, open Windows Explorer, go to %temp% and look
It prompted me for a login (or create an account) and I created a login and
logged in successfully. I then tried to create a bug and it prompted for a
login and would not accept the credentials created a few seconds earlier.
(So I will just keep track of the issue until I learn how to file a
I did not find an email, even in junk, but our IT group may have nixed it.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-Bug-and-Feature-Request-location-http-wixtoolset-org-issues-tp7588281p7588355.html
Sent from the wix-users mailing list
Is there a MSBuild Task or a method of conditioning one of the Targets that
fires prior to Compile, so that my in-line task will not fire if linking is
going to be skipped?
I notice that when I add a task to Target MsiSign that it does not file if
linking is skipped (which is the behavior that I
I cannot comment on Wix tools, but in general we have received many
complaints from folks who install a third-party .Net 2.0 application, which
we distribute, on networks which are locked down with no external access to
an Authenticode certificate server. Form what I have read such a network
Using Wix 3.8.722 (and 3.8.823 debug build )
I read through the src code and observed where bind, candle, torch and other
tools use the WIX_TEMP variable. I defined an environment variable. When I
build my projects this folder is never used and it continues to users %temp%
folder.
Is there
Take a look at the following two links. While there is a 32 bit version of
Windows Server 2008, in most cases foks really mean Windows Server 2008 R2,
which, like Windows Server 2012 is only available in 64 bit configurations.
VersionNT is undefined on 64 bit configurations and VersionNT64
FYI - From this MSDN page:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372495(v=vs.85).aspx
The installer sets the VersionNT property to the version number for the
operating system, *undefined if the operating system is not *Windows NT,
Windows 2000, Windows XP, Windows Vista,
Sorry for the delay in responding to the last post. I updated my user info
using the link provided in the email, however it always failed until I used
exactly the same optional 'user name' provided originally. Then it liked
the new password, and I can now log into the new bug tracker. Thanks
I am relatively new to Wix and have not used the Service Control
functionality yet, but I have over the years created services and installed
them with setups created by another non-wix setup. So from that
perspective, given your statement but does not remove the service from the
Services list, I
The original post indicated I have created MSI/EXE using Wix .
If the '/EXE' implies a Bundle was created, and 'Condition' is used in the
Bundle then also take note that Burn built-in VersionNT and VersionNT64
variables have a different format than the related MSI variables.
This is just a wild idea, but could you create a bundle (with a product
search), which you use to stage your test project (uninstall the old and
install the new)?
--
View this message in context:
If using the WixStdBA in 3.8 (or with Wix 3.7 AND the WixExtendedBA from
http://wixextba.codeplex.com/) you may find it helpful to use the
BAFunctions.DLL. As others have indicated you could ask the questions in
the WixStdBA, process the selected radio button on OnPlanComplete, and
install your
I am using WixStdBA in Wix 3.8 with a BAFunction.DLL (which is similar to
using the Extended BA in Wix 3.7).
In the BAFunction DLL (under a debugger) I can use this- to access member
variables including this-pEngine. But I am trying to drill down and check
what was passed in on the command line.
I will plan to add the Feature request. The wix.codeplex.com 'bug' link is
not responding so I will check back again later to do that. In the mean
time I plan to have the 'parent' process set a registry key and then read
that in the BAFunction.DLL. I really appreciate the BAFunction.DLL as I
The core issue is that the Wix 3.7 tries to download that package from the
web site and the web site is down at this time.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installation-Failure-tp7588876p757.html
Sent from the wix-users mailing
The issue is really a separate issue from Installing the Service. Before an
account is specified for a Windows Service to use, the Local Security
Policy\Local Policies\User Rights Assignment, for that account, needs to
allow the 'Logon as Service' permission (or if the service is designed to do
a
Yes the wixtoolset.org web site is still down which means that the wix38.exe
setup which I have does not run and install on my new build server. However
another approach is to go to wix.codeplex.com, select the Source Code tab,
select Wix38 in the browse changes, and then click on Download. This
The approach I take to do this is:
1) in the Bootstrapper, as a child of your Bundle element, declare a
variable that has bal:Overridable='yes'.
2) then under the MsiPackage use the MsiProperty to set the Property to the
value of the variable.
3) Launch the bundle with MyFile.exe MODEL=Xxxx (and
1 - 100 of 776 matches
Mail list logo
