I would like to know if there is a way to detect what triggered a product
uninstall.
Issue: We have some custom actions that should NOT be triggered if the
install is running in Upgrade mode. This is true for the upgrade install,
but the custom actions in the previous version, that is being
Okay I have been searching around and found the following property:
UPGRADINGPRODUCTCODE
I totally forgot about this property and therefore this is the one that I
should be setting my custom action conditions on.
--
View this message in context:
Nope the VM's are strictly captured snapshots and therefore no accumulative
changes are applied to the images.
Another thing to note is that we have our own uninstaller application that
simply launch the uninstalls of our products that are selected by the user
and the tester noticed that the slow
Here is the download link to the uninstall logs:
https://www.dropbox.com/s/5qivuotwbornc8t/UninstallLogs.zip?dl=0
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812p7600828.html
Sent from the wix-users mailing
Our testing department has been doing some install/uninstall testing with our
products and have reported that sometimes the uninstall can be very slow at
times and therefore wanted to know if we can fix these.I reviewed the logs
and there were no indication of any tasks taking an overall long time
Does anyone know of a way we can detect if there are pending Windows Updates
or currently running Windows Updates?We have seen this issue quite a lot
where we have 32 bit assemblies within our installs that get installed and
then published near the end of the install. But if there are pending
We have some advertises and some that are not. I'll have to check if the apps
to the shortcuts that are advertised are the only ones that produce sxs in
the event viewer during installs. If so then I'll check to see what happens
if I turn advertisement off.
Thanks.
--
View this message in
Coming back to this one just to see if there may be another reason for this
issue. Again it does not prevent out apps from running at the end of the
install, it is just an issue of seeing sxs errors in the Event Viewer.
I checked the app .exe manifest files and yes all the assemblies that are
No we are not doing nested installs. Since Wix does not support an admin
chain install that creates a output .msi we are using InstallShield to
create our chain installs to chain all out wix install projects.
We have quite a few wixlib 32 bit assemblies that we create to that gets
installed and
Yes that is basically what InstallShield is doing and again the only reason
that we are still supporting this is that we still have administrators that
push out our software by .msi only and therefore we had to support a multi
.msi package so that they only had to push out a single .msi file
Joe, did you ever get the MaskedEdit control to only accept Upper/Lower case
letters and numbers?
I am trying the same thing and I just want the MaskedEdit to only access the
same thing, but at the moment it will accept all characters and then I have
to create conditions/CA to validate to make
Subject: Re: PIDTemplate w/ MaskedEdit
According to this:
http://msdn.microsoft.com/en-us/library/aa733654(v=vs.60).aspx
all uppercase A might be what you need.
---
Phil Wilson
On Tue, Sep 9, 2014 at 2:30 PM, TimM [hidden
email]/user/SendEmail.jtp?type=nodenode=7596768i=0 wrote:
Okay
I have a MaskedEdit control that can either be blank or filled in. If blank
then next button will continue, but if any characters are entered then I
only want it to continue if all the required characters are filled in. So is
there some built in method to validate that all characters have been
Okay I have another question about the masked edit field. If we have a PID
that contains only letters and numbers then is there a maskededit setting
that will ONLY allow this mix of characters or is this something that it can
not handle and therefore other actions would have to be used to validate
I am updating the WiX 3.8 to see the differences in the updated Bootstrapper
and therefore I am looking at the following page:
https://classicwixburntheme.codeplex.com/wikipage?title=Guide%201referringTitle=Documentation
Just to follow the example it states to download 1033.zip and extract the
Sorry, Rob but I am still at a loss here as how what I would need to update
to be able to get the values of these environment variables into the WiX
burn bootstrapper that then get passed to my .msi installer. Again I am not
up to date with programming skills and therefore having to update code is
Okay so it is not as easy as adding a new control to the Success Page in the
theme because as stated I did that and it shows no problem, but have
basically no control over this and it's execution. So the actions that were
on the Launch button has to be switched actions that get triggered only if
Thanks Rob, I'll do that.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697p7596704.html
Sent from the wix-users mailing list archive at Nabble.com.
Yes I already do this, but I was trying to get the value so that it could be
appended to a property that gets passed to the main installer. Since what gets
passed to the install will override what defaults gets set in main install
those and therefore you lose the entries. I'll figure something
Oh and one more thing about customizing the burn bootstrapper theme files. I
figured that if it was too much work to simply add a checkbox on the success
screen and have it set to launch the app on finish, I figured that maybe
just add a text control at the bottom that then informs the user what
Yes this all works and all, but is there no way that we can have say some
text with a description of what will be launched?
I have a WiX .msi installer that contains all the standard and custom UI
that we need and it contains the check box at the end of the install for the
user to launch our
There are a bunch of Burn built-in variables that we can use, but if what I
want is not included in that list then how can I go about declaring a new
variable that gets a standard environment variable?
Basically what I need is to get the %USERDNSDOMAIN and %USERDOMAIN
environment variables and
Thanks Rob...
Since I have not yet had to do any Burn customization is there any samples
that would help me get started on how to customizing the
BootstrapperApplication?
Thanks.
--
View this message in context:
Okay I was able to generate a check box field at the end of the bootstrapper,
but now I need to know how it actually gets triggered to launch the app?
Here is what I have in the theme file:
Page Name=Success
Text X=11 Y=80 Width=-11 Height=30 FontId=2
We are randomly get having out WiX builds fail with the following:
[Light] light.exe error LGHT0001: Cannot create a file when that file
already exists.
The log does not indicate what file it is complaining about and I have not
seen any other reports of this error in the groups.
Has anyone seen
Thanks Phill,
I do not think someone would have been on the TeamCity build machine opening up
files at the times of the failures, so that should rule out that case. We have
a build step that will generate a new Product Code for the product and replace
the one in the WiX projects, but that
This could be a simple question, but at the moment I just can not see it...
For push buttons and check boxes we just add the amp; in front of the
character that we want set for controls Alt hotkey, but if you have Edit and
MaskedEdit controls how do you set it's controls Alt hotkey?
Thanks.
It was a request from one of our managers as they noticed that they can use
Alt-Hotkey on the Change Directory dialog box, even though this is a
built-in MS dialog box. But that dialog box can do it so they wanted in in
the main installer as I have a Custom Dialog box that has 5 edit controls
and
No I have not tried that so I'll give it a try.
Thanks.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Dialog-box-edit-controls-and-setting-Alt-hotkeys-tp7595958p7595962.html
Sent from the wix-users mailing list archive at Nabble.com.
Okay thanks Rob that did the trick. I had to make sure the static text
controls had Tabskip set to 'no' though to get it working. But all good
now
--
View this message in context:
My condition is:
Again we are still at WiX 3.7 so will not be able to look at the 3.8
functionality until we move to that version in our build environment.
I have not yet looks into the registry keys, but I guess that I should if we
support 4.5, but most of the machines that we will be
Okay now I am experiencing another issue with this.
Since I have set my Text to # so that I can accept values from 1 to
9 it is actually back filling my property with spaces if I enter less
than 5 numbers.
So if I enter '34' the property would end up being '34 ', meaning the
string now
That's the think though, I checked the install log after it failed to find
.NET 4.5 and the NETFRAMEWORK45 property was not generated at all. So if in
WiX 3.7 it will detect 4.5 and greater then it should have at least created
that property with the version that it found.
So why did it not do
Yes, I should have netfx linked in. It shows in my project References and it
is listed at the top of my wix project:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension;
Now we build through
Well I feel like an Idiot I was declaring Property Id=NETFRAMEWORK45
/ and missed the Ref part of it and did not even noticed after all the
examples that I looked at
Sorry for all the hassles that I put you through. I'll give it another shot
and more than likely it will work now..
Okay changing the property to PropertyRef fixed the issue.
The MsiNetAsseblySupport = 4.0.30319.33440
The NETFRAMEWORK45 = #378675
Which means that what is installed is: 4.5.51641
So I am good to go. Thanks for all the help.
--
View this message in context:
Thanks John.
After a bit of frustration I finally figured out my issue, it was one of my
conditions on the publish events that was screwing me up. Now that I fixed
that I can correctly enter 1 to 5 numbers and have it do what I expected it
to do
--
View this message in context:
I was actually using a PORT_NUMBER 0 conditions before I switched to
MaskedEdit and therefore once I switched I did not remove that condition as
the mask # does not accept negative numbers and therefore I did not need
that condition. Once I removed it then it began to work as expected.
--
I have seen many WiX articles on detecting .NET 4.5 or greater and I have
implemented the recommended entires, but my install will FAIL to detect .NET
4.5 on machines that have .NET 4.5 and 4.5.1.
Now we are still using WiX 3.7, and therefore if the machine has .NET 4.5.1
does the NETFRAMEWORK45
Thanks John, but yes I have seen that article and it still does not explain
how you can enter 1 to 5 numbers in the field.
If I change enter 1, 11, 111, the next but will fail to do anything,
but if I enter 1 then the install will proceed as expected.
So it seems that if the text field
I am trying to do a MaskedEdit control that can contain 0-9, so I set the
text to # and I have a default of 2279.
When test the dialog box the Next button will do nothing until I enter 5
numbers in the MaskedEdit control.
So what am I supposed to set the text field to so that I can enter
Piping in a little later here, as had no requirements for PowerShell custom
actions but now do.
Our product team is developing a Server app and require a bunch of
PowerShell actions to be ran, some only require triggering commands that are
used to log server info, but others are more
Thanks for the information John.
I'll prompt the developers on if they know what modes the servers will be
ran under, but I would figure that it would be Restricted.
I do not have much/any experience in creating C#, so are you suggesting a
wrapper .exe or custom action dll, which would therefore
Is it possible to reference a wixlib within a wixlib project?
I am re-asking this as I had no responses to the inquiry I posted back in
January:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problems-with-referencing-wixlibs-within-a-wixlib-project-td7591687.html
It has been a
I have looks at the WiX 3 Tutorial: Custom EULA License and MSI localization:
http://weblogs.sqlteam.com/mladenp/archive/2010/04/15/WiX-3-Tutorial-Custom-EULA-License-and-MSI-localization.aspx
And see how they had to actually modify the LicenseAgreementDialog.wxs file
to accomplish this, but as
Thanks Rob.
No I have not seen this. I am definitely not a high end developer as I do
mostly install related development, but with that said I could always have a
sand boxed look at the code and see if I can figure out how to implement and
test.
What would I need to be able to look
Okay, since for now I have to use the modify method for the License dialog
found another issue that would be nice if it could be supported as well.
In the tutorial the set the following in the language string files:
String Id=LicenseRtf
Overridable=yes\Lang\en-us\EULA_en-us.rtf/String
But
Okay I do have this working now, but have one more question on this...
If the element keys exists and you only have to change the values then we
can simply use the XmlFile action=setvalue method.
If the element keys do not exist then I had to use the XmlFile
action=createElement and a few
Bob, what was the 'normal' custom action that you used at the end of the
install to launch your app with arguments?
I was also using LaunchApplication to trigger the launch of my application
at the end of the UI by check box selection, but I also needed to supply
arguments and therefore it did
This does not work if the file you want launched is installed through a merge
module or wixlib as you can not specify the FileKey to an Id that does not
exist in your main wxs project. So what other methods are there to launch an
installed app at the end of the install that requires arguments that
Okay still having an issue with util:XmlConfig. If I use the following:
Component Id=ProgramComponent
Guid={68FCE723-347D-4FD9-A3DF-3BB5A961F0E0}
File Id=sample.config Source=sample.config Vital=yes DiskId=1/
util:XmlFile Id=ModifyServiceLocation Action=setValue
Okay do you have a small example of using XmlConfig to create and set the
value of a key, as I was also trying XmlConfig and I did not get any errors,
but it did not do anything to the .config file?
Thanks.
--
View this message in context:
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
Thanks eyoung, I made the recommended changes:
util:XmlFile Id=SetServiceInfo Action=setValue
ElementPath=/configuration/appSettings/add[@key='ServiceInfo']/@value
Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config
Sequence=5 /
But when I build the install I get the following
Thanks John, I made that change and the build worked but when I ran the
install to test it I get the following error:
Failed to find node:
//configuration/appSettings/add[@key='ServiceInfo']/@value in XML file:
C:\Program Files (x86)\CompanyName\Product\Product.exe.config, system error:
I added the Name=value entry, but I still get the same error???
util:XmlFile Id=SetServiceInfo Action=setValue Name=value
ElementPath=//configuration/appSettings/add[\[]@key='ServiceInfo'[\]]/@value
File=[#RemoteInk.exe.config] Value=[LYNC_SERVER_ADDRESS] Sequence=5 /
So I am still at a loss as
Okay I must be missing something as as I mentioned above this one did write
to the file, just did not write it correctly:
util:XmlFile Id=ServiceInfo Action=setValue
ElementPath=/configuration/appSettings Name=ServiceInfo
Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config /
When
Well I created the Sample and it worked correctly, using exactly what was
shown.
So then I simply substituted my app.config file with the sample.config file
and built and ran the test again and it failed?
So I figured that it was my .config file that was the issue, but then I
simply added the
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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.
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
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 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
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
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
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
1 - 100 of 157 matches
Mail list logo
