Our installs support multiple languages and we would like to add a few
languages that are not currently supported: English (United Kingdom, en-gb)
and Spanish (Mexican, es-mx)
We created the two new .wxl files using the WixLocalization Culture=en-gb
and Culture=es-mx
Then using Studio 2010 to
Thanks for the response Bob...
Now using the Cultures to build would mean that I have to place all the
languages that we currently support in our installer, which is 24, and so
that they are all built. We build all the languages and convert to language
.mst at the end of the build.
Since we
I added all the cultures to the Cultures to build as well as the 2 cultures
that needed to have the fallback cultures and now when I build I get a few
errors about duplicated localization identifiers.
Each language as it's own .wsx file and all contain the same identifiers
with the correct
As we created more WiX installer and therefore more fragment .wxs files that
can be shared by other WiX installers we are now getting into cases where we
are storing shared fragment files in environment path locations.
Now we would like to link in these shared fragment files, but do not know
how
Still new to WiX as we have most of our installs in InstallShield and in some
cases we have InstallShield genearated Chained installers so that we can
deploy a suite installer.
My question is about the generation of the WiX chain output package. Can the
WiX Chainer produce a single .msi package
Thanks Steven,
But that is not exactly what I was getting at. We have a WiX include file
that is included.
What I was referring to was to include a *.wxs file, that resides in a
shared location (environment variable), that I need complied into the main
WiX project.
When we add a new .wxs file
I have tried %MyEnv% and that did not work, but supply ..\..\..\ will work.
Now when I do that it does create a folder structure in the solution tree
that shows all the ..\..\..until it hits the file. Not that great looking...
Thanks,
Tim.
--
View this message in context:
No we are not talking about nested installs.
I am actually talking about a Chain installer that chains in a bunch of .msi
project into a single msi package.
InstallShield has this it correctly creates a single .msi package for
administrators to push out.
We started looking at WiX and therefore
Thanks Daniel, that did the trick. It created the link with the relative path
and then I simply replaced the relative path with the environment variable
in the .wixproj file and it did the trick.
robmen, we have not yet looked into creating any .wixlibs as of yet, but
that is something that we
Since we still have a lot of our customers that still use GPO for pushing out
our software we still have to have a .msi solution. So again it looks like
we have to stay with InstallShield for all our chained projects.
Tim.
--
View this message in context:
embedded UI from WiX toolset.
On Wed, Feb 27, 2013 at 6:22 AM, TimM [hidden
email]/user/SendEmail.jtp?type=nodenode=7584353i=1 wrote:
Since we still have a lot of our customers that still use GPO for pushing
out
our software we still have to have a .msi solution. So again it looks like
we
=7584397i=1 wrote:
Jeepers, you should just include the language packs in the products
and put a language selection in the product.
59 language packs is a headache to manage separately.
-Original Message-
From: TimM [mailto:[hidden
email]/user/SendEmail.jtp?type=nodenode=7584397i=2]
Sent
Hello,
We are converting over one of our InstallShield install project to WiX and
would like to know if WiX has a install support folder?
Our InstallShield project has a custom action that calls an app that
requires 5 files to be in the same folder so that the custom action works.
These files
Message-
From: TimM [mailto:[hidden
email]/user/SendEmail.jtp?type=nodenode=7585348i=0]
Sent: Monday, April 22, 2013 1:58 PM
To: [hidden email]/user/SendEmail.jtp?type=nodenode=7585348i=1
Subject: [WiX-users] Custom Action triggered from Support Directory
Hello,
We are converting over one
is
set to the folder for the payload when the Package is being executed.
-Original Message-
From: TimM [mailto:[hidden
email]/user/SendEmail.jtp?type=nodenode=7585350i=2]
Sent: Monday, April 22, 2013 1:58 PM
To: [hidden email]/user/SendEmail.jtp?type=nodenode=7585350i=3
Subject: [WiX
We have a WiX (.msi) installer that has to run as administrator, but at the
end a service app is needed to be launch, but has to launch in non-elevated
mode. If it is launched in elevated mode then users have to restart the
machine to have it launched in non-elevated mode.
Now we have a dll that
Natalie, I have basically the same task where we have about 5 files within
the binary table that need to be extracted so that we can trigger a custom
actions that depends on all 5 files existing in the same folder.
So I would like to know if you have this working correctly and if so would
you be
I have the following in my main WiX wxs project file:
MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName] is
already installed. /
I then installed a newer version of my software and then installed an older
version and instead of getting the error message that a newer version is
Did you ever get this resolved?
I am just now creating my first Bootstrapper with Burn and at the moment I
can only get it to display a License Dialog box. What do I have to do to get
a License and Directory dialog box and then to pass the entered/selected
directory to the .msi file that is
Thanks Jacob,
So added all the supported language .mst's using the Payload element under
the MsiPackage, but without being able to condition if one of the supported
.mst's are to be used or to have to use the default languages of English
then again it makes it harder to use.
So it looks like
Okay adding all supported language .mst's by Payload element and then having:
MsiProperty Name=TRANSFORMS Value=[SystemLanguageID].mst /
Does work. The install did install the shortcuts under the correct language,
but if you are running on a unsupported language, a language that we do not
have a
Okay thanks, that is something I'll have to look at...
Now as for my error when running on a OS that is running a different
language than what I support. Is there any examples that you can direct me
to that would help me to create a custom action to condition the TRANSFORMS
property so that if
Okay I have not yet figured this out. I have tried placing the calling of my
MsiPackage into a separate Fragment file and add a property definition to
default language and then conditioned custom actions for the supportted
languages, but it looks like Burn completely ignores this default property
Okay thanks Jacob...
So figuring I would go with the easiest method I started to convert my main
project with conditioned language components and then when I build I then
receivce a bunch of errors stating:
error LGHT0311: A string was provided with characters that are not available
in the
Gabriel,
I am trying to condition my MsiPackage on Language and you have mentioned
here the installCondition:
InstallCondition=LANG = quot;fr-FRquot; AND NOT VersionNT64
So my question where did LANG get defined. I see the Variable set section:
Variable Name=LANG bal:Overridable=yes/
But I do
Okay thanks Jacob...
After a bit more testing I was able to get this to work by using the
InstallCondition. When I first tried using the InstallCondition I was
looking for languages like this:
InstallCondition=[SystemLanguageID]=1036 and this was failing.
After some research I found out that I
There should not be a problem with Product Codes as I am using the same .msi
in both MsiPackage entries, not multiple msi's that are language specific.
I have again just the one .msi and the language .mst's files. So if one of
the supported languages exists it will trigger the first MsiPackage ID
I am running in to something the same and the logic is screwing me up.
I have the following:
?ifdef $(env.PRODUCT_CODE) ?
?define GenProductCode = $(env.PRODUCT_CODE) ?
?else?
?define GenProductCode = * ?
?endif?
If the environment variable PRODUCT_CODE exists then
Oh, sorry I had the wrong syntax... It should have been:
?ifdef env.PRODUCT_CODE ?
?define GenProductCode = $(env.PRODUCT_CODE) ?
?else?
?define GenProductCode = * ?
?endif?
After the correction it worked as expected...
--
View this message in context:
I would like to know if there are tricks/settings that we can apply to speed
up our WiX install project builds?
We build mult-language installers and then geneate the language transforms
.mst's for each language so that we can ship the main English .msi with all
the language .mst files.
Is there
Bill, did you ever get this working?
I have seen some other posts on this and some of the answers seem to suggest
that the issue is that the bundle is not signed correctly.
All our Chained MSI packages are signed as well as the bundle and we are
still getting these errors.
In my original
I am trying to get Burn (bootstrapper) to show in different languages and
need a bit of help with this.
I saw an article that mentions that WiX Burn fully supports translations,
but then I read further that it only shows in English???
So what I would like to know is if there is built in language
Okay tried a few thing suggested in to following web page, but still no go...
Still same 0x80004005 error on extraction of files.
Is there a command line that we can call to manually extract all files
within the Burn bootstrapper .exe so that we can verify that the files are
actually in the .exe
the failure. Then put the
.pml file and the corresponding burn.log somewhere and I'd like to take a
look.
On Mon, Jul 22, 2013 at 2:55 PM, TimM [hidden
email]/user/SendEmail.jtp?type=nodenode=7587507i=0 wrote:
Okay tried a few thing suggested in to following web page, but still no
go
Hello Rob,
I forwarded an email to you with .zip file that contains the Process Monitor
and burn logs. Let me know if you did not get it and if not then let me know
where I can post this file for you to review.
We really need to get this bundle signing done as at the moment testing can
not test
Okay I have placed the .zip file in my dropbox:
https://www.dropbox.com/home/Shared?select=ErrorLogfile.zip#!/home/Shared?select=ErrorLogfile.zip
So if this will help determine what is wrong with signing of our bundle then
that would be great.
If there are any other methods to signing a Burn
Sorry about that
Try this link: https://www.dropbox.com/s/5ersyy950w54fdy/ErrorLogfile.zip
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-tp7587152p7587541.html
Sent
. Would be a great idea to open a bug with as
many details about the issue as possible.
On Wed, Jul 24, 2013 at 5:06 AM, TimM [hidden
email]/user/SendEmail.jtp?type=nodenode=7587561i=0 wrote:
Sorry about that
Try this link: https://www.dropbox.com/s/5ersyy950w54fdy/ErrorLogfile.zip
Okay we think we have this fixed now.
Our MSBuild target file had the following:
Target Name=SignBundle
MSBuild.ExtensionPack.Framework.MSBuildHelper
TaskAction=StringToItemCol ItemString=$(TargetPath) Separator=;
Output TaskParameter=OutputItems ItemName=TargetPathItem/
Alnoor,
We are currently using WiX 3.7 and still having issues with localization on
Burn WixStandardBootstrapperApplication.RtfLicense dialogs. Have you got
this working and do they have localized resources for the standard dialog
boxes already?
If you have this going could you let me know what
Phill/Alnoor
I had to make a few more adjustments to my code to match what you have, but
it will still only launch in English when running on a French OS. If I use
the command line option -lang 1036 then the Burn wrapper will correctly show
UI and License in French.
So how do I get it to show
Okay thanks, If 3.8 does correctly detect OS language and launch Burn wrapper
in detected language then that should solve part of that issue.
As for your 2nd issue, are you talking about conditioning your MsiPackage so
that it will only use your supportted language .mst's that you need to pass
to
Brian,
I currently already have English MSI and supported language .mst's in my
Burn Wrapper .exe. I generated the language .mst in my VS 2010 project by
running the PostBuildEvent Torch.exe -t language command on each of the
language .msi file compared against the English .msi.
So the Burn
So Phill, did you have a chance to try any of these suggestions and/or WiX
3.8 to see if you can get the Burn wrapper .exe to launch correctly in the
language of the OS?
--
View this message in context:
Rob, excuse a non-experienced programmer here.
I was looking at the code for the LocProbeForFile function was wondering
about it. In the first if statement you are checking to see if a language
was specified. Is this coming from a language selection dialog box and/or
from the -lang LangID cmd
Neil, thanks for pointing out what the code does.
I am running WiX 3.7 on Win 7 64 bit the problem is that when I have the
System OS set to French, the current language that I have been testing, and
run the burn wrapper .exe the burn UI will only appear in English.
When I add the -lang 1036 to
Thanks Neil,
Before I look at moving over to 3.8 could you let me know what I would have
to do to use the extended BA to test how that works with 3.7. Basically what
changes do I have to make and if there are any files I have to be editing to
actually make it work?
I have not done alot of Win 8
Quick questions about components within a referenced wixlib.
If you add a new component to a WiX install project .wxs file, but then
forget to add a reference to that component as part of a ComponentGroup
and/or Feature then you get an error LGH0267: Found orphaned Component
'component Id'.
Okay that makes sence
So do you then just document what components and/or CompoentGroups are in
your wixlib so that if someone needs to add this wixlib to their project(s)
that they know what is in it and what they would have to reference to have
it installed with their project(s)?
I basically
Yes Rob that is true with added fragments, but with the fragments as long as
they are part of your project you can see the components listed and
therefore reference the ones you want, where as a wixlib you can see the
reference in your project, but you can not see the components within it and
Attached is my main WiX Burn .wxs file:
TableToolkitBootStrapper.wxs
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7588120/TableToolkitBootStrapper.wxs
Now again this will correctly add the .mst files and push the correct .mst
file on the command line to the .msi as long
Thanks Niel..
Just for my reference could you let me know which Extended BA site that
contain these examples? I have seen a few and I think I know the one you are
talking about but just wanted to confirm? Also is there an example on the
site for specifically testing the Burn UI under system OS
Thanks Neil...
Phill you mentioned the following:
Phill Hogland wrote
I looked at your code. You do not have any translated Payload .wxl files
with name attributes in the form LCID\thm.wxl , etc.
And I do have translated Payload .wxl files, they are listed in the
PayloadGroup
Ok Phill, I was able to download and extract the files from your zip. I tried
out both .exe that you created and created a German VM to test on. They did
show the German EULA and when I switched to my French image it showed the
English EULA.
I then updated your German .wxl file with German text
Placing the WiXBalExtentionExt.dll file into my WiX 3.7 bin folder did not
make a difference. So was there anything else you had to do or did to make
this work?
Can both 3.7 and 3.8 reside on the machine at the same time? If as you said
that 3.8 already has the fix in it then I was thinking of
Okay after getting your install to build I test and it will still not show
German or French licenses on German and French systems. This is still
building with WiX 3.7 and having the updated WiXBalExtentionExt.dll file
into my WiX 3.7 bin folder.
So just having no luck what so ever.
I'll look at
Okay, when I installed the latest WiX 3.8 and Updated my project files to use
3.8 the build correctly built in the UI so that on German the UI/EULA is
German, on French it is French and on English and unsupported languages it
shows English.
So yes 3.8 has the fixes in it. So my version of 3.7 has
I would like to know when WiX 3.8 will become a published released build?
We normally upgrade when a release is published and therefore was wondering
if there is a schedule when 3.8 will be released?
We are trying to create a Burn .exe with translated UI and 3.7 currently has
a bug in it that
Hello Enrique Domínguez,
We are basically in the same boat.. We have quite a few WiX projects that
contain between 12 and 18 language cultures and at the moment our project
files are set up to build all cultures and then using the Torch commands to
generate all the language .mst. This process
I am working on an issue that we are seeing when our WiX project creates
shortcuts to target files that require assemblies to be already installed
onto the machine.
Okay here is the issue. We run our install, all shortcuts are created and
the install completes without issues. The app and all
We have an app that when runs produces a quick Dos Window and then goes away.
So we are using the WiXCA - CAQuietExec custom action to call the app in
quite mode. This work great, but my question is if the App fails and I have
the WiXCA custom action set to Return the error code will it return
Thanks, at first it did not seem to work as the calling app did have failures
and they did not cause the install to fail, but then we had another error that
did fail the install.
So we figured that some returns were not a complete failure and therefore the
return did not cause an install
We have 2 components that are conditioned to be installed. On simply installs
the file, but the other installs the file and creates some file association
entries that are shared by other apps. By default the component that only
installs the file turned on and therefore the other component is
I am looking in to creating patches with WiX and therefore I am starting with
the basics of both:
Using Patch Creation Properties and
Using Purely WiX
I am currently using the 3.7 released version of WiX and following the exact
example for the 'Using Purely WiX' from the following documentation
Joe, we are just looking at patches and I have a question about this method
if you don't mind?
I am just testing out with using the sample 'Using Pure WiX' example and I
am looking at the PatchFamily element and noticed that you have to add a
reference to a component in your main install project.
Ok, figured out what was wrong, operator error . I had my Upgrade and Target
sourcefiles reversed. After I fixed that it worked as expected
--
View this message in context:
I am currently testing the creation of WiX patches using Patch Creation
Properties. Now I am trying this over Pure WiX patches because the versions
that we will initially be patching have already been released and when they
were built they were NOT built to generate the .wixpdb files. So we have
We have an install project that installs most of our public assemblies that
are used by most of our various apps. The assembly components are all mark
as permanent as we do not want them removed during uninstall.
The issue that we seem to be are running into with one our assemblies is
that when
Nope this is not the issue, because as I mentioned, the sxs folder and files
for both versions do exists after the install and if it was like this
article then the older version would be gone.
So the files exist, but the app can not find the assembly, so this implies
that the system no longer
Okay thanks for all your help/suggestions, but have found what the actual
issue was. The MsiProvideAssembly returning: 1607 on 2 assemblies was
actually the hint.
After testing a few times I got it to the point where 2 assemblies were gone
after the upgrade and they were the ones listed in the
On 28-Oct-13 22:05, Tunney, Stephen wrote:
Ok, good to know. I have thousands of components though spread across a
dozen features. Those features are shared amongst 8 products :)
Stephen, how did you make out with your patch creation using this Pure-Wix
method?
We are just looking into the
Okay I have done a bit more testing with Pure Wix and Melt and here is what I
have found with my testing.
Create Product.wxs with a bunch of components in root and I also create a
fragment with is bunch more components.
I then built this msi and associated .wixpdb file.
I then updated some of
Hey Stephen,
Here is the contents for my sample build.bat file:
@echo call melt.exe to fix the Version 1.0 wixpdb file so that we do not
have to worry about original source files/folders.
Melt.exe Ver1.0\product.msi -out Ver1.0Corrected\product.wixpdb -pdb
Ver1.0\product.wixpdb -x
Okay Rob, taking out the PatchFamily does allow the patch to all updated
files to be correctly patched and therefore does reduce the complexity of
this method...
Now if we look at Stephen's issue I can see this being a major concern as we
also do the same thing where files are updated with
Well I just did a test of Patch Creation using two different builds of our
next release of our software, which the .msi files are 118 MB in size, and
if I set the WholeFilesOnly=yes the patch .msp size is 20MB. Now if I set
the WholeFilesOnly=no then the size of the .msp is only 3.8 MB. Way
[via Windows Installer XML (WiX) toolset]
[mailto:ml-node+s687559n7590487...@n2.nabble.com]
Sent: Friday, November 08, 2013 2:31 PM
To: Tim Mayert
Subject: Re: Purely WiX patching and FeatureRef
Is this: pyro -delta ?
-Original Message-
From: TimM [mailto:[hidden
email]/user/SendEmail.jtp
: TimM [mailto:[hidden
email]/user/SendEmail.jtp?type=nodenode=7590492i=3]
Sent: Friday, November 8, 2013 1:04 PM
To: [hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=4
Subject: Re: [WiX-users] Purely WiX patching and FeatureRef
Well I just did a test of Patch Creation using two different
Well add my name to this request as well to having this work be put to the
top of the list
Since Purely WiX patching requires generation of the .wixpdb files I would
like to know how these work if the install supports multiple languages? We
had generation of the .wixpdb files turned off as at
I have been testing the 2 patching methods for WiX:
Using Patch Creation Properties
Using Purely WiX
I have created basic samples for both and got both of them working okay so I
am now try a real install upgrade patch.
So I get the .msi and .wixpdb files for say version 1.0 and for version 1.1
Here is part of my build log and all are referring to binary and merge Id's
that are listed in fragment files and referencing the path that our build
machine created for the build:
D:\BuildAgent72\work\9f69624fb270635f\BoardSW\install\win\SMART Product
Drivers
\Core_x86PNPDrivers.wxs(158) : error
Thanks Blair, I have created bug #4187.
I have added, to the bug, the dropbox link to the zipped up product files
that can be used to reproduce the issue as well. So hopefully a solution to
this issue can be found or at least maybe let me know what I could possibly
be doing that may be causing
We just added a new registry key to our installer:
RegistryValue Id=ArgumentTemplate_Regkey Name=ArgumentTemplate
Value=BUT_AREA_CAPTURE –x{0} –y{1} –w{2} –h{3} Type=string /
Our install supports 26 languages and during the install we will get the
following error on this registry key entry:
/cc305152
Carter
Quoting TimM [hidden email]/user/SendEmail.jtp?type=nodenode=7593051i=0:
We just added a new registry key to our installer:
RegistryValue Id=ArgumentTemplate_Regkey Name=ArgumentTemplate
Value=BUT_AREA_CAPTURE –x{0} –y{1} –w{2} –h{3} Type=string /
Our install supports 26 languages
I have the same issue, and the files that I am including are 3rd party files
so we can not change them.
I tried the DefaultLanguage = 0 and I then get a LGHT1101 warning. So that
does not solve the issue. So if we can not get rid of the LGHT1076 warning
I guess we would have to just ignore
Danish,
The tool that you were creating to help with Dynamic linking of files to a
WiX install is it done yet? If so where can we get it to try it out?
Now I am really new to WiX and therefore do not know the in's or out's of it
as I have been using InstallShield for quit some time now. Now I
Sorry, I did not mean during Minor/Patch creation that files can be deleted,
but during regular development that they can be. As long as each component
is correctly set up with single folder link and a static key file then each
build will not generate a new guid/keyfile.
Anyways as I mentioned I
I am new to WiX and therefore just trying to duplicate one of my
InstallShield install projects in WiX.
We have many merge modules that are both set to follow the parent installer
INSTALLDIR location and some that have hardcoded paths in them so that the
files are installed in to shared
I have a wixlib project that now needs to install files that are within a
merge module. I thought that just adding the Merge Id to the wixlib fragment
DirectoryRef and the MergeRef Id to the fragment Feature Id that it would
just work, but it did not.
The wixlib built without errors and during
Thanks Rob...
It actually turned out to be the first build I did from TeamCity did not
link in the merge module as it did not have access to it at the time. So the
wixlib that went into the parent just did not have the merge module to
install.
So I re-verified with the latest build and it
Hello,
We are currently building with WiX 3.7 and our install supports multiple
languages and I just added the FirewallExecption to our project. And we are
also receiving the localization error LGHT0102 for the firewall strings.
So this still has not been fixed/updated as of yet? Or am I also
I am just starting to use the Wix FirewallException element to create File
exceptions for Domain and Home\Work (Private) entries and it seems to work,
but I just have a slight concern when viewing the msi log for these actions.
The entry in the log looks corrupt and I am just wanting to know if
Actually during my testing it looks like the Domain exception does not seem
to be created, only the Private exception is created.
So maybe I have something wrong with my configurations. Here is what I have:
fire:FirewallException Id=NB_FirewallException_Private
Name=[ProductName]
We have ran into a case where a change in our product has now required one of
our files to need access through the firewall. We need Domain and Private
rules set.
Since I have not used the new FirewallException element before I do not know
if I have the configurations set up correctly or not.
Thanks Phil.
We at first did use Profile=all, but it was decided that we did not want
our program to have Public firewall access. So we figured that we would
simply create the 2 entries, one for Domain and one for Private. But as
stated above only Private gets enabled and Domain does not.
So is
Sorry for taking you away from Torch work Phill.
Now with my code my Id's are different, so it is not that that is causing
the issue, but I noticed that you are not using the File or Program elements
and you also have your Scope set to 'localSubnet' where as mine is set to
'any'.
If you do
Okay I changed the Name entries and it finally worked
So this works, but it would have been nice to be able to use the same Name
as we let the app run without the firewall entries and it prompts for
firewall exception then it will create the entry using the app name and
therefore there is
Okay newbie question here concerning the updating of a .config file during
install, using WiX 3.7.
I was given the task to update a new .config file during our install and I
found the documentation for XmlConfig Element (Util Extension):
Okay I tried the following:
util:XmlConfig Id=ServiceInfo Action=create
ElementPath=/configuration/appSettings/
Name=ServiceInfo Value=[LYNC_SERVER_ADDRESS]
File=[INSTALLDIR]RemoteInk.exe.config On=install
Sequence=9 /
This one did nothing at all,
Okay I am re-looking at the XmlConfig method as described in the following
link:
http://sourceforge.net/p/wix/mailman/message/20326106/
And when I use the example that is in that link I get the following failure
in the install:
Failed to find node:
I have just been given a task to update one of our apps .config file and so I
tried what was listed in this topic but I am getting the following error:
Failed to find node:
//configuration/appSettings/add[@key='ServiceInfo'] in XML file: C:\Program
Files
1 - 100 of 157 matches
Mail list logo
