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
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
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:
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:
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:
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 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.
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'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 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
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.
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
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:
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
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.
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
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:
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
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
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:
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
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
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 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:
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 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
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,
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
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
701 - 776 of 776 matches
Mail list logo
