We've run into this. Luckily the one largest SQL script is also the last one we
need to execute so we removed it from the installer and just have customers run
that one manually using SQL Management Studio. About 34 seconds to run through
there while the installer takes an hour and a half to
For things IIS related not directly authored in WiX code I've found APPCMD.EXE
to be a useful substitute in a custom action for those sorts of things. These
are older and may be supported natively now, but some examples.
CustomAction Id=ConfigureHiddenSegments Execute=deferred Impersonate=no
I compiled and linked your example into an MSI and ran it and it works great.
Notepad.exe and Readme.txt installed. Remember if you are on a 64-bit system
you need to look in C:\Program Files (x86)\Example to find your installed files.
-Original Message-
From: Richard Silverstein
example.wixobj
With this, I do not get the FOLDER and abc.txt in the installed directory along
with Notepad.exe and Readme.txt.
Rick
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Friday, July 12, 2013 1:18 PM
To: General discussion for Windows Installer XML
with Notepad.exe and Readme.txt.
Rick
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Friday, July 12, 2013 1:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] help needed including directories
I compiled and linked
Look at what you pointed to. It's an article from 2006 dealing with
InstallSheild 12 (NOT 2012) so it is very old. Some of it still applies to
older projects but I don't think that applies to a Basic MSI project.
If you run your MSI with MSIEXEC.EXE command line parameters to generate a
Try setting this
Property Id= CA_WebAppPoolPassword.SetProperty Hidden=yes/
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Thursday, May 02, 2013 2:56 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Hide/blank out
If possible paste in a snippet of your log file around where the password is
seen. I tried for a long time to hide passwords using the same method. But it
was some built-in custom actions that were logging my passwords rather than
code I'd written myself.
Property Id=ConfigureIIsExec
I'd bet you haven't changed this variable.
Id=$(var.ProductCode)
While in there make sure this is set to what you want also.
Version=$(var.VersionNumber)
Make sure you do keep this one the same (it is if you get the message you
mentioned)
UpgradeCode=$(var.UpgradeCode)
-Original
Check to see if the InstallShield is a Per-user or Per-machine install and
compare that to your WiX installer. A per-user install can't be removed by a
per-machine install. If ALLUSERS isn't set or is set to 0 then that's per-user.
If ALLUSERS is set to 1 then it's per-machine.
-Original
+1 for Orca. I use it a ton to inspect the resulting MSI and see if it looks
like it built like I wanted it to. You can sort by Sequence number in those two
tables to see what relative order things go in. Very handy.
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
these various Windows folders in my DIRECTORYREF its not taking.
How can I overcome this problem.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: 07 January 2013 23:28
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Changing
In addition to that you might want to read up on the ROOTDRIVE property as it
appears it is somewhat involved in the symptoms you are describing.
http://msdn.microsoft.com/en-us/library/aa371372(VS.85).aspx
Also, don't forget about the well-known properties that identify various
Windows
If you gather a verbose log file you might search it for the word ROOTDRIVE.
This property can alter where an installation automatically goes.
You can set ROOTDRIVE manually in your WiX code, too.
Property Id=ROOTDRIVE Value=C:\ /
-Original Message-
From: Chaitanya
That Windows for you. Existing CMD consoles don't get updated environment
variables. Happens with no installer involved, too. For example, open a CMD
Prompt. Then go to your Environment variables and alter your Path. The altered
Path won't show up in the running CMD Prompt, but new CMD Prompts
A person does need to use OnlyDetect=no to have a product removed. With it
set to yes it will only detect that it is there, but not remove it.
It's at least one thing to try.
-Original Message-
From: Chaitanya [mailto:chaita...@pointcross.com]
Sent: Wednesday, November 07, 2012 1:43 AM
Is your property all uppercase letters? Making it all uppercase makes it
public, otherwise it is private. Also if the property is being set in the UI
sequence and then being called in the Execute sequence you probably need to add
it to SecureCustomProperties.
Your ElementPath isn't pointing to anything beyond your root element of
appplicationSettings, as far as I can tell. You need to use XPath to specify
the inner text of that deeper element. Seems it is almost always some trial and
error to nail these. I like to create a mini installer that does
I was able to get past this error in your example by adding this inside the
Fragment
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence
-Original Message-
From: Don Walker [mailto:don.wal...@versaterm.com]
Sent: Wednesday, July 11,
What version of WiX are you using? I don't believe that RemoveFolderEx
would be available until WiX 3.6. Something to consider, at least.
-Original Message-
From: Shyam Kannam [mailto:shyam.kan...@gmail.com]
Sent: Wednesday, May 30, 2012 10:44 AM
To: wix-users@lists.sourceforge.net
Not sure it's what you want, but what I typically do in this case is run
REGASM /Regfile to generate a .REG file and then use Heat to convert
that .REG file into a .WXS fragment that I can then include in my
project.
-Original Message-
From: Sam Youtsey [mailto:sam.yout...@gmail.com]
I was also going to point out that Rob already responded with the same info and
you don't get much more WiX Team than that.
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 15, 2012 11:07 AM
To: General discussion for Windows Installer XML
A good test anyone can try. Run a command something like this.
MSIEXEC.EXE /L*v C:\Foobar\test.log /I path to MSI
For that log folder that you point to make sure the C:\Foobar directly DOES NOT
EXIST.
Note how MSIEXEC.EXE will simply error out rather than creating the Foobar
folder in which
-us/library/windows/desktop/aa372847.aspx
Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Chad Petersen
Check out the ToolTip attribute of the Control element. Should do
exactly what you are looking for. At least that is how I use it.
-Original Message-
From: James DellaRosa [mailto:jdellar...@aspexcorp.com]
Sent: Monday, March 05, 2012 12:35 PM
To: wix-users@lists.sourceforge.net
] Mouseover
That works as far as a hover over event is concerned thanks! Now a more
difficult concept... is there a way to make it so that the ToolTip
attribute can reference another control, say a text control?
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent
An option I use on the candle command line is just to pass an arg of
*.wxs rather than calling each. Likewise on the light command I pass in
*.wixobj.
I find it cuts down on the length of the command line.
-Original Message-
From: Ian Williams [mailto:iawil...@microsoft.com]
Sent:
Is this happening across all supported operating systems or have you
been able to narrow it down to something like Windows 2008 Server and
Windows 7, for example? Sounds like UAC *might* be involved. When logged
in as the Domain User in Administrators group do a right click on your
MSI and choose
I can probably answer one fairly easily. For the shortcut put it inside
of your file element
File Id=HelloWorld Source=$(sys.SOURCEFILEPATH)
Shortcut Id=DesktopShortcut Directory=DesktopFolder
Advertise=yes Name=Hello World Icon=HelloWorld.exe
Icon Id=HelloWorld.exe
Do you have a separate WebSite element in your code? I see the WebSite
attribute on the WebVirtualDir element, but I'm not seeing the WebSite
element. Maybe you didn't paste in into your e-mail.
iis:WebSite Id=Default Description=[WEBSITE_NAME]
iis:WebAddress Id=PortNum
If you open up your MSP in Orca does it have a FileShare and/or
FileSharePermissions tables? It sounds like it does based off of the
behavior you describe, but I'd hope it doesn't because I'd think
(ideally) your minor update should leave the shares and permissions
alone that were created by the
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370556(v=vs.85
).aspx
Would probably look about like this. You don't have to use CDATA blocks,
but my example used the symbol so I just went with it.
Component Id=XP Guid=[yourguid]
Condition![CDATA[(VersionNT = 501)]]/Condition
The inner text in a Publish element is the Condition expression. An
inner text of 1 says to always do it. I could be off here, but it
seems like you just need to set up a proper Condition for each inner
text to only show the given dialog under a given condition.
Mine look a bit like this
Publish
That does seem overly complex right out of the gate. Have you taken a good look
at the Binary element? This is how I make my files available to my custom
actions without having to copy anything to the local computer. Might not be
what you are after, but it's worth mentioning.
-Original
Microsoft used to provide the Windows Clean-up Utility (MSIZAP.EXE was
one common name) but I believe they must have removed it from their web
site.
This might be a viable copy of that same program. They seem to indicate
the author is Microsoft Corp.
Absolutely possible. Wouldn't be much fun if all files on installation
media had to be in the same folder. Wouldn't even work for files with
the same names that should go into different subfolders like you are
asking about.
On your hard drive just set up the folders the way you ultimately want
Trying to figure out the right approach to validate that a Web site
already exists during my install. In IIS6 I used
GetObject(IIS://localhost/w3svc) and queried that for the info the
user typed in. Any of you that target IIS7+ how are you dealing with
this? I am using a Web site locator for an
ServerManager
class.
--
John Merryweather Cooper
Jack Henry Associates, Inc. (Premier Tech, Inc.)
Build Install Engineer - jXchange
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Friday, October 21, 2011 1
if
end if
next
FindElement = -1
End Function
Thanks,
Greg
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Friday, October 21, 2011 12:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Validating Web site
Another option is to use the RemoveFile/ element tied to the same
Component as your File/ element. This will always clear out the
existing file prior to the current install writing the new one. Works
for rollback and uninstall.
Component Id=Filetxt DiskId=1 Guid=someguid
RemoveFile
That's very odd. The old MSI that installed those v.3 assemblies is the
one that should be removing them, not the newer MSI. If you don't
consider the upgrade, but just uninstall that older MSI through Control
Panel does it not remove the GAC'ed files? The Major Upgrade simply
uninstalls that
are the files being GAC'ed in the old installer? Custom action or
using the File element attributes?
--
John Merryweather Cooper
Jack Henry Associates, Inc. (Premier Tech, Inc.) Build Install
Engineer - jXchange
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
-Original Message-
From: Chad
I'm used to Major upgrades removing the previous release(s) so only the
newest major version shows in Add/Remove Programs. But, that probably
won't work if you have OnlyDetect=yes. And maybe that's not what you
want to do.
You might also check a clean install to see if all four files get
.
Do these files contain Version information
yes, all files have strong names
Is each file in its own Component?
yes
Kurt
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Wednesday, August 17, 2011 1:51 PM
To: General discussion for Windows Installer XML
We place some of our shared files in C:\Program Files\Common Files\our
company name
-Original Message-
From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
Sent: Tuesday, June 28, 2011 1:14 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How do you
Oh, and there is a known property called CommonFilesFolder as documented
here.
http://msdn.microsoft.com/en-us/library/aa367994%28VS.85%29.aspx
So, makes it real easy to use.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Tuesday, June 28, 2011 1:46
I'd suggest taking one step back. You mention a log file created in the temp
folder. Have you tried running your installer when the temp folder doesn't
exist or the TEMP variable isn't defined? If you are calling MSIEXEC /L*v and
wanting it to log to a TEMP folder I recommend you try it in
Your isn't working like that already? Well, it's a simple fix, but may
be needed in quite a few places. In the following example the amp; in
front of the character you want to use as the hotkey should do the
trick.
Control Id=Next Type=PushButton X=230 Y=243 Width=57
Height=18 Default=yes
Versioning is built into certain files like DLLs and EXEs and not into
other files like XML and text files. That much has nothing to do with
WiX or MSI. Files are either versioned or they aren't. MSI simply
reflects those versions, by default.
-Original Message-
From: Dave Combs
What I find immediately odd is that your sample shows single quotes
around double quotes on the Target/ attribute. I'm thinking it should
be one or the other, but not both. Maybe it's correct, but it is
different than the manual shows, too.
-Original Message-
From: Jonah Dahlquist
Heat /? shows usage. Looks like -ke is keep empty directories. I don't
see a way to exclude files, but maybe somewhere in the mix.
-Original Message-
From: CoolBreeze [mailto:coolbreeze...@googlemail.com]
Sent: Friday, May 13, 2011 11:20 AM
To: General discussion for Windows Installer
http://msdn.microsoft.com/en-us/library/0c6xyb66.aspx
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com]
Sent: Wednesday, May 11, 2011 7:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] missing assemblies referenced by
I might have missed but does this happen during a clean install, upgrade
or both?
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com]
Sent: Tuesday, May 10, 2011 1:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to
Check a verbose log file and it should say why it is not replacing that
file. Typically because it is newer than the file you hope to replace it
with.
The RemoveFile element can be handy for some of these types of issues.
Not positive it's what you'll want, but maybe.
-Original
file is unversioned but modified
I will look at RemoveFile. It seems kind of counter intuitive that on
installation I want to remove a file. Would I put the RemoveFile
element in the same component as the component that is installing the
file?
-Original Message-
From: Chad Petersen
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Wednesday, April 13, 2011 2:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX force copy file.
Yes
My syntax is a bit different than yours, but you might try removing the
[WPFINSTALLDIR] property from your RemoveFile element. But, I always
nest my Components under a Directory element, so our approach is
somewhat different.
-Original Message-
From: Kevin Burton
be missing something simple, because it
doesn't
seem
that it should be so difficult to get this to work.
On Mon, Mar 28, 2011 at 4:38 PM, Chad Petersen
chad.peter...@harlandfs.comwrote:
If you run a CMD prompt and change to c:\windows\assembly
folder
and
then do a DIR
Oh, and an easy way to see what each MSI was used for is to open the
C:\Windows\Installer folder in Explorer and add the Subject column to
the details. I can immediately see what each MSI belongs to. Quite
informative.
-Original Message-
From: Chad Petersen [mailto:chad.peter
PM, Chad Petersen
chad.peter...@harlandfs.comwrote:
Oh, and an easy way to see what each MSI was used for is to open the
C:\Windows\Installer folder in Explorer and add the Subject column to
the details. I can immediately see what each MSI belongs to. Quite
informative.
-Original Message
I think this is happening because your Silverlight check has a version
number in the registry Data and the URLProtocol has no value in the
registry Data for that string. I think you might need to check a setting
that would actually have a value. As soon as I put a value of Test in
the URLProtocol
You might check with Adobe and see what their recommended method is for
detecting their application. I've had good luck doing that with third
party apps I've needed to detect. Never actually needed to check for
Acrobat myself.
-Original Message-
From: kim [mailto:contactme...@gmail.com]
If you run a CMD prompt and change to c:\windows\assembly folder and
then do a DIR you will likely see GAC, GAC_32 and GAC_MSIL as
subfolders. Yours is apparently in GAC_MSIL. From there it has folders
following a name similar to your DLL name. Then a version specific
folder in which your DLL will
Is this a major upgrade or a minor upgrade? Sounds like the uninstall of
the older version might not be removing the service. Verbose log file
might be helpful. You can also hit Cancel during an install to
effectively pause it (then hit Resume to continue) to look at the state
of the machine at
Actually, I've been using [ComputerName] since MSI 2.0. If you read
those requirements a bit closer it goes on to say...
Windows Installer on Windows Server 2003, Windows XP, and Windows 2000.
Which implies just about any version.
The 4.0, 4,5 and 5.0 are required if you are on the newer OSes
X2
Even installs where I never use [ComputerName] the verbose log file
still lists the entry
Property(C): ComputerName = my computer name
Showing that this is always available for use in any install.
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent:
Or you could publish the property just before entering your custom
dialog, like in the preceding dialog.
Publish Property=MACHINENAME Value=[ComputerName]1/Publish
-Original Message-
From: Skildum, Mathew [mailto:mathew.skil...@aspect.com]
Sent: Thursday, March 24, 2011 12:59 PM
To:
I found OR Priviledged to work better than OR AdminUser. It actually
triggered a Windows message rather than the message in the condition.
!-- first make sure the platform is at least win 2003 --
Condition Message='Your operating system must be Windows 2003 or
greater'![CDATA[VersionNT =
I think it is because your Conditions are not mutually exclusive.
-Original Message-
From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
Sent: Tuesday, March 15, 2011 2:25 PM
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] One install for multiple OS
I've got an
I believe I might know what you are running into. You can't access things
destined for the GAC *during* the install. You probably will need to expose a
regular COM interface to your assembly and put it someplace accessible other
(also) than the GAC. We've had to do this with some of our .NET
Of course, there's more than one way to skin a cat. Check out Phil's suggestion
here
http://social.msdn.microsoft.com/forums/en-us/winformssetup/thread/9E48A3D0-ADF2-4CF3-B9BA-D5E9DE584C8F
-Original Message-
From: Colin LeMahieu [mailto:clemah...@gmail.com]
Sent: Tuesday, March 01,
In another area of your code look for the Product/ element and make
sure you change the Id= guid there as one necessary step. But, leave
the UpgradeCode unchanged in that same element. Also make sure you
increment your version number to something higher than that one you have
already installed.
I can offer some help. For the command line you append your PROPERTYNAME
followed by an equal sign and then the value you want to assign to that
property. Like this.
msiexec /L*v c:\log.txt /i my.msi PROPERTYNAME1=value1
PROPERTYNAME2=value2
In my experience it seemed like if you gave it all
Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Wednesday, February 23, 2011 11:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re
WiX version 3.0.5419.0
OK, my installer is working in a huge number of cases without hitting
this error. We released back in November. Today I get a log file from a
customer that doesn't get any on-screen error. The installer just
suddenly rolls back on its own. The verbose log file shows these
that the
installer is running as)?
Does it work? (does StartRunhttp://e3server start a browser?)
Do they have enough memory/disk space to create the shortcut?
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: 31 January 2011 17:36
To: General discussion
I think you'd mentioned before that it was during the compile, as
opposed to the link, which I suspect, too. You can certainly break those
down into two discreet steps to figure out which one it is. Assuming it
is the compile then it would be in one of the .wixobj files, since that
is what the
\platformclient
Core.Data.DataManagement.Plugins.Client is the project name (and the
assembly name + XPT).
So you see my dilemma, short of renaming everything I am left with the
warnings. To me, since the ID is generated, it seems like a bug...
-Original Message-
From: Chad Petersen
Use the sql:SqlScript/ element is the WiX way to do it. Working very well for
me.
-Original Message-
From: Anu Dev [mailto:queryl...@yahoo.com]
Sent: Wednesday, December 08, 2010 9:01 AM
To: WIX
Subject: [WiX-users] Run DB Scripts
Hi
How can I run DBScripts during the installation
When installing my package the icon for normal file shortcuts are
initially showing up as generic icons. Once a person double-clicks on a
particular one then the icon changes to the correct one. We did not have
this issue when compiling using WiX 2.0. In that version the Shortcut
table in Orca
: ICE57: Component 'Autotaskconfigexe' has both per-user
and per-machine data with a per-machine KeyPath.
If I leave it as Advertise=yes then no ICE errors, but the original
problem occurs where the icon shows generic until someone clicks it.
-Original Message-
From: Chad Petersen
?
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Tuesday, October 12, 2010 3:14 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] File share missing after major upgrade
If I do a clean install of our product I see the two
as
the
sequence involved.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Wednesday, October 13, 2010 7:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] File share missing after major upgrade
No, the previous major release
If I do a clean install of our product I see the two file shares showing
at the end of the install. However, when I do the major upgrade the file
shares are there before I start the major upgrade and are missing by the
time it is done. I've taken verbose log files of each and tried to
compare
Use a separate Component for each necessary shortcut and then apply a
child Condition on each component based off of the VersionNT= property.
Here's a good reference for VersionNT.
http://msdn.microsoft.com/en-us/library/aa370556(v=VS.85).aspx
-Original Message-
From: Wu, Emma (GE
I was having the same issue after converting from Wix2 to Wix3. Once I
added
LaunchConditions After=AppSearch /
To both InstallUISequence and InstallExecuteSequence then it started
working right for me. Sounds like what you already tried. If so, use
Orca to inspect both sequence tables and see
MSIEXEC /L*v [logfilename] /i [msifilename]
Replace the square bracket variables with your log file name of choice
and your MSI filename.
-Original Message-
From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
Sent: Monday, October 04, 2010 1:52 PM
To: General discussion for Windows
Our product requires another product to be pre-installed. We then
overwrite some of the other products files during our install as the
integration points between our two products.
If they are in Folder A and my product goes into Folder B, then it would
be true that when we detect them we are
CustomActionData is that magical packet of information passed from the
installer to your deferred CustomAction using the Value= attribute.
Then, your .exe (or VBScript or Javascript) has to set a variable to the value
of Session.Property(CustomActionData); so it gets a copy of this information
The folder is referred to as SystemFolder
I'm fairly sure you can get away with only a DirectoryRef to it since it
is a built-in property.
-Original Message-
From: Beekeeper [mailto:bria...@yahoo.com]
Sent: Tuesday, September 14, 2010 1:07 PM
To: wix-users@lists.sourceforge.net
In your Value= line you will need to escape the square brackets.
XMLConfig mentions this in the Value Attribute Description column.
Opening bracket - [\[]
Closing bracket - [\]]
-Original Message-
From: Alexander op de Weegh [mailto:alexan...@ipa-tp.nl]
Sent: Tuesday, August 31, 2010
That is handled by the ROOTDRIVE property. Not sure you can avoid USB
drives, though.
http://msdn.microsoft.com/en-us/library/aa371372(VS.85).aspx
-Original Message-
From: Prabhat_IE [mailto:prabhat.n...@gmail.com]
Sent: Tuesday, August 31, 2010 2:00 PM
To:
the Name= as then it will add to
the elements text.
util:XmlConfig Id=XMLMod50 File=C:\web.xml Action=create
Node=value On=install
ElementPath=/web-app/context-param[\[]param-name='DEFAULT_LOCALE'[\]]/p
aram-value
Name= Value=other Sequence=1 /
Dave
-Original Message-
From: Chad Petersen
I have an XML file that looks like this. The goal is to alter the en_US
to some other value.
web-app
context-param
param-nameDEFAULT_LOCALE/param-name
param-valueen_US/param-value
/context-param
context-param
Try adding the xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
schema to the top of the file that has the XmlFile element in it.
Mine looks like this
Wix xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://schemas.microsoft.com/wix/2006/wi;
param-nameDEFAULT_TIMEZONE/param-name
param-valuePacific/param-value
/context-param
/web-app
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Thursday, August 26, 2010 11:26 AM
To: General discussion for Windows Installer XML
-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Tuesday, August 10, 2010 8:18 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] InternetShortcut and public properties
On 8/10/2010 3:54 PM, Chad Petersen wrote:
Now that I'm past all my ICE errors I'm on to trying some new things
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] ICE34 error or Unresolved reference
On 8/9/2010 1:09 PM, Chad Petersen wrote:
What would be appropriate defaults for these properties? It seems like
it wants one of the choices from the RadioButtonGroup. For
MaintenacneMode this would
, August 07, 2010 7:53 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] ICE34 error or Unresolved reference
On 8/6/2010 1:29 PM, Chad Petersen wrote:
error LGHT0094 : Unresolved reference to symbol
'Property:MaintenanceMode' in section 'Fragment:UpdateUIStandard'.
The message says
This is my last stumbling block on my WiX 2.0 to 3.0 conversion. The UI
in all my projects is basically the same. It predates my use of WiX in
our company, so I'm not sure where it came from, but it's not
WixUI_Mondo, I do know that.
The pre-existing RadioButtonGroup definition is causing me some
1 - 100 of 267 matches
Mail list logo
