I'd suggest giving the 3.7 branch a shot, as it actually builds with MSBuild
(as opposed to 3.6 and older which was a combination of ugly Nant'ness).
-Original Message-
From: Filip Balas [mailto:fba...@petersco.com]
Sent: Friday, November 02, 2012 1:38 PM
To:
The bootstrapper will add itself to ARP (no real way to get around this nor
do I think it would be a good idea), but it will hide the install of your other
prerequisite installs. If you want the prerequisites to stay after uninstall,
then attributing them not to be removed will prevent those
: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: November-05-12 3:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] stop bootstrapper creating ARP registry key...
The bootstrapper will add itself to ARP (no real way to get around this nor
do I think
You only need to assign a property containing the values you are looking for
on deferred custom actions.
Remove
CustomAction Id=SetCustomActionDataValue1 Return=check
Property=myActionId1
Value=MyLocation=[INSTALLLOCATION];AnotherValue='Action1' /
Unless you are
An extension is used to extend the dialect of WIX at compile time (Ex:
UtilExtension and WixCreateInternetShortcuts) which may involve dynamically
adding a custom action DLL for the MSI use to execute the new logic. Custom
actions are only used as a function during runtime, though they are hard
The install log would tell you what exact version of Wix you are using. If it
isn't the RC, the first suggestion is going to be to update to the RTM version.
If you are signing your MSI and EXE with the same digital certificate, what
happens if the user tries to view the certificate on the
One could write a custom BA to handle this. You'd simply capture the success
with info code, and set a variable in the BA that it happened and return to the
engine a success message. Then upon install complete, evaluate your variable
and optionally show the more info to the end user.
Wix only packages the files you tell it to, so I would look at your WXS file to
see if the .config file is referenced.
Which config file are you trying to modify? Is it one for your CA DLL or the
managed utility DLL, or is this a setting you want to update for the installed
application? Is
You need to do more than just reference the property. Did you add a Condition
element, and if so what was the value of the text within it?
-Original Message-
From: Dushyant Bansal [mailto:dushyant.subscr...@gmail.com]
Sent: Monday, November 12, 2012 7:17 PM
To:
Assuming the popular CASE tool uses Windows Installer to install, you should
be able to search for it as a prerequisite. In addition, you should need to ask
the user for the install folder, as you should be able to query the product
state of the main application for its installation directory.
I would suggest starting with WixStdBA. You should be able to configure the
bundle with a few DirectorySearch/FileSearch/RegistrySearch/ProductSearch
elements and then use the InstallCondition to tell the Exe/Msi package to
install and mark it as Permanent so that uninstalling doesn't remove
I have looked at WixStdBA, and I do believe is not accounting for CA progress
updates would cause overlap in the overall progress. I specifically remember
seeing comments in wiutil.cpp:
// HACK!!! this is a hack courtesy of the Windows Installer team.
It seems the script planning
I seem to remember some tidbits in code about burn self-updating.
From http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset,
In WiX v3.7, there is a new option in Burn to plan an update. If your
Bootstrapper Application detects a newer bundle is available, it can tell the
Burn
Is the service which is running the CI builds using the same user account as
you are?
-Original Message-
From: Matt Clarkson [mailto:mattyclark...@gmail.com]
Sent: Thursday, November 22, 2012 10:10 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Running WiX on Windows Server
May not be optimal, but if you can't find out why it is restarting explorer you
could always create a separate MSI for the one shell extension and install them
together with burn as a bundle.
-Original Message-
From: Jeremy Chiu [mailto:green...@gmail.com]
Sent: Wednesday, November 28,
You write logs to appdata because you want a standard user to be able to run a
scan and store logs. Anything the application needs to modify or create at
runtime should be in appdata. In addition, per user installs go to app data
(because a per user install can be done without admin rights).
What he is saying is that the Shorcut tables Name property isn't formatted so
you can't use properties ( []'s ) to change the name of the shortcut at install
time. The only solutions I can think of to get a dynamic shortcut name are:
If you only have a predefined set of possible names, then
If I had to guess, this is a feature missing from the WixNetfxExtension
extension. If you were calling out the Exe installer yourself and assuming the
.Net installer is returning a unique exit code for installed but needs a reboot
then you could add an ExitCode element to the ExePackage.
See MsiPackage/@Visible
-Original Message-
From: Harmon, Joseph [mailto:jhar...@illumina.com]
Sent: Thursday, November 29, 2012 2:33 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX chain issue
Hello,
I am using wix to chain multiple installers together into a bundle. I
Could you not change your product code of your MSI, and enforce this new one is
per machine only? Then with burn, you could detect the previous product code
and uninstall it if found (this would only work if the same user was installing
the per machine as the one who installed it per user). Or
While it may not be optimal, you could use an XSLT to remove the unwanted
elements. If I had to guess, the scom element simply tells heat to use the MSI
Registry table instead of the TypeLib (and related) tables. I seem to remember
a post by Rob and maybe an ICE saying not to use the TypeLib
Hmm, not certain on this but do you really need your BA to be 64 bit? Wouldn't
just the MSI/EXE installation packs need to be x64? Don't you want a single
bundle that would install your application on either an x86 or x64, using the
VersionNT64 in your conditions to decide which subset of
Yes, if you go with burn the desire is to not show any UI from any of the
installers. From what I understand, you have a feature tree in your MSI that
your users can change. In that case, you would need to write a BA to do the
feature tree and then pass in the options via a MsiProperty
Are you using ProgId/Extenstion in your MSI? If so, Windows Installer should
take care of this for you.
To be safe, I think I'd place this inside the InstallExecute sequence after
InstallFinalize. This would ensure your binaries were on disk so any icons for
the new extensions would be
Out of the box WixStdBA doesn't but if you were into doing a custom BA, you
could cache the state from OnDetectComplete. When switching to the success page
(WIXSTDBA_PAGE_SUCCESS) you would then want to hide or show the appropriate
text control based on the previously cached value.
Edit the MSBuild project to pass in the Build as a variable. I believe it was
along the lines of
DefineConstants%(DefineConstants);Build=$(Configuration)/DefineConstants
for both the debug and release sections.
-Original Message-
From: Steven Cramer [mailto:steventcra...@gmail.com]
I don't think that is possible, the MSI is either 32 bit or 64 bit. What you
can do is create two installers from the same Wix source with conditional
defines, then use an external CAB for the binaries and burn to select the
proper MSI based on OS bitness.
-Original Message-
From:
How are you referencing the fragment with your searches that aren't working?
Is it possible you are only referencing them from the .Net bundle?
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Tuesday, January 22, 2013 9:57 AM
To: General discussion for
If I had to guess, removing the fragment and making it part of the main file
will fix it. I normally make my checks inside the same fragment as the
Package. This way if you include the package in the chain you also include
your searches and conditions. I also use a separate file for each to
I've been using Burn and Wix for a bit now and while not a Wix specific issue
I was hoping for some comments from the community.
I currently have a single MSI with ~30k components. During installations and
major upgrades it appears the sheer number of components is causing performance
My guess would be because you are sharing UpgradeCode. When burn runs a second
time, the 32bit MsiPackage is going to detect based on upgrade code. Because
your InstallCondition evaluates to false, it schedules the removal of it.
-Original Message-
From: Karl Werner
the UI on the second run of the bootstrapper.
Thanks!
Karl
On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob
jacob.hoo...@greenheck.com wrote:
My guess would be because you are sharing UpgradeCode. When burn
runs a second time, the 32bit MsiPackage is going to detect based on
upgrade code
Bootstrapper is run a second
time
Since the bootstrapper isn't registering itself in ARP, that shouldn't matter,
right?
On Tue, Jan 29, 2013 at 11:24 AM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:
But if the same component is used in both the 32 bit and 64 bit MSI, a
repair or removal
If the task at hand is simply to update a config file before building a MSI,
this could all be done with MSBuild and could be outside the scope of the
wonderful world of Wix. Also, if this value could change per install or per
customer, then it would be easier to store the base config in the
I believe what you want is a bal:Condition Message=Your message goes here
VersionMsi = 405/bal:Condition instead of a bundle condition.
-Original Message-
From: Eric Potter [mailto:eric.b.pot...@gmail.com]
Sent: Wednesday, January 30, 2013 2:05 PM
To: wix-users@lists.sourceforge.net
I'd see this as a +1 vote for WixStdBA to support a declarative feature tree
dialog. Not a trivial task, but something that would be useful.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Thursday, January 31, 2013 11:05 AM
To: General discussion for Windows
Not today, but you have the source so it would be possible to
contribute it as a feature. I'd envision you needing to describe a tree
structure in XML, and enhancing the existing schema to support it. From there,
adding a page in the BA to build up the tree and display it isn't a
Depending on C:\Windows\system32 would break on non-default installs...
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Monday, February 04, 2013 3:59 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn: Prerequisites on
Another option is to use a second property for the UI state, and then on click
of the next button you assign the value of your property conditionally.
Ex:
In CustomSettingsDlg.wxs:
Control Id=IncomingEmailEnabled Type=CheckBox X=180 Y=60
Width=100 Height=18 Property=IncomingEmailEnabledUI
Where will you be getting your version information from? You could use a
MSBuild task to read it from an ini and set both a MSBuild property and a Wix
Define. If you want the version information to be set via your primary exe you
could look at
I assume you mean how do I invoke an XSLT from heat. The wix specific
portion is simply passing -t transformfilename.xslt. From there on out, it's
all just XSLT.
Here's an identity template to get you started:
?xml version=1.0 encoding=utf-8?
xsl:stylesheet version=1.0
1.
. Because this is a feature on 2008R2, this method fails and says need to
enable the feature to install the framework.
http://blogs.msdn.com/b/sqlblog/archive/2010/01/08/how-to-install-net-framework-3-5-sp1-on-windows-server-2008-r2-environments.aspx
And a previous discussion:
?
Thanks,
Nan
From: Hoover, Jacob
Sent: Tuesday, February 12, 2013 7:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] questions on bootstrapper
1.
. Because this is a feature on 2008R2, this method fails and says need
What service pack is on this XP machine? Is this only an issue with wix, or do
all 3.7 bundles fail? If you view the properties of the wix bundle, is the sig
valid?
Sent from my iPhone
On Feb 16, 2013, at 3:12 PM, Matt Hoover (VSNC) mahoo...@microsoft.com
wrote:
Did the version of .Net that
This smells like a need for a FragmentRef, which I currently work around with a
Property in the fragment and a PropertyRef in the Product to pull in the
fragment. Another possible option may be to reference a component/feature in
your Product, but I haven't done much with wixlib's so I don't
toolset.
Subject: Re: [WiX-users] WixLib not behaving as desired
I've yet to see a case where real content didn't exist in a Fragment that could
be referenced. smile/
On Wed, Feb 20, 2013 at 1:12 PM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:
This smells like a need for a FragmentRef
Are you selecting this location via the BA or the MSI? The best way to do this
would be via the bundle, and pass it into the MSI as a property. That way you
can tell burn to remember the value of the variable for you.
Variable Name=Foo Value=[ProgramFilesFolder]\Bar Persisted=yes/
MsiPackage
for the tip!
/Kristian
2013/2/22 Hoover, Jacob jacob.hoo...@greenheck.com
Are you selecting this location via the BA or the MSI? The best way to
do
this would be via the bundle, and pass it into the MSI as a property.
That way you can tell burn to remember the value of the variable
I've never had to deal with that specific vender, but all of the ones I have
interacted with have had a means of submitting false positives. If you submit
your bundle to them, it usually takes less than a week for them to fix their
problem.
On Feb 26, 2013, at 8:57 AM, Rob Mensching
src\ext\BalExtension\wixstdba for the native BA, and src\Setup\WixBA for the
Wix MBA.
WixStdBA does support localization, but it seems you went about this different
by localizing your MSI instead of the burn way which would be to localize
your BA and remove all of the UI from your MSI's.
In
1) this would be a question for the tomcat people, I can't remember if tomcat
installs once and runs multiple servers but component rules tells me it may
2) if its in process isolation, and #1 is true, then I think this is a non-
issue
3) are you using a ba/burn UI, or are you exposing the msi
: [WiX-users] General disccussion
3) Iam using burn UI(WixUI_installDir)
1) i want to know the bootstrapper working can u tell me code.
how it works
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 27 February 2013 12:14
To: General discussion for Windows
I would assume it would be as easy as adding a MsiProperty element.
MsiProperty Name=TRANSFORMS Value=:[UserLanguageId].mst /
This assumes you have a transform embedded in the MSI for each possible
language. If it's external, remove the : and add a series of Payload
elements to the MsiPackage
MSI (s) (40:34) [10:20:34:506]: PROPERTY CHANGE: Modifying REMOVE property. Its
current value is 'ALL'. Its new value: ' '.
Action start 10:20:34: ResetRemove.
MSI (s) (40:34) [10:20:34:506]: Doing action: FindRelatedProducts
MSI (s) (40:34) [10:20:34:506]: Note: 1: 2205 2: 3: ActionText
Action
Providing an exe to fix a bad uninstall seems lazy/wrong to me. One should ask
for a fixed installer, short of that I can only think of two options. The first
is as you suggested with a stub exe to run the uninstall and then the cleanup
utility. The second option would be to modify the bad msi
Skip the merge module, use burn, and add the two redistributables as
prerequisites. Make the x64 specific redistributable, give it an
InstallCondition of VersionNT64 and a DetectCondition based on a variable you
define with a search.
-Original Message-
From: Jack Sojourn
You didn't clear it, you set it to a space. We're you doing the same in the old
install?
Also, is there a reason you didn't use burn and avoid all of hacks around
nested installs?
On Mar 6, 2013, at 3:44 AM, msporek mspo...@gmail.com wrote:
It is done on purpose, because this MSI is specific
Use ~=
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Wednesday, March 06, 2013 1:24 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How do i convert a global property string value to
uppercase (or lowercase)?
I have a global property that's
Do you need to support multiple instances on the same box?
If yes, you need to look at instance transforms. If no, then property drive the
install using the remember me pattern and conditions on the components for each
instance. If the differences are all config based, you could use ca's to
First hit in most any search engine for remember me property pattern -
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
The MSI will contain all the contents for all of the installs. If that's a
general question of how do you filter out files from a wxs,
I would use a single XSLT which adds component conditions to a single MSI.
Component Id=cmp57960E1EF7499A48186BC46688BF
Directory=dir572C565E70B3AEE6F0C29D3EE9056E9B
Guid={DE230102-74DE-4184-827A-F3044D293FFC}
File Id=fil5C02599F3F58049858209DAC8CDD2935 KeyPath=yes
Use a CA to set the value of the property at runtime right before scheduling
the deferred CA.
You might even be able to assign the property the value of itself so it
evaluates it at runtime.
Deferred CA's are special as they only have access to the limited data you
explicitly send to them
From the documentation...
RegistrySearch Element (Util Extension)
Attributes
Name
Type
Description
Required
Win64
YesNoTypemk:@MSITStore:C:\Program%20Files%20(x86)\WiX%20Toolset%20v3.7\doc\WiX.chm::/html/util_xsd_simple_type_yesnotype.htm
Instructs the search to look in the 64-bit
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] acces hklm from a current user installer
Hi:
I'm not using th util extension--this is just in msi as tandard!
Cheers
Sean.
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 08 March
I wouldn't, simply because some of the difficulties others have reported as
well as introducing another dependency to your installer. A simple C++ CA DLL
can be compiled for a minimal footprint and has no dependencies.
-Original Message-
From: Raghu [mailto:raghu_ti...@yahoo.com]
Sent:
for managed custom action support instead of PowerShell.
I have millions of successful installations logged and failure caused by
DTF are extremely rare in WiX 3.6 / 3.7. In WiX 3.5 there was a bug that
resulted in a 1% failure rate.
From: Hoover
Depending on your upgrade plans, you can have multiple files per
component. If you are always doing major upgrades, this isn't a huge ordeal
(though if any non-key file gets damaged you have to send custom parameters to
msiexec to force it to rewrite all the files). A second option
Certainly an external CAB file or in the case of an Exe installer, whatever the
3rd party vendor deems needed to sit along-side the installer (Ini, Inf, Zip,
Cab, Dat, ...).
-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Monday, March 18, 2013
Just a guess but you aren't initializing your pointer to null. Possibly the
API is trying to free the old string before allocating a new one...
On Mar 20, 2013, at 11:45 AM, Tristen Fielding tfield...@tradestation.com
wrote:
We have a custom action that was working just fine in 3.5, we are
And it's the right way because session.Message shouldn't display a modal
dialog if you are running in a silent mode.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, March 25, 2013 3:43 PM
To: General discussion for Windows Installer XML toolset.
Activation should be done inside your application. Any checks you put into a
MSI can easily be subverted.
-Original Message-
From: Hugh Moran [mailto:hugh.mo...@morantex.com]
Sent: Wednesday, March 27, 2013 5:01 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Activation
It's been my experience that EXE Packages need detect conditions. Also, if you
need the Sentinel package to be there, why not mark it as Vital?
-Original Message-
From: Monitor Vlecad [mailto:monitor.vle...@gmail.com]
Sent: Thursday, March 28, 2013 3:20 AM
To:
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an Install fails to
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
Hiya Jacob,
It's currently the default, which is afterInstallValidate which is even earlier
I think.
Cheers,
Jack
-Original Message-
From: Hoover
Sadly, the API call to create a restore point is blocking and doesn't provide a
callback for status updates. If simply displaying a message on the UI that the
installer is creating a restore point would provide value, a change to WixStdBA
and the engine inside of OnApplyInitialize would have
Oh snap, all my responses were under the impression that he was using Burn. I
now re-read it and realized this was WixUI_Minimal... Different problem domain,
different solutions.
The controls in question are one of these
Control Id=ActionText Type=Text X=70 Y=100 Width=285
: Set your initial text when using the wixstdba on the Progress page and
you'll be able to get essentially what Jacob proposes in in MSI solution.
wixstdba will show the default message until UAC and system restore are all
complete... then packages start.
On Thu, Mar 28, 2013 at 11:35 AM, Hoover
I would use bal:Condition instead of Bundle/@Condition. The bal:Condition
allows you to specify a message, the Bundle/@Condition feels like it is more
designed for when your BA requires something for it to run.
Ex:
bal:Condition Message=Insufficent memory, this install requires a minimum of
I don't do much with managed BA's, but there is a difference between a standard
WPF Exe project and a BA which is a DLL. You might want to have a look at the
Wix BA (src\Setup\WixBA) to see if there is an example to go by there.
-Original Message-
From: Nick Miller
Question,
In your build output folder (Debug or Release), do you have a Views/Styles
sub folder? If so, they are external and need to be referenced by a Payload
with a Payload SourceFile=c:\path\to\file\ButonStyles.xaml
Name=Views\Styles\ButtonStyles.xaml /
If there isn't a subfolder,
MsiPackage/@Compressed = No
-Original Message-
From: Spud [mailto:andysmi...@gmail.com]
Sent: Tuesday, April 09, 2013 10:09 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to create and reference a custom pre-requisite
package
Hi Raj, thanks for your response.
I
I'm struggling to see how you could do this without rebuilding the bundle. Are
you not relying on burn to download missing packages? Are you only using
physical media to deploy your install?
You could always write a stub exe that is bundled that could contain your
custom logic, but
Yes
It is in the documentation. It involves checking in the binaries and modifying
a few project properties. I think WixToolsPath was one of them. I am not at a
computer, so I can't give you more than that.
Sent from my iPhone
On Apr 12, 2013, at 3:51 PM, j2associates j2associa...@yahoo.com
Sounds like your InstallExecute sequence is depending on something in your
InstallUISequence. You could verify this with an install from the command line
passing /qn.
-Original Message-
From: Francisco Leon [mailto:fl...@seguroscatatumbo.com]
Sent: Monday, April 15, 2013 1:01 PM
To:
I would say fix your MSI, If you release a bad one, you need to re-release it
with the same product/upgrade codes (and version), and have the user recache
your updated MSI and then remove it (ala the fixed MSI).
-Original Message-
From: Mr GAPearce [mailto:mr_gapea...@yahoo.com]
Sent:
Burn should only elevate once, and only when it needs to. Since Burn can
install per-user, it won't elevate on initial start of the exe. Your BA should
elevate automatically when *apply* (I believe) happens. The
install/modify/remove button inside your BA should be the ones to have a Shield.
So your resulting file is a MSI? In which case, there is no way of putting a
manifest in it or changing its icon.
If your file is an exe, then you are using some other tool to bundle the MSI
into an exe.
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday,
The Shield icon on the EXE is caused by a manifest change enforcing
that the EXE always runs as admin. There might also be something hokey if it's
named Setup, but I wouldn't expect that to live forever. The reason some
other installer have the shield icon is they took the lazy way out
Exe package logging would be dictated by the Exe. You could try passing /? To
the exe to see what parameters it supports. From there, you can customize the
parameters the bundle passes to the package to get the desired result.
-Original Message-
From: Marco Tognacci
Hmm,
Just a guess but...
InstallCommand=/s /vquot;REBOOT=ReallySupress /qn /l*v
[LogPathVariable]quot;
And then if it fails, what does the bundle log show when it executes your
ExePackage? What is the error code that is returned? It should log all the
options passed to the package so we
Burn would support this, via Payload elements. In 3.8, the current directory is
set to the folder for the payload when the Package is being executed.
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent: Monday, April 22, 2013 1:58 PM
To: wix-users@lists.sourceforge.net
On a 64 bit OS you'd probably want a second search with Win64=yes.
Property Id=EXCELPATH32
RegistrySearch Id=ExcelDirSearch32 Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw
/
/Property
Property Id=EXCELPATH64
RegistrySearch Id=ExcelDirSearch64
there.
From: Hoover, Jacob [jacob.hoo...@greenheck.com]
Sent: Wednesday, April 24, 2013 8:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying
values obtained from registry
On a 64 bit OS
(WIXUI_DONTVALIDATEPATH OR (WIXUI_INSTALLDIR_VALID = 1)) AND NOT (KEYS
SomeString) AND (KEYS OtherString)
Though I am betting should be !=
-Original Message-
From: Philippe Gorley [mailto:gorley.phili...@gmail.com]
Sent: Friday, April 26, 2013 8:51 AM
To:
[05BC:0BF8][2013-04-28T13:03:04]: Detected related package:
{B892ABD4-6B9B-432A-8B31-D849CBEA6969}, scope: PerMachine, version: 7.0.127.0,
language: 0 operation: MajorUpgrade
[05BC:0BF8][2013-04-28T13:03:04]: Detected related package:
{B892ABD4-6B9B-432A-8B31-D849CBEA6969}, scope: PerMachine,
You could harvest them all and use an XSLT to filter them. The command line
heat accepts a -t parameter to transform the output, and the MSBuild task
should have a related property.
-Original Message-
From: chennam [mailto:chatrapathi.chen...@gmail.com]
Sent: Friday, May 03, 2013 9:57
Hmm,
I think I would have one config file and conditionally modify it with CA's
like XmlFile/XmlConfig. I'd also try to eliminate the machine name dependency
and instead use a dev/test/live burn bundle passing a parameter via a
MsiProperty to the installer.
-Original Message-
From:
Have not at all tried this, and it may not work or cause all other kinds of
issues... But judging from
http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx , you could try
prefixing the fully qualified path with \\?\
The Windows API has many functions that also have Unicode versions
The better option is to have one Web.config file and 6 other components
(containing the XmlFile elements) with conditions on them for writing the
appropriate values.
Not that I like the idea, but you could have 6 Components with a Web.config in
each and a Condition element for each component
Are they setting a property within their CA called ConnectionString?
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Monday, May 06, 2013 11:48 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] WiX-users] Hide/blank out
1 - 100 of 707 matches
Mail list logo
