Hi,
Experience has taught that the best experience for the user and for the
developer and the support organisation is to follow the way that the burn
bundle works, it has been very carefully designed.
Fire and forget bootstrappers are an alternative (I used to use this many years
ago
Add the file as a binary resource to your custom action and stream it from
there?
Or use the api to read it from the binary table.
http://blogs.msdn.com/b/icumove/archive/2009/06/23/custom-action-using-wix-reading-from-the-binary-table.aspx
It's usually easier to just install the file and then
If you allow the tools to decide what is in your patch it ultimately does a
binary comparison to see what has changed between versions and includes them if
there is any difference.
You would need to dig into the patch building tools to implement an override of
this behaviour to examine the
We use Trueupdate for delivering updates:-
http://www.indigorose.com/products/trueupdate/
We chose it instead of rolling our own as it had solved all the hard things
already (resuming downloads, firewall and proxy stuff) and it is quite
customizable.
Downsides are we had to learn lua and we
http://stackoverflow.com/questions/25311969/how-to-downgrade-a-third-party-file-in-a-wix-msi
[http://cdn.sdl.tridion.sdlproducts.com/static/corporate/SDLlogo2014.png]
www.sdl.com/
www.sdl.com
SDL PLC confidential, all rights reserved. If you are not the intended
recipient of this mail SDL
or other
use of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
in error, please contact the sender and destroy any copies of this information.
David Watson | Development Operations
Windows Installer version 2.00 was included with windows XP RTM and windows
2000 SP3
http://en.wikipedia.org/wiki/Windows_Installer#Versions
You would only need the redistributable if you were targeting an older
operating system.
David Watson | Development Operations Engineer
dwat...@sdl.com
The error says you are using the VS extension in some way. look for a Help
element or something else from that extension.
http://wixtoolset.org/documentation/manual/v3/xsd/vs/helpfile.html
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: 18 December
Do you have a verbose log we can peruse?
-Original Message-
From: Daniel Norman [mailto:daniel.nor...@snowsoftware.com]
Sent: 04 December 2014 13:09
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Issue with deploying MSI through SCCM and GPO
Thanks for your
http://msdn.microsoft.com/en-us/library/aa372388%28v=vs.85%29.aspx
-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
Sent: 21 November 2014 14:59
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] effects of not using authenticode digitally
If the msi is installed it is usually stored in the c:\windows\installer folder
and that would be used for autoheal repair.
I understand that burn caches packages in case this is not true anymore.
-Original Message-
From: Farrukhw [mailto:farru...@gmail.com]
Sent: 20 October 2014
location
it was when the install was performed.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: David Watson
You could also split your optional features into separate MSIs and use Burn to
control their installation behaviour, which may be easier in the long run than
trying to fight what windows installer is intended to do. You would probably
need a custom BA though.
-Original Message-
From:
Nothing built in at this time, you would need a custom action to encrypt the
password.
-Original Message-
From: pezmannen [mailto:pezman...@gmail.com]
Sent: 15 October 2014 11:37
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Repair removes application pool user
Anybody?
I would imagine that It would be fairly complex to do this as Project structure
varies widely with lots of files used to make up a wixproj.
I expect it would be much easier to create a report out of the final MSI as it
has all the information combined and is in a well known database structure
My notes indicate that you need to set a System.AppUserModel.ID for these to
work (I did this research a while ago and don't remember the details and if it
is still accurate under windows 8.1).
I understand though that if you don't do it explicitly windows will allocate
you one on the fly, but
Hi,
Has anyone successfully used a DigitalCertificateRef to add a new embedded .cer
in a patch to allow UAC patching to continue?
We have previously done this a few years ago by hacking MSIs and using a blank
patch family but now I can't seem to get either method to work.
It seems to be
It's there on my windows 8.1 and server 2012R2 machines.
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: 29 July 2014 07:37
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WIX environment variable missing from Windows 8.1
Does it work with
If you want to block the installation you can use the upgradeVersion element
with OnlyDetect='yes' to set a property to use in a launch condition with your
error message.
If you want to break the new installation away from the previous versions and
allow for side by side installation you can
You can add the new file in a new location in a patch, and it is simpler to
leave the old dll in place.
This may work out for you if the application supports the moved dll and will
ignore the old dll.
If you really need to you can also try and remove the file during patching see
Hi,
Has anyone used one of the new EV Authenticode certificates to sign MSIs and
bundles?
If so have you had any issues with it so far?
Also is it possible to export the public key into a cer file from the hardware
token to allow you to embed it in an MSI to do UAC-less patches?
Cheers
Dave
http://support.microsoft.com/kb/2901907
has it at
http://go.microsoft.com/fwlink/?LinkId=328856
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: 20 May 2014 10:57
To: wix-users (wix-users@lists.sourceforge.net)
Subject: [WiX-users] .NET 4.5.2
I am working on
Some large companies use mass deployment methods to distribute software to
thousands of users automatically and they prefer to use MSI files to do this as
the reporting they get back from them is better. They would tend to strip the
msi out of your bundle and use it directly (and silently).
In
If you want to do a major upgrade, ditch the upgrade elements for a
MajorUpgrade one, change the product Id to *.
Be aware that the MSI only pays attention to the first three parts of the
product version, but in this example it should upgrade.
-Original Message-
From:
Installers are registered by product code.
As Bob said the upgrade code is stored elsewhere in the registry in a different
format so you can't search for it.
-Original Message-
From: Karkare,Aparna [mailto:akark...@travelers.com]
Sent: 25 April 2014 12:52
To: General discussion about
Phil not Bob, sorry :)
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: 25 April 2014 13:48
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Queries on Upgrade
Installers are registered by product code.
As Bob said the upgrade code is stored
You can do a /layout to get the contents of the bundle, then you would need to
do an admin install with the msi.
Don't know if there is a /admin on the bundle, you could make one if not that
calls each msi in turn with admin parameters.
-Original Message-
From: Bruce Cran
Hi,
You can just use signtool to sign them like an .exe. There are some issues
around this though, you will probably not have access to the 3rd party
certificate which means you will have to use your own and explain to your users
that you resigned them should they care or notice. If any of
Ideally configuration like this should be done at first run by your application.
Your installer should deploy the config file in a safe place under your
installation folder somewhere where it is not in use then it should be copied
to the live location during configuration by the application.
You need to persist the VIRTUAL_DIR_VAL (store it in the registry) so the
uninstaller knows it has changed otherwise it will use the default values.
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
-Original Message-
From: Suvrajyoti Panda
You can trouble shoot your target machine for dependency issues by using either
dependency walker for native code (http://www.dependencywalker.com/) or use
fusion logging for .net to see if something is missing at runtime.
-Original Message-
From: Hoover, Jacob
http://wix.codeplex.com/SourceControl/latest#src/Setup/
-Original Message-
From: Bo Zhang [fabbricadigitale] [mailto:b.zh...@fabbricadigitale.it]
Sent: 04 March 2014 11:31
To: General discussion about the WiX toolset.
Subject: [WiX-users] How WiX created its own setup package?
Hi
If you need to pass information into an MSI at runtime you need to author a
public property.
http://msdn.microsoft.com/en-us/library/aa370912(v=vs.85).aspx
You should also remember what was passed in from the command line or it will
revert to default on a repair or patch, see:-
It looks like @AnonymousAccess is not a formatted type so it does not accept
the property.
You would need to author two mutually exclusive components that differ only by
AnonymousAccess and use the passed in condition as a component condition.
Dave
-Original Message-
From: Kiran
and see if they work.
Cheers,
Stephen.
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: 16 January 2014 16:42
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Problem with service install on non English OS
The wix properties
, you can see a bunch of errors starting around line 9319 as our
custom actions attempts to start the services.
Cheers,
Stephen.
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: 17 January 2014 09:29
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users
The wix properties are populated by an api call at runtime, so it should be
working fine and they are the correct option in this case.
There may be a specific issue in this language.
Is there anything interesting in the install log?
-Original Message-
From: Stephen I. Woolhead
If you are not shipping the simulator and it is already on the target machine
you can use a directory/file search to search the hard disk for it then use the
resulting property to set the registry value.
See
The easiest and cleanest way is to make the daily builds update the build
number (third part of the msi product version) each build and implement major
upgrade with a * product code (if you don't already)? Then dev builds always
install and remove any previous build.
You alter the product code
Its 0x0800 in CustomAction.Type
-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com]
Sent: 03 December 2013 12:43
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Deferred CustomAction Impersonate=y/n / vs.
elevation
Thanks.
What flag/option get set
my properties. Maybe a
Properties.wxs or (more likely) in the UI.wxs files since that's
where most of them get set.
Hmmm... Maybe it makes more since to place the feature definitions
in the wixlibs rather than in the 'main' wix project???
On Wed, Nov 20, 2013 at 10:08 AM, David
If you mean to share files between two different product MSIs then you need to
author them carefully to make sure that they share the same component guids.
-Original Message-
From: Daniyyel [mailto:daniel.bed...@freenet.de]
Sent: 15 November 2013 12:09
To:
Anything that is customizable is regarded as user data and should be installed
to a safe non-live location and then copied to the live location during your
programs first run configuration step (or post install custom action).
Your confg tool/CA then knows where the template source is (which is
They are right, burn is a tool to allow you to collect data and chain some MSIs
silently, but you will need to make a custom BA to get the most from it.
The visual studio installer is a custom burn BA that does just that.
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Create a 0kb placeholder files in your empty directories, if you want them to
be included automatically.
Would be an interesting addition to heat to allow empty folder harvesting.
-Original Message-
From: Chaitanya [mailto:chaita...@pointcross.com]
Sent: 25 October 2013 10:43
To:
that it is working fine.it is
creating empty folders.
On 25-10-2013 16:22, David Watson wrote:
Create a 0kb placeholder files in your empty directories, if you want them to
be included automatically.
Would be an interesting addition to heat to allow empty folder harvesting.
-Original Message
Check out this
http://stackoverflow.com/questions/3560370/custom-action-in-c-sharp-used-via-wix-fails-with-error-1154
Why are you not using the service control element to ensure the service is
stopped?
http://wixtoolset.org/documentation/manual/v3/xsd%5Cwix%5Cservicecontrol.html
-Original
The windows installer property reference is a good resource to know.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370905(v=vs.85).aspx
-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: 11 October 2013 17:10
To: General discussion for Windows
The evaluation order of launch conditions cannot be guaranteed.
Also they are conditions on which to launch the msi so if the condition is true
the message is NOT displayed.
I can't see your conditions to see if that is an issue for you.
If any launch conditions fail the rest of the conditions
You don't.
You have to change the maintenance mode UI to be what you want.
-Original Message-
From: dileep s [mailto:dileep.sanamp...@gmail.com]
Sent: 10 September 2013 12:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] [WIX] How to installing same MSI
You can host your ui in the bootstrapper ask all the questions, then install
sqlexpress if needed then run your msi with relevant properties to install the
services/populate the database.
Dave
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: 09
I don't think there are issues with re-distributing the wix toolset as I have
seen third party tools do that.
Double check the license.
I would personally just link to the site with instructions or if needed
distribute the entire toolset.
Dave
-Original Message-
From: biswajitbiee
Make a minor update msi that fixes the issue and get your users (or write a
stub that) runs it from the command line with the repair and recache msi
options.
msiexec /fv your.msi /l*v log.txt
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: 28 August 2013
I think -suid manages clashing ids if you only have one pass but not if you
run heat multitple times to generate fragments.
Dave
-Original Message-
From: jo...@msli.com [mailto:jo...@msli.com]
Sent: 16 August 2013 09:29
To: General discussion for Windows Installer XML toolset.
Subject:
.'
Subject: Re: [WiX-users] Adding a new dependent file to shared component
without breaking component rules
I agree. A common shared component has been updated and it needs fixing in
all the products because it can no longer be shared properly.
Phil
-Original Message-
From: David Watson
The latter behaviour is automatic, only installed features are patched.
-Original Message-
From: Swaroop Kare [mailto:swaroop.k...@ifdspercana.com]
Sent: 14 August 2013 10:12
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom installation in Wix Patch
In the wix major
This is now a bug in product1. It needs fixing at a priority that your
product owner decides. You must have an update strategy for that product,
what if it has a critical security issue/flaw?
You could release product2 as a burn bundle and include a fix in it for
product1 by adding a major
You need to update the file version to allow windows installer to know
whether or not to overwrite any existing file.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).asp
x
I don't think the string version is used but I always keep them both in sync
anyway.
Windows
/x64
Looks like I am pooched...
Steve
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: July-30-13 12:11 PM
To: General discussion for Windows Installer XML toolset.; David
Connet
Subject: Re: [WiX-users] Need help, how to put a condition on a merge
module
: David Watson [mailto:dwat...@sdl.com]
Sent: July-31-13 12:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on a merge module
in Product.wxs [P]
I did it by not using merge modules, I used pure wixlibs.
http
I don't think burn currently supports this kind of scenario well (it may but
I am not an expert).
What you could do is make a per-user burn bundle that just installs your msi
silently then add that as an .exe package to your main with-prerequisites
bundle.
Or indeed leave it the way you have it
Isn't the win64 setting on the component so you need to build a 64bit and a
32 bit version of each merge module (or wixlib).
This is easily done with a shared .wxs file and a compilation setting.
I have 32 and 64 bit components all up my build tree just because one package
needs a 32 and a 64 bit
What error?
-Original Message-
From: Pasquale Fersini [mailto:basquale.fers...@gmail.com]
Sent: 25 July 2013 14:42
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Error launching bootstrapper
Hi all,
on a user machine (Windows XP SP3) our setup, compiled
Hi,
We have been shipping with our own (non-burn) chainer packages for years and
not had any problems with these scenarios. In my experience if a
mass-deployment system is being used the end users machines are locked down
so they can't install software by hand so they could not use an .exe to
Don't you run it with the /layout parameter to download everything you need
locally then copy that to the other machine.
(Never tried it mind).
-Original Message-
From: Philip Mitchell [mailto:mitch...@trdeo.co.uk]
Sent: 18 July 2013 12:17
To: wix-users@lists.sourceforge.net
Subject:
Also you could use the Directory or DirectoryRef @FileSource attribute to
say where all files in a folder are pulled in from then you can make your
component definitions very clean.
e.g. your example component would be :-
DirectoryRef Id=myInstallerFolder FileSource=$(var.LocalRootDir )
Votive has been part of the standard wix install for a while. If you have
installed 3.7 you should have wix templates (etc.) available in visual
studio.
There should be a windows Installer Xml template group if you do file-new
project.
If not try a repair.
-Original Message-
From:
Merge modules are only really of use these days to share components with
other installation technology.
If you are totally wix based use wixlibs or wix fragments.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 11 July 2013 13:48
To: General discussion
It should come up as unsigned in the UAC prompt, if you have that disabled
you won't see anything. You can usually still install it.
-Original Message-
From: Ivo Beltchev [mailto:i...@ibeltchev.com]
Sent: 07 July 2013 23:34
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
Does it work if you remove the PatchCertificates elements?
I.e. is insignia hand holding you and doing everything so you do not need to?
-Original Message-
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: 08 July 2013 15:54
To: 'General discussion for Windows Installer XML
Generally people fix the issue and release a later build version, so your
scenario is quite odd.
If you can't do that you could take the msi with build 3698 in it and edit it
so that it does a major upgrade* (one that uninstalls and reinstalls) with
orca or insted (you may need to re-sign it
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To:
I don't think so, this is why we don't hide our msi entries, in case someone
wants to uninstall a patch.
It would be nice if there were a way to show updates but hide the msi.
I don't use burn yet, but I believe that you can author a patch bundle which
I assume you would be able to uninstall from
I think if you delete the key it and its updates would not be visible in ARP.
-Original Message-
From: rowbot [mailto:james.row...@microfocus.com]
Sent: 14 June 2013 10:18
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patch not visible in ARP if MSI installed via Bundle
Personally I would write a patch bundle, the reason I don't do it already is
it would involve customizing our chainer and I want to move to burn so it
would be wasted effort.
The bundle arp entry and the individual msi entries are slightly confusing to
the end user but we just named the bundle
these lines:
Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property
SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching
http://wyrdfish.wordpress.com/2011/01/05/32-and-64-bit-msis-from-a-single-sou
rce-file/
-Original Message-
From: Subbiah Ganesan [mailto:subbiahtv...@gmail.com]
Sent: 13 June 2013 06:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix help
Use wix
ProgramData is actually known as CommonAppDataFolder
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367992(v=vs.85).asp
x
so try
Directory Id=CommonAppDataFolder
Directory Id=JetrionDir Name=Jetrion
Directory Id=INKUSECONFIGDIR Name=Ink Usage
If you have uninstalled, the persisted property registry key should not be
there.
Check that the keys have been removed before installing your new version.
-Original Message-
From: chennam [mailto:chatrapathi.chen...@gmail.com]
Sent: 05 June 2013 15:30
To:
Your patch wix looks similar to mine but we use @MinorUpdateTargetRTM=yes
on the patch element as that is what you are doing it may be worth a go.
-Original Message-
From: Joe Flynn [mailto:roo...@gmail.com]
Sent: 22 May 2013 20:01
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
The User can be an Id of a util:User which in turn can have Domain, Name
and Password set as properties.
e.g.
iis:WebAppPool Id=platform.webapppool Name=SdlServer
User=platform.website.user Identity=other ManagedRuntimeVersion=v4.0
ManagedPipelineMode=integrated /
util:User
1) This http://support.microsoft.com/kb/834549 ?
2) Heat thinks the .exe is a com server, as it is another installer you can
ignore it. If you are bundling several packages together you may want to look
at the burn bootstrapper which will handle this much better than embedding
the sub installers
The usual thing to do here is generate wix file with everything in
componentgroup , then include a componentgroupref in a feature in your main
wxs file.
You can use Orca or Insted to open an msi file to see if contains what you
want.
Dave
-Original Message-
From: BGINFO4X
Interesting, I looked into it briefly and didn't think it would be possible
due to all the hoops you have to jump through.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 15 May 2013 21:58
To: General discussion for Windows Installer XML toolset.
Subject:
Do you use the -suid heat option?
-Original Message-
From: Marco Tognacci [mailto:mark...@live.it]
Sent: 15 May 2013 23:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Speed up installer for copy file using Heat
Yes, it could be possible to make an
Add a SKIPCONDITIONS property to each of your conditions and pass that in.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 08 May 2013 09:31
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Skip Bundle Condition
You could
The major upgrade pattern seems to be what you were trying to achieve and
it's the tried and trusted way of getting what you want.
Follow this http://wix.sourceforge.net/manual-wix3/major_upgrade.htm
Do not mess with reinstallmode in your bootstrapper, leave the defaults. You
could even use burn
Can you pass the credential info to the CA and do the impersonation inside
the utility?
Or install the utility and call it on first run?
-Original Message-
From: Joe Barker [mailto:joeb...@gmail.com]
Sent: 02 May 2013 16:36
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom
on first run, as our application is a web-based application,
so it's a little more difficult, as it only needs to be ran once per
server/install.
On Fri, May 3, 2013 at 9:53 AM, David Watson dwat...@sdl.com wrote:
Can you pass the credential info to the CA and do the impersonation
inside the utility
Interesting question and I've never noticed or thought about it.
By default it looks like you can edit the properties of any data file like
that, .exes seem to be blocked.
If you digitally sign your MSIs then the signature is broken if these are
edited, which is expected.
You can make the file
Antivirus or index server are favourites.
-Original Message-
From: Dexter [mailto:d8x...@hotmail.com]
Sent: 15 April 2013 15:33
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Slow Installs
Thank your for all the suggestions. I had already included many of the
suggestions
I think that using downgrades to support a rollback scenario is slightly
dangerous in that the user may not realize that they are putting an earlier
version on as it just gets on with it.
Most people block downgrades and let their users un-install and re-install an
older version or have any patch
The username and password could be stored encrypted in the bundle (when
passwords are supported or in a custom BA).
I've done this in MSIs / custom chainers before with custom actions, also for
persisting credentials in the registry.
Dave
-Original Message-
From: Spud
Indeed, directories are properties.
http://blogs.msdn.com/b/robmen/archive/2006/10/17/deciphering-the-msi-directo
ry-table-part-7-directories-are-properties.aspx
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 10 April 2013 16:02
To: 'General discussion for Windows
This sounds like a configuration task that is best handled outside
installation. Install your file to a neutral safe area in your installation -
somewhere it can be safely repaired without breaking anything. Attempt your
download, then copy either your safe file or the downloaded one into the
-Ursprüngliche Nachricht-
Von: David Watson [mailto:dwat...@sdl.com]
Gesendet: Donnerstag, 4. April 2013 16:06
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] download file from Internet
This sounds like a configuration task that is best handled outside
Product Id=* generates a new product code each time you build.
-Original Message-
From: Ackerman, Buddy [mailto:backer...@tnsi.com]
Sent: 22 March 2013 17:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about conditional statements in
language packs really sweet.
On Fri, Mar 15, 2013 at 8:26 AM, David Watson dwat...@sdl.com 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
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:timmay...@smarttech.com]
Sent: 14 March 2013 17:37
To:
Not really sure what you are meaning by an embedded UI here. GPO publishes
MSIs silently to client machines.
Also its possible to push several MSIs as part of one policy (we have to
document this for our customers so they can install prerequisites) so I don't
see an absolute requirement for
1 - 100 of 342 matches
Mail list logo
