The WiX help file for WiX 3.0 has a bunch of how tos that document best
practices for various tasks. Most of them will likely apply to WiX 2.0 as well.
When you are done with your best practices doc I'd love to see a copy :)
Neil
-Original Message-
From: Greg Silin [mailto:[EMAIL
The Wix.chm file lists them. Look under the Advanced WiX Topics section,
Standard Custom Actions.
Neil
-Original Message-
From: David Bartmess [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 8:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users]
It is part of WiX 3.0.
Neil
-Original Message-
From: Kalvagadda, SivaKrishna (MLX Technology) [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 8:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating user groups using WIX
Thanks for
I don't know whether the change was intentional, but to fix this you can edit
the .wixproj file to redirect the location. See the Using WiX with MSBuild
topic in the WiX.CHM for the property you need to set.
Neil
From: Neil Sleightholm [EMAIL PROTECTED]
Sent:
There is a complete example of how to do this in the WiX help file that ships
with WiX. Look under the How To section.
Neil
From: Wong Shao Voon [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 2:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
Use the NetFx library that comes with WiX. See the WiX documentation, there's a
topic in the How To that describes how to check the Framework version. It
should also have a reference to a table with all the predefined properties for
each framework version.
Neil
Shao Voon,
Your attachment didn't come through, but I'm curious: why are you trying to
hand-author build process for this? WiX ships with a complete build process for
building WiX projects using MSBuild. See the topic Using WiX with MSBuild in
the Wix.chm file that ships with your install.
)...
Thoughts?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output
=detailaid=2127057group_id=105970atid=642714
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 1:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land
in bin
The answer to your last question is no, you do not need (and should not)
include the policy modules.
Neil
From: Travis Burkitt [EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 7:58 AM
To: General discussion for Windows Installer XML toolset.
Subject:
of mfcm90.dll for Winforms integration.
Phil Wilson
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Questions about using MFC Merge Module
The answer to your
Alex's blog entry at
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx
is a good starting point.
Neil
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 10:40 AM
To: General discussion for
Look in the Wix.CHM file for the How To topic on how to create shortcuts to
applications. It shows you the steps to take to author the setup correctly to
remove these errors.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Yen
Sent:
...)
Thank you,
Roger Yen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 18, 2008 4:26 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about LGHT0204:ICE43 and ICE57
Look
/2003; /
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, September 12, 2008 4:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land
in bin
You don't even have to that much. WiX includes a library to do this for you,
which you can just include and then reference the property with a PropertyRef.
See the How To: Check for .NET Framework Versions in the WiX CHM file for the
general approach, but substitute in WixVSExtension instead of
Robert,
This happens when you have multiple .wxl files in your project with different
cultures in them. Setting the Cultures field in properties will control which
languages get built, but the output will still go into the sub-folder (this is
so you can set up different configurations, for
build agent server
pre/postBuild event authoring more straight forward.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users
)\lang-locale folder.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output
I've found the MsiBreak environment variable is a very useful tool for
debugging custom actions. See
http://msdn.microsoft.com/en-us/library/aa368264.aspx for the details, but in a
nutshell:
1) Start a command prompt (if you are on Vista make sure it is elevated. XP
make sure you are an
folder.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land
in bin
in postbuild step. Prebuild processing currently only
involves strong name signing and sandcastle chm file generation prior to msi
build that uses those bits.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16
You should be able to use a combination of the Intel, Intel64, and Msix64
standard properties. They are documented at
http://msdn.microsoft.com/en-us/library/aa370905.aspx#hardware_properties.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Michael
Michael,
Were you getting ICE validation warning when you were using the # reference?
The way you had your components set up I would expect to see the validation
warning specifically designed to prevent us from having to think :) It was
raised in my installer when I used # incorrectly, so I
Sonar,
Have you looked at the sample on Alex's blog for doing major upgrades? The
details are at
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.
It's a little lengthy but it should give you the details you need to make this
work properly.
Neil
That's correct. This is alluded to in the documentation for ICE warning 69 at
http://msdn.microsoft.com/en-us/library/aa369019(VS.85).aspx:
If the component referenced with the [$componentkey] property is already
installed and is not being changed during the current installation (for
example,
Have you set the codepage appropriately on your Product element? See the
Code Page topic in the WiX documentation for more details.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nemzági Ferenc
Sent: Monday, August 11, 2008 3:19 PM
To:
relpy was extremely fast, thanks a lot!
I changed it Central Europan (1250), a it it works!
Thanks again,
Nemzagi
Neil Enns [EMAIL PROTECTED] írta:
Have you set the codepage appropriately on your Product element? See the
Code Page topic in the WiX documentation for more details.
Neil
If all you are trying to do is register your DLL in the GAC, add
Assembly=.net to your File element and it'll automatically get installed to
the GAC.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Poornima S [EMAIL
PROTECTED]
Sent: Monday, August
John,
Are you building using a .wixproj file? Or custom command-line stuff?
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Gilbert
(MBS)
Sent: Monday, August 04, 2008 4:26 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to
per
component (unless the assembly consists of multiple files and is a multi-module
assembly).
Neil
From: Poornima S [EMAIL PROTECTED]
Sent: Monday, August 04, 2008 9:54 PM
To: wix-users@lists.sourceforge.net
Cc: Neil Enns
Subject: Re: [WiX-users] Call
Neil,
Can you open a sourceforge bug on this requesting the clarified documentation?
Thanks!
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Neil Sleightholm [EMAIL
PROTECTED]
Sent: Sunday, August 03, 2008 2:38 AM
To: General discussion for Windows
that is
generated in the tfsbuild.proj into the .wixproj. So there is no way
to get them into the .wixproj?
Thanks
2008/8/1 Neil Enns [EMAIL PROTECTED]:
Joe,
Simply setting properties in the tfsbuild.proj file won't get them passed
down into the .wixproj. I wasn't sure about this and had to look
Sajid,
Create a .wixproj file either manually or using the Votive integration with
Visual Studio, then check that project into TFS. After that's done you can go
through some easy steps to check the WiX tools into TFS and make a minor
modification to the .wixproj file so it will build on your
Here's the documentation I mentioned that should show up in the next weekly WiX
build:
Integrating WiX Projects Into Daily Builds
One of the most common reasons for using MSBuild with WiX project files is to
integrate the build of an installer into an existing daily build process. This
is
You can definitely do this. My first question is why are you using
CreateProperty instead of setting a property directly using PropertyGroup
elements? You should only have to use CreateProperty if the value is something
computed on the fly by the build.
Here's what our project file looks like:
Fixed a typo below, I botched a closing PropertyGroup tag.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, August 01, 2008 9:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Overriding
, the DefineConstants should be totally
replaced using the above code, but when checking the build log, it has
all the defines that have been specified using votive.
Any ideas?
2008/8/1 Neil Enns [EMAIL PROTECTED]:
You can definitely do this. My first question is why are you using
CreateProperty
Stefan,
We had the same problem and resolved it by simply downloading the source to WiX
and then building the printeula project inside of it. Then we included the
printeula.dll in our installer.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of
Something's not making sense. Properties like [WindowsFolder] are stored
directly in the MSI and are resolved at install time. Were you simply using it
as a path in something like a File element? What do the install logs show
when you run the MSI on the target machine?
Neil
That GUID would be generated at MSI build time, not at MSI install time, so it
won't be unique for each user.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Pat Higgins [EMAIL
PROTECTED]
Sent: Monday, July 28, 2008 4:51 AM
To: General discussion
Greg,
Check out the netfxutil extension. It includes many properties, including the
directories for various versions of the framework. The help file has a how to
on using it to get the framework version, and that is similar to using it for
the directory. All the available properties are in the
To elaborate a bit on what Rob states below (thanks for setting me straight,
Rob!), you can use !(loc) variables as the value for the Source attribute on a
File element. So in your Japanese localization file you can set a String
property to the path to the Japanese version of the files on disk,
For those that don’t read Bob’s blog and see the weekly release summaries,
please pay close attention to the note below regarding changes to address bug
2020595. In builds 3.0.4325.0 and later the output location for WiX builds of
localized installers is now
This won't work because you're using a pre-processor check for your condition,
which happens at the time you build the MSI, not at the time you run it.
You need to do the check by adding a Condition element to the Compnent
element that I assume eventually includes the Registry snippet below.
One option to consider is using the shipping MSBuild .targets file that has a
complete build process for WiX in conjunction with NAnt. Trying to re-construct
a build process using individual tasks is often fraught with peril, and using
the one that ships with WiX is almost always a better idea.
Ilya,
If we changed things so the localized output went into subdirectories, rather
than modified the name of the MSI, would htat work for your situation?
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ilya Slobodin [EMAIL
PROTECTED]
Sent: Monday,
PROTECTED] On Behalf Of Dominik Guder [EMAIL
PROTECTED]
Sent: Monday, July 21, 2008 12:23 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Localization filename change
Neil Enns wrote:
While Rob wasn't part of the change, I was :)
I'm looking for feedback on how to best approach
) into the
overridable property, say TargetDirLocalized.
Best regards,
Ilya Slobodin
- Original Message -
From: Neil Enns [EMAIL PROTECTED]
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Monday, July 21, 2008 6:18 PM
Subject: Re: [WiX-users] Localization
This was my approach for a long time as well, but last week I changed to using
a binder variable. The core application we install is always stamped with an
assemblyversion by the build process. Instead of passing flags in via the
Candle command line, or using a pre-processor variable, I now
While Rob wasn't part of the change, I was :)
I'm looking for feedback on how to best approach tweaking this. One option
that's been suggested is to not rename the MSI file, and to instead put them
into subdirectories. So on a build you'd have
Taking this approach will require literally pulling in everything, right?
Including all the localization files for WiXUI_Minimal?
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General
Adam,
WiX ships with complete MSBuild support through a set of tasks and targets,
there's no need to try and hand-edit things.
Do you have Visual Studio installed? If so, create a new Visual Studio project
and look for a WiX node in the new project dialog. Create that, add the
contents of
one I have at the moment), then just use the MSBuild task in my build
file to build them. Does that sound sensible or have I overcomplicated things?
Anyhow, thanks again - everything's working.
Adam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil
] On Behalf Of Tony Juricic
Sent: Wednesday, July 16, 2008 7:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Same problem here so I second a plea for help and more info
-Original Message-
From: Neil Enns
, July 16, 2008 7:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Same problem here so I second a plea for help and more info
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent
You can think of merge modules (MSMs) like an application DLL: it's a package
of install instructions that can be included in a parent installer. You still
need some sort of tool to author the MSM, something that explains what files to
include, where they should go, and what the order of
Murray,
I checked in changes between the builds you mention that change how localized
installers are built, to support multiple .wxl files in a project.
To figure out what's going on I'll need to see the verbose build log. From a
command line type msbuild /v:d yourproject.wixproj foo.txt then
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 16, 2008 7:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Neil Enns wrote:
Well, unfortunately, that's not what's happening. It's
Murray gave me some logs and a sample project offline, and there is indeed a
bug in the new localization work I checked in last week. If anyone else hits
this let me know and I can give you a workaround.
Thanks,
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
: Wednesday, July 16, 2008 8:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Neil Enns wrote:
Still no love through the verbose log. I'm going to try making our app
restart manager aware (which we should
It appears that our installer is magically detecting whether our application is
running at the time of an install, and even correctly closes it. However, the
FilesInUse dialog that comes with WiXUI isn't showing anything in the listbox
of running processes. What magic do we need to do to
PROTECTED] On Behalf Of Bob Arnson [EMAIL
PROTECTED]
Sent: Tuesday, July 15, 2008 6:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Neil Enns wrote:
It appears that our installer is magically detecting whether our
Thanks for the suggestion, Amir. I'll tweak it next time I'm mucking with the
help file.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Amir Kolsky [EMAIL
PROTECTED]
Sent: Saturday, July 12, 2008 4:37 PM
To: General discussion for Windows Installer
My application will wind up shipping with a ton of loose resource files on
disk*. We will have several items with the following well-defined structure:
MyFile1.foo
MyFile1_files
\ 0
\ somefile.txt
\ 1
\ somefile.txt
...
\ 9
\ somefile.txt
This is how the files live
. Paraffin handles much of the GUID generation and updating
for you. For maintaining large directories of non-binary files where additions
and removals are common, this tool works very well for me. I just wish it
generated WiX 3.0 code
Jason Swager
- Original Message
From: Neil
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
From: [EMAIL PROTECTED] on behalf of Neil Enns
Sent: Fri 11/07/2008 07:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Automating the inclusion
screwed (cause, in the worse case, all the GUIDs will change)... so
buyer-beware.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 11, 2008 07:13
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users
I'm messing around with trying to get my installer's ProductVersion to be based
off our main application's assemblyVersion. I thought this would be as simple
as putting !(bind.assemblyVersion.MyApplicationId) in the right places, but
this doesn't work unless I put Assembly=.net on my main
://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for-assemblies-without-installing-into-the-gac.aspx
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
--- On Fri, 7/11/08, Neil Enns
Christopher,
Last night in my aborted attempt to automate including files in my installer, I
got a basic extension up and running and working. If you can wait, I can zip it
up and send it to you tonight as a starting point.
Neil
-Original Message-
From: [EMAIL PROTECTED]
be excellent. I can't really wait, but I fear I will not make
substantial progress today, so it would probably be wonderful to have this
anyway. :-)
Chris
On Fri, Jul 11, 2008 at 1:17 PM, Neil Enns [EMAIL PROTECTED] wrote:
Christopher,
Last night in my aborted attempt to automate including files
John,
I don't think anyone got back to you on this yesterday. Unfortunately there's
no way to suppress the warnings at the merge module level. It's all or nothing
at the project level.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of John Nannenga
What errors are you getting?
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:25 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stable Wixv3 build for VS 2008
Hi,
Need help with the Wixv3
While we do not use WiX inside TFS, we do use WiX in a daily build process on a
machine without installing WiX on the build machine.
Instead, we have checked in all the WiX binaries and targets files into the
tree. Basically, this is the contents of C:\Program Files\Windows Installer XML
See:
http://wix.cvs.sourceforge.net/*checkout*/wix/wix/src/ext/UIExtension/wixlib/ErrorProgressText.wxs
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of andywhitt
Sent: Wednesday, July 02, 2008 11:39 AM
To: wix-users@lists.sourceforge.net
Subject:
Andreas,
Another option is to make ProductName a localization string in your wxl file.
Then use !(loc.ProductName) everywhere, including in the Product element. This
is what we do and it works like a charm.
Neil
-Original Message-
From: Andreas Hellwig [EMAIL PROTECTED]
Sent:
Rather than prompt the user to do the uninstall, have you considered having MSI
take care of it for you? How to make that work is reasonably well documented at
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.
Note that this requires you increment
A new How To topic (should be in the next weekly build) covers launching your
installed application after install. While not exactly what you are trying to
do it does demonstrate how to use the ShellExec cusotm action. You can modify
it slightly by changing the WixShellExecTarget element to
And the list of properties is at
http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx. They start with
ARP.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rob Hamflett [EMAIL
PROTECTED]
Sent: Monday, June 30, 2008 5:34 AM
To:
Try the following two blog entries:
http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Oh, wait, that's the same blog entries referenced by the FAQ item you said you
read and followed below :) Never mind me... it's Friday morning.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, June 27, 2008 10:17 AM
Bryan,
I have a new how-to topic out for review that covers launching an application
based on a checkbox at the end of setup. I've included the text of it below.
Assuming your installer has UI, you can wire up the action in the same way (to
the Finish button), but simply omit the piece that
If you installed the latest weekly build of WiX 3.0 you can find several how to
guides in the help file that was installed. There's a complete sample on how to
build a simple installer, as well as examples on using registry keys. For
information on dialogs see
For #1 I keep forgetting that's one of the topics on my list to add to the
docs. In the mean time you can read Alex's blog entry which is how I got it
working:
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.
For #2, we have this set up as a WiX
I just gave this a try with a clean Votive project by manually editing the
.wixproj file to add $(Project) to the output name and it worked fine. Here's
what my MSBuild property looks like:
OutputNameWixMergeModule1 $(Platform)/OutputName
This is with WiX 3.0.4022.0.
Can you send out what
Ah escaping. I'm not sure if it's a VS2008 vs. Votive thing either, but if you
want to take a test to see how painful figuring out what to escape can be, see
the following blog entries on how VS/MSBuild handle things:
http://blogs.msdn.com/msbuild/archive/2005/10/27/484742.aspx
] On Behalf Of Neil Enns
Sent: Wednesday, June 25, 2008 10:15
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] VS setup project - WiX 3.0 conversion
For #1 I keep forgetting that's one of the topics on my list to add to
the docs. In the mean time you can read Alex's
this project. :-)
-Chris
On Wed, Jun 18, 2008 at 10:34 PM, Neil Enns [EMAIL PROTECTED] wrote:
You can use it stand-alone, but it's also part of the Votive stuff that's
significantly reworked in WiX v3. Assuming you installed WiX v3 on a machine
that has VS on it you should be able to do File New
Andreas,
You'll need to manually build each localized version of your MSI. Votive
doesn't currently support building multiple installers per language, nor
selecting between them at build time. Here's the information from the How To:
Build a localized installer topic in our new help file:
How
It is a best practice to always have one assembly per component. This gives you
far moe flexibility when you have to service your application.
Neil
-Original Message-
From: Shiliang Li [EMAIL PROTECTED]
Sent: Thursday, June 19, 2008 6:46 AM
To: wix-users@lists.sourceforge.net
You can't, assembly version numbers are stored as numbers by the OS, so leading
zeros are stripped.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maxim Vyazovsky
Sent: Wednesday, June 18, 2008 8:31 AM
To: wix-users@lists.sourceforge.net
Subject:
/aea71120584104c1c6b99d3ba93e.jpeg
what about this?
On Wed, Jun 18, 2008 at 7:01 PM, Neil Enns [EMAIL PROTECTED] wrote:
You can't, assembly version numbers are stored as numbers by the OS, so
leading zeros are stripped.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED
Here's the info on how to do it from the new How To topic I wrote on this very
topic that should show up in the next weekly WiX build:
How To: Install the Visual C++ Redistributable with your installer
If your application depends on the Visual C++ runtimes you can include them as
part of your
Fixed a small wrapping issue below that made the code sample hard to read.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Wednesday, June 18, 2008 9:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX
anyhow, thanks for pointing this out.
On Tue, Jun 17, 2008 at 10:08 PM, Neil Enns [EMAIL PROTECTED] wrote:
Chris,
I'm curious, why do you use this approach instead of the shipping
wix.targets build process that comes with WiX?
Neil
From: [EMAIL PROTECTED
Interesting, the docs for Control do say that you can use the Text element
underneath Control when CDATA is required.
In your case, since you don't need to wrap your text in CDATA, you can just use
the Text attribute instead:
Control ... Text=[CreateVantageAdminDomainIdentityTextLabel]
...
Chris,
I'm curious, why do you use this approach instead of the shipping wix.targets
build process that comes with WiX?
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Chris Mumford [EMAIL
PROTECTED]
Sent: Tuesday, June 17, 2008 8:04 PM
To: General
Does Votive do the actual conversion or is it candle.exe?
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander
Shevchuk
Sent: Thursday, June 12, 2008 12:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
Did you add a reference to the SqlExtensions? Right click on the References
node in solution explorer and in the resulting dialog add WixSqlExtensions.dll.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Reed (SQL)
Sent: Thursday, June 12,
1 - 100 of 135 matches
Mail list logo
