If the transform is to be applied during an installation you must use the
CreateTransformSummaryInfo method to populate the summary information stream.
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Friday, September 02, 2011 1:46 PM
To:
Should I be manually changing the product code of each instance
every time? Or should the base product code be static also? Or ought it not
matter?
Follow the Windows Installer documentation guidelines as for when to change
your PC:
http://msdn.microsoft.com/en-us/library/aa370579(v=VS.85).aspx
Anyone have any idea as to how to go about specifying the position within an
XML document to insert a node, relative to some other node?
SharePoint has a 'wss_minimaltrust.config' file which contains a
firstmatchcodegroup construct (reference
I think this is kind of odd:
?define $(env.TMP)=adsf?
?ifdef $(env.TMP)?
?define foo=Yes?
?else?
?define foo=No?
?endif?
Which compiles just fine.
What I want to be able to do is have the preprocessor condition logic based on
whether or not an environment variable is set.
A launch condition probably should not be used for this. Launch conditions
should be things that verify things at first launch, not at some pre-determined
time well into the installation UI.
You could use a Custom Action to accomplish this, or perhaps better yet, just
hide the feature
Here's the key point from the SDK:
* To keep the nonfile data of each instance isolated, the base package
should collect nonfile data into sets of components for each instance. The
appropriate components should then be installed based on conditional
statements that depend on the instance
Regarding properties from the UI not retaining their values into the execute
sequence, look into 'SecureCustomProperties', ref:
http://msdn.microsoft.com/en-us/library/aa371571(VS.85).aspx
-Original Message-
From: David Drake (Excell Data Corporation) [mailto:a-ddr...@microsoft.com]
there and the file is then
written as expected).
The concept you'll want to look up here is transitive components.
Reference: http://msdn.microsoft.com/en-us/library/aa372462(VS.85).aspx
-Original Message-
From: John Nannenga
Sent: Thursday, November 05, 2009 5:00 PM
To: 'General discussion
It's important to keep in mind the DTF (for the most part) provides a managed
interop around the windows installer APIs. You'll still need to become
intimately familiar with [
http://msdn.microsoft.com/en-us/library/aa368786(VS.85).aspx ] and how to
handle all the messages and compute the
Not sure of the terminology here, but if your checks are in the LaunchCondition
table, they execute in an indeterminate order:
Ref: http://msdn.microsoft.com/en-us/library/aa369752(VS.85).aspx
Specifically,
You cannot guarantee the order in which the launch conditions are
evaluated by
You likely don't need your own CA for this, check out XmlConfig or XmlFile.
Your problem here is likely that you get a FileNotFoundException or something
similar which is due to the fact you have your CA scheduled to execute in the
immediate sequence and scheduled after InstallFiles which
Take a peek at CurrentSession.GetMode, passing it what you're interested in
detecting. InstallRunMode.Scheduled I believe is 'deferred',
InstallRunMode.Commit is commit, etc...
For immediate I use InstallRunMode.Operations || InstallRunMode.Maintenance.
-Original Message-
From: Tom
...\wix\src\ext\NetFxExtension\wixlib\NetFxExtension.wxs
-Original Message-
From: Lloyd Dupont [mailto:l...@galador.net]
Sent: Monday, June 22, 2009 6:14 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixNetFxExtension / how to check for .NET 3.5
for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX compiler extension and WiX Lib...
John Nannenga wrote:
Found my issue and resolved it...
What was the root cause?
--
sig://boB
http://joyofsetup.com
Howdy folks;
I'm building a WiX compiler extension. I've over-ridden
WixExtension::GetLibrary to return my custom built WiX Lib.
My WiX Lib has the following in it:
Fragment
Binary Id=blah SourceFile=C:\Blah.dll/
/Fragment
When I
Found my issue and resolved it...
Cheers...
From: John Nannenga [john.nanne...@microsoft.com]
Sent: Tuesday, April 28, 2009 2:18 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX compiler extension and WiX Lib
Reference this:
http://msdn.microsoft.com/en-us/library/aa371662(VS.85).aspx
and probably this... INSTALLLEVEL:
http://msdn.microsoft.com/en-us/library/aa369536(VS.85).aspx
Standard disclaimer for authoring VBScript custom actions /
From:
Reference the TerminalServerAware attribute of the CustomAction element in
the WiX help.
TerminalServerAware YesNoType This attribute specifies controls whether the
custom action will impersonate the installing user during per-machine installs
on Terminal Server machines. Deferred execution
Presuming we're all talking about the basic UI dialog...
UI
Error Id='16' Time remaining: {[1] minutes }{[2]
seconds}/Error !--Time remaining string --
Error Id='20'Product Name is being configured on your
computer.Error !--Dialog 'top text' --
/UI
According to the Feature Table in the SDK:
http://msdn.microsoft.com/en-us/library/aa368585(VS.85).aspx
Neither Title or Description are format-able fields
-Original Message-
From: Jon Drnek [mailto:jon.dr...@vibrationresearch.com]
Sent: Wednesday, March 25, 2009 9:45 AM
To:
Take a look at configurable merge modules in the SDK...
http://msdn.microsoft.com/en-us/library/aa368027(VS.85).aspx
From: Reuss, Matthias [matthias.mr.re...@siemens.com]
Sent: Monday, March 23, 2009 10:25 AM
To: General discussion for Windows Installer
Quick question...should this work after the product is installed i.e., in
maintenance mode or even in a patch?
A quick implementation we've messed with results in a read only session object
in these situations; before we get heavy into looking into this, wanted to see
if you knew off the top
Take a peek at the Preprocessor section in the WiX.chm file. It has all
sorts of information in this regard, complete with examples.
-Original Message-
From: sandun css [mailto:sandun...@gmail.com]
Sent: Wednesday, February 25, 2009 2:59 AM
To: wix-users@lists.sourceforge.net
Subject:
Your CA isn't running because although you've defined the custom action within
Product.wxs you haven't scheduled it for execution (you have no sequences
defined which would invoke your CA).
For example...
.
.
.
InstallExecuteSequence
Custom Action=TestManagedAction
Ref: http://msdn.microsoft.com/en-us/library/aa368060(VS.85).aspx
-- SDK documentation pertaining to this issue.
Where the rubber then meets the road [within WiX] is within your directory
elements...if you have any file additions / removals within your directory
table, that impacts file
in any recogniaseable way, they're
just predictably randomly different from each other.
John Nannenga wrote:
Ref: http://msdn.microsoft.com/en-us/library/aa368060(VS.85).aspx
-- SDK documentation pertaining to this issue.
Where the rubber then meets the road [within WiX] is within your
You can control the progress bar via messaging...
Reference: http://msdn.microsoft.com/en-us/library/aa371672(VS.85).aspx
Use a message type of msiMessageTypeProgress and fill out the record
information as documented for what you want to accomplish.
-Original Message-
From: Neil
DateAdd returns a date, Session.Property must take a string, hence the type
mismatch error you were likely receiving.
Try this instead... Use FormatDateTime to convert your date object...
CustomAction Id=CalcOldDate Script=vbscript
SUB CalcMigratorDate
Session.Property(OLDDATE)
The condition of NOT Installed means do this if the product is not
installed.
In maintenance mode the product is installed and upgrading isn't normally
relevant to maintenance mode; so this constraint keeps your CA from running.
standard disclaimer about using CAs / SelfReg / etc... to
Reference:
http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx#configuration_properties
'ComputerName' will get you, well, the computer name.
Full name of the machine, I've normally gone after that with a CA of sort...
-Original Message-
From: sandun css
Same thing works in WiX, only it's XML so you have to use amp; instead of
.
Control Id='Next' Type='PushButton' X='320' Y='243' Width='60' Height='18'
Default='yes'
Textamp;Next/Text
/Control
Alt+N would then be the accelerator for the Next button.
-Original Message-
From:
Corrected my type-o on the Text element below... had a quote in there that
didn't belong...
-Original Message-
From: John Nannenga [mailto:john.nanne...@microsoft.com]
Sent: Monday, February 23, 2009 11:38 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] update Hotkeys
Try this:
[CustomAction]
public static ActionResult DisplayMessageBox(Session session)
{
session.Log(Begin CustomAction1);
Record rd = new Record(2);
rd.SetString(0, [1] [2]);
rd.SetString(1, John Nannenga
What happens when the data value you need contains what appears to be the
delimiter between independent properties within the CustomActionData class?
semi-colon...
-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org]
Sent: Tuesday, February 17, 2009 10:52 PM
To:
I leave the upgrade code the same for all instances. I have a dialog asking
the user whether they'd like to upgrade an existing instance, or install a new
instance (only if an existing instance is detected).
If the user selects to upgrade an existing instance, I store the product code
of that
If memory serves me correctly (from last August), the issue here lies in the
MakeSfxCA processing. It only writes the Embedded UI entry points if there are
no CAs included in the project.
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
I'm working on deployment of a managed Word Add-in. Managed Word Add-Ins in
Office 2007 are registered under the HKCU registry hive, hence I'm creating a
per-user installation.
My question is regarding the HKCU registry keys-they are not being removed
during product uninstallation...
I figured it out. It was classic user error. Crap/
-Original Message-
From: John Nannenga [mailto:john.nanne...@microsoft.com]
Sent: Tuesday, February 17, 2009 4:54 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Per user installation HKCU registry keys remain after
un
In your patch generation you need to target the patch for all the product codes
[instances] you want it to be applicable to.
TargetProductCode Id=PRODUCT_CODE_GUID/
TargetProductCode Id=PRODUCT_CODE_GUID_INSTANCE1/
TargetProductCode Id=PRODUCT_CODE_GUID_INSTANCE2/
Etc...
From: Matt Ziegler
Use a configurable merge module.
Ref: http://msdn.microsoft.com/en-us/library/aa368027(VS.85).aspx
From: Castro, Edwin (Hillsboro) [EMAIL PROTECTED]
Sent: Thursday, November 13, 2008 1:56 PM
To: General discussion for Windows Installer XML toolset.
Reference:
http://msdn.microsoft.com/en-us/library/aa369786(VS.85).aspx
From: Joshua Chambers [EMAIL PROTECTED]
Sent: Monday, September 29, 2008 6:19 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] old installer running?!
Hello!
When I
Is this change not compatible with the List of Supported Project References?
Before this change, I had a reference in my MSI WiX project to a merge module
WiX project. I then referred to the built merge module via
$(var.ProjectName.TargetPath). This worked just peachy, until this change
-users] what setting causes current wix build output to land
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used
to land
Yes, that looks like it won't work. Can you log a bug on this in SourceForge?
Neil
-Original Message-
From: John Nannenga [mailto:[EMAIL
: John Nannenga [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 1:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used
One way would be to use Dark against your built deliverable.
WiXCop is documented to take WiX 2.0 to WiX 3.0...
http://www.wixwiki.com/index.php?title=WixCop
WiX 1.0 was so long ago (for me), I can't remember much about it... :)
From: [EMAIL
There's the MsiSetProperty API Ref:
http://msdn.microsoft.com/en-us/library/aa370391(VS.85).aspx
Or, if you're doing this from a native windows installer UI sequence, through
WiX, you'd make use of the Publish element.
Example:
Publish Property='PropertyName'
Reference:
http://robmensching.com/blog/archive/2007/09/03/Windows-Installer-4.5-and-the-WiX-toolset.aspx
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: Monday, September 15, 2008 7:53 AM
To: wix-users@lists.sourceforge.net
Subject:
FindRelatedProducts, Ref:
http://msdn.microsoft.com/en-us/library/aa368600(VS.85).aspx only runs the
first time the product is installed. Hence, I do not believe it is relevant
for a small update or a minor upgrade.
You can verify this in your scenario by capturing a verbose log file /l*v
Found the MSIPATCHREMOVE property... Ref:
http://msdn.microsoft.com/en-us/library/aa370348(VS.85).aspx
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Monday, September 15, 2008 1:03 PM
To: 'General discussion for Windows Installer
You may also be able to make use of the following properties:
http://msdn.microsoft.com/en-us/library/aa367536(VS.85).aspx
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Pally Sandher [EMAIL
PROTECTED]
Sent: Thursday, September 11, 2008
for your help,
wondering if you know where I can find information on amending the condition
so it only fires on install and not on install.
regards
Derekj
John Nannenga wrote:
Launch conditions fire when the condition is false:
http://msdn.microsoft.com/en-us/library/aa369752.aspx
FindRelatedProducts:
http://msdn.microsoft.com/en-us/library/aa368600(VS.85).aspx ... only runs the
first time the product is installed. As so, I don't believe it executes during
a patch scenario (so it wouldn't be relevant).
That is also documented as being true for RemoveExistingProducts
and in the case of custom actions I've have the correct install pass only
feature component state conditions in place. Is that a correct assumption.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Thursday, September 11, 2008 1:18 PM
Launch conditions fire when the condition is false:
http://msdn.microsoft.com/en-us/library/aa369752.aspx
The property you likely mean to use is Installed, not INSTALLED.
http://msdn.microsoft.com/en-us/library/aa369297(VS.85).aspx
From: [EMAIL
for this to work. Is that
only for the case of applying a minor upgrade using a My Deliverable
Small Update or Minor Upgrade.msi approach to update an existing
install?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Nannenga
Sent: Tuesday, September 09
.vcproj references are not supported. Reference the recent thread (last
monday) w/Subject : Add reference to setup project in Visual Studio 2008.
Essentially Justin R notes, Unfortunately .vcproj references aren't supported
because they're not MSBuild compliant. There is a feature request out
In our installs, we don't utilize a patch wrapper.
Instead, we set the REINSTALL and REINSTALLMODES appropriately within our
installation(s)...
CustomAction Id='Patch_SetReinstall'
Property='REINSTALL'Value='ALL'/
CustomAction
How are your features configured?
Pay particular attention to the Feature.Directory_ column of the Feature
table...
ref: http://msdn.microsoft.com/en-us/library/aa368585(VS.85).aspx
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Alvin Moser
upgrade using a My Deliverable Small Update or Minor
Upgrade.msi approach to update an existing install?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Tuesday, September 09, 2008 7:32 AM
To: General discussion for Windows Installer
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Saturday, August 23, 2008 12:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Anybody know how to use EmbeddedUI?
I've spent a bunch of time lately regarding UI handlers, including embedded
UI
I've spent a bunch of time lately regarding UI handlers, including embedded UI.
Where can I be of assistance (did you have particular questions I might
answer)?
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Andrew Crum [EMAIL
PROTECTED]
Sent:
Here's a creative approach:
You could use an external UI handler to assist you in unit testing deferred
custom actions. You can still create the MSI etc... like documented on
code.dblock.org; but instead of actually invoking the custom actions yourself,
fire off the install and process the
If folks are looking for some good information regarding patching, you might
try the following:
The Windows Installer 3.0 Patching white paper (an excellent resource):
http://www.microsoft.com/downloads/details.aspx?FamilyID=ad7ac91e-2493-4549-ae6f-bf5e007c12a3DisplayLang=en
Heath
You've got a ton of options available to you; since I don't know the details of
your installation, I'll try to give you a couple options (pick one [or
something similar, or perhaps a hybrid] that makes the most sense for your
situation). If none of the below work for you, holler and I'll try
I believe REINSTALLMODE comes into play here.
Ref: http://msdn.microsoft.com/en-us/library/aa371182(VS.85).aspx
So, in your first post, you had a non-transitive component installing a
registry key conditioned on NOT PATCH. Assuming your installation wasn't
slipstreaming (applying a
I, personally, absolutely love WiX v3. I have a bunch of installations built
with WiX v2; I took a couple of 'em and moved them over to WiX v3 (with very
little problems, I might add).
Moreover, a bunch of the features within WiX v3 actually saved me time and when
I re-factored, was able to
Custom4 runs during the install because your condition is Not Installed.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Moore
Sent: Wednesday, August 06, 2008 2:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Actions
I'm
Where is your RemoveExistingProducts action scheduled?
Ref: http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jim Flood [EMAIL
PROTECTED]
Sent: Wednesday, August 06, 2008 4:26 PM
To:
Of Bob Arnson
Sent: Monday, July 28, 2008 11:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] EmbeddedUIResource
John Nannenga wrote:
We're building a .NET based embedded UI for Windows Installer 4.5. While the
SDK for windows installer implies more than
XML toolset.
Subject: Re: [WiX-users] EmbeddedUIResource
Bug in the XSD. Compiler would support it if you suppress schema validation.
Mind opening a bug on it? It'll be easy to fix.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent
We're building a .NET based embedded UI for Windows Installer 4.5. While the
SDK for windows installer implies more than one resource DLL can be included in
the MsiEmbeddedUI table (though only one primary DLL), the wix schema doesn't
allow more than one EmbeddedUIResource element under the
http://blogs.msdn.com/heaths/archive/2006/02/14/532200.aspx
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Powell, Simon
Sent: Friday, July 25, 2008 4:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Extract files
] Extract files from an MSP
Is it possible using DTF?
Regards
Simon Powell
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Nannenga
Sent: 25 July 2008 15:03
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Extract files
Ideally, the MSI would un-install itself after it finished creating the
database.
This might be off topic, but curiosity got the best of me; given that to be the
case, why would this be in an MSI at all?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
this as an alternative to the DOS
batch script I used in the previous version of our software.
On Wed, Jul 23, 2008 at 10:14 AM, John Nannenga [EMAIL PROTECTED]
wrote:
Ideally, the MSI would un-install itself after it finished creating the
database.
This might be off topic, but curiosity
Your rollback script will only be invoked if failure was realized after your
rollback script was scheduled.
Bear in mind, the Immediate vs. Deferred execution context. Rollback happens
only in the deferred sequence.
So, is your failure that you fake in the deferred sequence after
is different from one Component to the next.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe
FRIGGEN
is identical then you shouldn't put them in different Components.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, July 18, 2008 07:31
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances
.
John Nannenga wrote:
Well, below is a really stupid example, but illustrates the behavior
(refer to WiX code snippets below).
Both installations install a single file and a single registry key. The
file components have the same Component GUID, but are installed to a
different file system
You can use a custom action to prompt for credentials. Condition the custom
action to fire if the property values you need are not already set, tie it to a
component / other action that requires the property values, and be mindful of
the UILevel.
-Original Message-
From: [EMAIL
I believe component ref-counting for file based data is handled at the product
code and location level. That's why Chad see's the results he does for the
below situation regarding the web.config file.
Component ref-counting for non-file based data (registry information, ini keys,
shortcuts,
Looking for some advice:
I need to support multiple instances of my product installation (for sake of
discussion, let's just say 50 of the suckers).
Regarding all non-file data, I've authored separate components and conditioned
their installation based upon an internal instance name property:
] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 14:28
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Instances and Torch.exe
Looking for some advice:
I need to support multiple instances of my product installation (for sake of
discussion, let's
is using the same name but is not
backwards compatible the GUID's should not be matched. In many cases only
the dev will know this information.
John Nannenga wrote:
I believe component ref-counting for file based data is handled at the
product code and location level. That's why Chad see's
Well, below is a really stupid example, but illustrates the behavior (refer to
WiX code snippets below).
Both installations install a single file and a single registry key. The file
components have the same Component GUID, but are installed to a different file
system location. The registry
installer used with Windows installer)
in relation to the non file components are you referring to non file keypath
or components which simply contain additional resources but maintain a file
keypath ?
regards,
John
John Nannenga wrote:
OK, what would the recommended approach be for non-file
Runtime Environment?
In contrast to, for example, the dot-net runtime, the JRE works fine when an
installed JRE directory is just *copied* to a new machine (without invoking
an installer which adds a myriad of registry keys and fully integrates into
the target machine).
--
Tom
John Nannenga
Here's some example code (this was WiX v2) for configurable merge modules:
In the merge module (foo.msm) = module GUID =
03A6BA5C-D324-4BB6-9109-35DCAFA943FE:
!-- MODULE INTERFACE PROPERTIES --
Configuration
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 [EMAIL
PROTECTED]
Sent: Wednesday, July 09, 2008 10:53 AM
To: General discussion for Windows Installer XML toolset.
Subject
pretty hard and
nearly impossible :(
Can you add this as a feature request on Source Forge?
http://sourceforge.net/tracker/?group_id=105970atid=642717
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of John Nannenga [EMAIL
PROTECTED]
Sent: Thursday, July
With regards to patches, I've encountered some folks / standards that don't
like patch wrappers. So if you don't want a patch wrapper AND you don't want
to force users to install your patch via the command line, here's a trick you
might find useful...
1) Author a property setting custom
This seems a little odd, but what the heck, I'll bite.
However, since I don't know anything about the Java Runtime Environment, I need
more info. How does your application installation (the one with JRE) deploy
the JRE? Merge modules? Components you authored yourself into your package?
MSI
to, for example, the dot-net runtime, the JRE works fine when an
installed JRE directory is just *copied* to a new machine (without invoking
an installer which adds a myriad of registry keys and fully integrates into
the target machine).
--
Tom
John Nannenga wrote:
This seems a little odd, but what the heck
Is there a way to suppress a specific instance of a light.exe warning?
For example, I'm consuming some VBA 6.4 merge modules where they incorrectly
authored a DefaultDir of SOURCEDIR for the Directory of TARGETDIR. When
including this module into my WiX v3.0 installation that has a DefaultDir
I'm trying to 'ADD' [to existing permissions] an explicit deny permission on
BUILTIN\Users for Traverse Folder / Execute File, for Subfolders and files
only.
I'll spare you all the gory details of what I've all tried [Permission and the
util:PermissionEx elements (from within a CreateFolder
/custom action so it can be
extended...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 09, 2008 13:53
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Explicit Deny permissions
I'm trying
2 big benefits I can think of:
1) Machine maintenance
If you have 5 build machines, you don't have to update WiX on all 5 of
the build machines. The synch process pulls down the appropriate WiX version
during the build process.
2) Large projects that share Build machines don't need
Another option is to create a transitive component to remove the non-versioned
file. [The RemoveFiles action runs prior to the InstallFiles action]
An advantage here is that you can condition the transitive component to only
force-spank the file when you want it to be spanked (depending on
From the windows installer SDK:
http://msdn.microsoft.com/en-us/library/aa371847(VS.85).aspx
The `Shortcut`.`Name` field is not a formatted field.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Hellwig
Sent: Tuesday, July 01, 2008 8:54 AM
is running as worked, but when running through the
service it didn't.
This is working for me now, Team Build is reporting the warnings, etc...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Monday, June 30, 2008 12:56 PM
To: 'Brian Rogers
1 - 100 of 106 matches
Mail list logo
