Re: [WiX-users] Burn and Msi logging revisited

[Rob Mensching]

1. The mba (Managed Bootstrapper Application) can install the .NET
Framework *before* your managed BA comes up. That's actually howthe WiX
toolset works. Install it on a machine with out .NET Framework and it will
first install .NET Framework then launch the custom BA.

However, I must say, I don't understand the scenario. Why are you so
worried about losing the installation log files if someone runs Disk
Cleanup Wizard? Presumably if something goes wrong during the install, one
would get the logs right away

2a. If you remove those, then you get what Burn provides by default. That
is why we picked that. 

2b. True, all the way the round and that is why we support the logging
policy.


On Fri, Jun 15, 2012 at 12:50 PM, Don Walker wrote:

> In reply to Rob's points:
>
> 1. I knew about the Burn log file Variables and link on the failure page.
> Since I'm new to both Windows Installer and WiX, I was hoping to avoid the
> need to write my own bootstrapper just to control logging. I may be
> installing to XP machines without .Net installed so I wouldn't even be able
> to write a managed bootstrapper. While I still occasionally program in C++,
> it is no longer my top choice for this sort of thing. Is there any
> possibility that this functionality could be added to the standard
> bootstrapper? If not, is wix36-sources\src\ext\BalExtension\wixstdba the
> place to start for writing my own?
>
> You're right about the Bundle log file name being self-explanatory. The
> problem with TEMP is that someone may run Disk Cleanup or remove log files
> files using some other maintenance tools.
>
> 2a. The tips about "!" and "x" are helpful. I'll remove both of them.
>
> 2b. Since the installs are being done on customer machines by their own IT
> people, requiring a certain logging policy would be considered intrusive
> unless there was a serious emergency. The best I can hope for is a logging
> solution that will work with most logging policy settings, including the
> default.
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7578878.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Sets of files installed at different times.

[Castro, Edwin G. (Hillsboro)]

I've seen many installers by others where their bootstrapper installs 
"installation tools" before the real installer begins to execute so I think 
this kind of approach certainly has a lot of precedence already.

I have not personally used burn so I'm not much help myself. If I was going to 
start I would look here, 
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm, first. The 
consensus on the mailing list is that the documentation for burn is still 
lacking quite a bit so you might need to ask others here for help as you 
explore using burn.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail



> -Original Message-
> From: Dan Muller [mailto:dmuller...@comcast.net]
> Sent: Friday, June 15, 2012 1:08 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Sets of files installed at different times.
> 
> Thank you for your in depth response. Since reading your post we have
> looked in to burn, and have a few questions that we hope someone could
> answer.
> 
> An idea that is being thrown around is that of a first MSI that would lay down
> the necessary files in the form of perl scripts, and a second that would 
> install
> the actual program.
> 
> It doesn't seem that burn.exe is currently in my Program Files folder, so
> where would I be able to get it, and where could I find any sort of docs on 
> it?
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Sets-of-files-installed-at-different-times-
> tp7578867p7578879.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Extracting embedded packages from the standard bootstrapper

[Don Walker]

I've submitted feature request #3535563.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Extracting-embedded-packages-from-the-standard-bootstrapper-tp7578806p7578880.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Sets of files installed at different times.

[Dan Muller]

Thank you for your in depth response. Since reading your post we have looked
in to burn, and have a few questions that we hope someone could answer. 

An idea that is being thrown around is that of a first MSI that would lay
down the necessary files in the form of perl scripts, and a second that
would install the actual program. 

It doesn't seem that burn.exe is currently in my Program Files folder, so
where would I be able to get it, and where could I find any sort of docs on
it?

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Sets-of-files-installed-at-different-times-tp7578867p7578879.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn and Msi logging revisited

[Don Walker]

In reply to Rob's points:

1. I knew about the Burn log file Variables and link on the failure page.
Since I'm new to both Windows Installer and WiX, I was hoping to avoid the
need to write my own bootstrapper just to control logging. I may be
installing to XP machines without .Net installed so I wouldn't even be able
to write a managed bootstrapper. While I still occasionally program in C++,
it is no longer my top choice for this sort of thing. Is there any
possibility that this functionality could be added to the standard
bootstrapper? If not, is wix36-sources\src\ext\BalExtension\wixstdba the
place to start for writing my own?

You're right about the Bundle log file name being self-explanatory. The
problem with TEMP is that someone may run Disk Cleanup or remove log files
files using some other maintenance tools.

2a. The tips about "!" and "x" are helpful. I'll remove both of them.

2b. Since the installs are being done on customer machines by their own IT
people, requiring a certain logging policy would be considered intrusive
unless there was a serious emergency. The best I can hope for is a logging
solution that will work with most logging policy settings, including the
default.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-Msi-logging-revisited-tp7578871p7578878.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Installer 3.1 or 4.5 for XP?

[Rob Mensching]

The current released versions of WiX will always support all the curent
versions of Windows Installer. 

Looking forward, the only reason I can imagine that we'd move the minimum
supported Windows Installer in the WiX toolset is if we cut support for old
OSs. In the coming months through next couple years, Windows XP (all SPs)
and Windows 2003 (all SPs) will be out of service.  At some point we cut
our tail and quit bending over backwards (mixing metaphors, I know) to
support "dead operating systems".  Of course, customer demand makes that a
challenging line to walk.  I'm walking it right now. Feedback (be
constructive and try to be kind ) is welcome.

And quite honestly, based on the usage numbers that I've seen, when cutting
the tail we may just move to Win7/Win2k8R2.  That provides a lot of freedom
and reduced overhead. However, customer demand probably makes this just a
pipe dream for me. 


On Thu, Jun 14, 2012 at 11:00 AM, Don Walker wrote:

> Thanks for letting me know that WiX will work well with Windows Installer
> 3.1
> and there are no current plans to change this. Now all I have to decide is
> whether I need features from Windows Installer 4.5 for my custom actions.
>
> Would you care to speculate if you ever plan to require a newer version of
> Windows Installer  in WiX?
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-Installer-3-1-or-4-5-for-XP-tp7578785p7578826.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Extracting embedded packages from the standard bootstrapper

[Rob Mensching]

Yeah, that's not supported in Burn today. Could file a feature request for
a future version.
On Thu, Jun 14, 2012 at 11:19 AM, Don Walker wrote:

> dark can be used as described. However, my customers don't have WiX
> installed
> and may not have .Net - I am under the impression that dark uses .Net. What
> I'm looking for is to give them a single file. If they want access to the
> embedded packages I would like to be able to tell them to just run the file
> with the appropriate command line parameter (/x or whatever). When you're
> supporting a number of customers it is good to keep things as simple as
> possible.
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Extracting-embedded-packages-from-the-standard-bootstrapper-tp7578806p7578827.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn and Msi logging revisited

[Rob Mensching]

1. Burn provides Variables to the paths to all log files, including it's
own log file. For example, the wixstdba code uses the Variable to provide a
link on the failure page. Your BA could do other things.

Note: the log filenames from a Bundle are designed to be pretty
self-explanatory and are stored in a safe location in%TEMP% that persists
across reboots. You may be trying to do something more.

2a. The "!" just makes Windows Installer really slow and the "x" is really
only interesting for debugging patch issues. The user can set "x" via the
command-line to Burn but I don't think a BA can set it. I haven't tried.

2b. Burn should respect the "x" if it is in the logging policy so logging
policy may work.


On Fri, Jun 15, 2012 at 11:40 AM, Don Walker wrote:

> I've found a number of topics about log file location and some topics
> about logging detail levels by searching the mail list and the bug tracker.
> I still don't know how to get logging working the way I want so here we go
> again.
>
> The Windows Installer properties that interact with logging are
> MsiLogFileLocation and MsiLogging. They can be used to configure logging
> the way I want for Msi files run directly from Windows Installer. The main
> problem I have with using these properties is that they are only supported
> in Windows Installer 4.0 and up. This would require upgrading all of my
> Windows XP customers to Windows Installer 4.5. A detailed discussion of the
> configuration issues follows. The question that applies to the entire
> discussion is:
>
> Is there any way to do this without Windows Installer 4.5 or newer?
>
> 1. Log file location - It is important for support purposes that log files
> from failed installs be saved to known safe locations. The TEMP directory
> is not a safe location. The standard msi log file name is meaningless. The
> IT guys I deal with may be calling me for support several days after they
> encountered the problem. I've implemented custom actions that copy the Msi
> log file to a known safe (and clearly named) location if the install fails
> or is cancelled. This works both when the msi is run directly or when it is
> run as part of a bundle. The log file that I don't have any solution for is
> the Burn bundle log.
>
> Is there any way to copy the bundle log when a bundle fails? Changing the
> location would work as well.
>
> 2. Since I'm currently a beginner with Windows Installer I have my log
> level detail set to "voicewarmupx!" by setting the MsiLogging property.
> This works when I run the msi directly. When I run it as part of a bundle
> Burn is overriding my detail setting with its own. I would like to see one
> of the following:
>
> a) being able to set the log level detail from the bootstrapper or
>
> b) being able to stop Burn from overriding my MsiLogging setting
>
> Comments and suggestions will be appreciated.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.6 Burn MsiPackage Basic Quesiton

[Rob Mensching]

The way to implement this is to download a new Bundle. The WiX toolset's
install basically does this via the "Check Updates" tile in the bottom
left. We don't automatically get the latest in the WiX toolset's install
but could have...

On Fri, Jun 15, 2012 at 10:40 AM, yojam  wrote:

> We have a similar requirement in order to download latest versions (hosted
> in
> DownloadURL) and we cannot redistribute the bundle installer (will be
> pre-installed on certain platforms).
> Would it be possible to change this hash/file validation by implementing a
> custom Boostrapper Application?
>
> Thanks,
> Jose
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-6-Burn-MsiPackage-Basic-Quesiton-tp6294854p7578870.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper UpgradeCode

[Rob Mensching]

I need to write the blog entry about this. Bundles are registered on the
machine. Bundles can be uninstalled, manage the package cache and they
reference count their packages. Basically, they do everything in their
power to help create a "unified installation experience for a set of
packages". Looking back (and this is the part I want to reflect on in the
to-be-written blog entry) "bootstrapper" probably oversimplifies what Burn
provides.

As such, a higher version Bundle upgrades lower version Bundles with the
same UpgradeCode or RelatedBundle of type "upgrade". UpgradeCode is really
just a (required) shortcut to define a RelatedBundle. RelatedBundles are
wicked cool concepts that are not at all well documented yet... another
blog post or three. 
Hopefully that provides a bit more background to make things less confusing.
On Thu, Jun 14, 2012 at 2:59 PM, Patrick Earl  wrote:

> What's the UpgradeCode for on Bundles?  I understand that in Products it
> searches for any existing products with the same upgrade code and removes
> them when installing the new one.  I don't see how having an UpgradeCode on
> the bootstrapper is relevant, since it doesn't get installed.
>
> In other words, what would happen if I just gave all my bootstrappers the
> same GUID for the upgrade code?
>
> Confused,
>
>Patrick Earl
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Burn and Msi logging revisited

[Don Walker]

I've found a number of topics about log file location and some topics about 
logging detail levels by searching the mail list and the bug tracker. I still 
don't know how to get logging working the way I want so here we go again.

The Windows Installer properties that interact with logging are 
MsiLogFileLocation and MsiLogging. They can be used to configure logging the 
way I want for Msi files run directly from Windows Installer. The main problem 
I have with using these properties is that they are only supported in Windows 
Installer 4.0 and up. This would require upgrading all of my Windows XP 
customers to Windows Installer 4.5. A detailed discussion of the configuration 
issues follows. The question that applies to the entire discussion is:

Is there any way to do this without Windows Installer 4.5 or newer?

1. Log file location - It is important for support purposes that log files from 
failed installs be saved to known safe locations. The TEMP directory is not a 
safe location. The standard msi log file name is meaningless. The IT guys I 
deal with may be calling me for support several days after they encountered the 
problem. I've implemented custom actions that copy the Msi log file to a known 
safe (and clearly named) location if the install fails or is cancelled. This 
works both when the msi is run directly or when it is run as part of a bundle. 
The log file that I don't have any solution for is the Burn bundle log.

Is there any way to copy the bundle log when a bundle fails? Changing the 
location would work as well.

2. Since I'm currently a beginner with Windows Installer I have my log level 
detail set to "voicewarmupx!" by setting the MsiLogging property. This works 
when I run the msi directly. When I run it as part of a bundle Burn is 
overriding my detail setting with its own. I would like to see one of the 
following:

a) being able to set the log level detail from the bootstrapper or

b) being able to stop Burn from overriding my MsiLogging setting

Comments and suggestions will be appreciated.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.6 Burn MsiPackage Basic Quesiton

[yojam]

We have a similar requirement in order to download latest versions (hosted in
DownloadURL) and we cannot redistribute the bundle installer (will be
pre-installed on certain platforms).
Would it be possible to change this hash/file validation by implementing a
custom Boostrapper Application?

Thanks,
Jose

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-6-Burn-MsiPackage-Basic-Quesiton-tp6294854p7578870.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Help with localized file locations

[Frank Jenner]

In my install source hierarchy, I have different localized versions of
files in different directories. So far, I have something that looks like
this:

[Install.wxs]
...



...

[Resources_en-us.wxl]

http://schemas.microsoft.com/wix/2006/localization";>
1033
MySourceFiles\documentation\en\Welcome.txt


[Resources_es-es.wxl]

http://schemas.microsoft.com/wix/2006/localization";>
1034
MySourceFiles\documentation\es\Bienvenido.txt


etc.

Unfortunately, when I run light.exe, I get the following errors for any
files that attempt to use a localized string in the Source attribute:

error LGHT0204 : ICE03: Invalid Filename; Table: File, Column: FileName,
Key(s): welcome.txt

If I look at the Files table, it seems that the non-localized files (which
have a hard-coded Source attribute) have their leading path information
(for example, MySourceFiles\documentation\) stripped off, whereas the
localized files contain the leading path information. This extra path
information in the Files table, presumably, accounts for the error. I'm
guessing that candle.exe handled the path information such that, when the
language strings are resolved from the localization files in light.exe, it
is too late for localized files to get the same treatment.

That said, what is the correct way add localized files?
___
Frank Jenner
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Sets of files installed at different times.

[Castro, Edwin G. (Hillsboro)]

Windows Installer uses a declarative language (implemented in an embedded 
database) to describe the end state of the system. This means that all files in 
selected components are installed at the same conceptual time in no specific 
order. Components can have Conditions that decide whether the component will be 
selected (assuming its parent Feature has already been selected). Perhaps one 
way to do this would be to construct Component Conditions such that they use 
the value of a Property (or Properties as the case might be) whose value is set 
by an immediate CustomAction you execute before the InstallFiles action. Since 
the Windows Installer does not actually install files until the install script 
is executed (at "deferred" time) you cannot use a Component/File to copy your 
dependencies.

Ideally, the immediate CustomAction is implemented in C/C++ with no external 
dependencies (statically linked, for example). WiX provides a very easy way to 
author custom actions in .NET by using the DTF but this will introduce a 
dependency to the .NET runtime of your choice. If you cannot guarantee that the 
appropriate .NET runtime will be installed before your package is installed, 
then you'll need to use a bootstrapper (like Burn) to make sure the .NET 
runtime gets installed before your package is installed. If you decide to use 
scripts to implement your immediate CustomAction (not recommended as they are 
often very fragile and difficult to debug, also anti-virus and anti-malware 
software tend to hate them), then the Windows Installer support JScript and 
VBScript out-of-the-box. You have various options here including adding your 
JScript or VBScript to the Binary table or including the text of the script 
"inline".

For any other kind of script, you'll need to be responsible for making sure the 
script runtime is available (provide it yourself, detect it exists, or provide 
it yourself) and you'll be responsible for providing your own scripts as well. 
If you need to provide the engine and scripts, then you would need to write a 
custom action (using one of the methods in the previous paragraph) to extract 
your script engine and/or scripts from some location (probably the Binary 
table), execute your scripts, and finally clean up after yourself. There are 
two major things to consider here:

1.) You are already writing a custom action in C/C++ or .NET (JScript and 
VBScript do not seem to provide enough features to extract files but I could be 
wrong) so perhaps you should just implement your real custom action in C/C++ or 
.NET.
2.) You lose the ability to interact with the Windows Installer engine (for 
example, you cannot set properties to communicate with other custom actions or 
to affect Conditions on Components) so using these kinds of scripts are only 
really useful to actually make changes to the system (they need to run 
deferred) that are harder to make using another technique.

Perhaps someday WiX can provide a built-in mechanism to extract arbitrary files 
from the Binary table but I suspect that type of functionality is extremely low 
on the WiX developers' priority list (if it is there at all).

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: Dan Muller [mailto:dmuller...@comcast.net]
> Sent: Friday, June 15, 2012 9:23 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Sets of files installed at different times.
> 
> Our installer needs to run a set of scripts on install and uninstall, is 
> there a
> way to write a specific set of files to the disk, then call them using some
> custom actions we made and depending on whether some of them
> produced proper files outputs, wix would then install the rest of the files to
> the specified INSTALLDIR.
> 
> What would be the best way to do this? Would we be able to add them as
> components and have a custom action to install them? Is there another way
> built into wix, or is there something missing?
> 
> Thanks in advance,
> Dan
> 
> --
> View this message in context: http://windows-installer-xml-wix-
> toolset.687559.n2.nabble.com/Sets-of-files-installed-at-different-times-
> tp7578867.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--

[WiX-users] Sets of files installed at different times.

[Dan Muller]

Our installer needs to run a set of scripts on install and uninstall, is
there a way to write a specific set of files to the disk, then call them
using some custom actions we made and depending on whether some of them
produced proper files outputs, wix would then install the rest of the files
to the specified INSTALLDIR.

What would be the best way to do this? Would we be able to add them as
components and have a custom action to install them? Is there another way
built into wix, or is there something missing?

Thanks in advance,
Dan 

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Sets-of-files-installed-at-different-times-tp7578867.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Example of multiple browse buttons in a single Dialog

[dtiger1]

Can you send me the code for your solution?

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Example-of-multiple-browse-buttons-in-a-single-Dialog-tp693894p7578866.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Perl Script on initialization **UPDATE**

[Dan Muller]

Thank you for your help! We eventually figured it out, here is a snippet of
our working source



We had to write our own exe to do it however, but that was not really a
problem.

Now we are trying to figure out how we can get the perl scripts into the
msi, unpacked and on the new system, and run them before install. Is there a
way to include the .pl files and our ExecuteCommand.exe in the msi like you
would normal components and write them before the other files, or to include
them a separate way and have them still be written to disk before the actual
install occurs.

Thanks again,
Dan

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Perl-Script-on-initialization-tp7578584p7578865.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Passing component Id in Custom Action

[jhennessey]

raviraj87 wrote
> 
> I want to pass a file name in the argument of Custom Action. These files
> are getting installed into the system. Can I pass the component id of
> these
> files rather than passing hard coded name?
> 

You can use this expression [#/filekey/] to get the full path of a file.
Take a look here for more information: 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368609%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368609%28v=vs.85%29.aspx
 

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-component-Id-in-Custom-Action-tp7578858p7578863.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: Planning: package customization

[jhennessey]

Kannan24 wrote
> 
> Hi,
> 
> 1. I followed the update  to set the msiproperty values in managed code,
> but i cannot achieve to set the property value.
> 
> I have used the below code.
> 
> Bundle.wxs:
> 
> 
> 
>SourceFile="C:\Users\Kannanns\Documents\Visual Studio
> 2010\Projects\TestSetup\TestSetup\bin\Debug\TestSetup.msi"
> Compressed="yes" DisplayInternalUI="no" ForcePerMachine="yes"
> Permanent="yes" Vital="yes" EnableFeatureSelection="yes">
> 
>   
> 
> BA Managed code:
> 
>   SyncBA.Model.Engine.Plan(LaunchAction.Install);
> 
>   SyncBA.Model.Engine.Apply(SyncBA.hwnd);
> 
>   SyncBA.Model.Bootstrapper.Engine.StringVariables["UI"] = "FALSE";
> 
> In product.wxs i used the USER_INTERFACE as TRUE, now i changing the
> USER_INTERFACE in managed code. I got the USER_INTERFACE as UI instead of
> FALSE. Please point out me where i need to change.
> 

Like Windows Installer properties, use should use brackets to have burn
evaluate the burn variable. So, change  to 

Also, you need to change the value of the variable before calling Apply().


Kannan24 wrote
> 
> 2. I need to display the MSI features in managed code, i found the
> BootstrapperApplicationData.xml file under the temp folder, it shows all
> the msifeatures but not in an order. I need to display in treeview control
> as it same order in product.wxs. Is there any way to display the
> msifeatures list in managed code?
> 

Sort them by the "Display" attribute. Look at the MDSN documentation for the 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368585%28v=vs.85%29.aspx
feature table . Since you have all of the information from this table you
can mimic MSI behavior if you wish.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Planning-package-customization-tp6040489p7578862.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Only one Registry Entry gets deleted while Repair

[Ravi Raj]

I got the answer:



I have to remove *NOT Installed* condition form the custom action. BTW
thanks for your responses.

On Fri, Jun 15, 2012 at 2:22 PM, Ravi Raj wrote:

> I was checking the conditions for the registry entry and added a new
> component:
>
>  Guid="833D44E7-EECA-476F-BD06-9045692EE2A1">
>   Not InstalledKey="Software\!(loc.CompanyName)\!(loc.ProductName)">
>  KeyPath="yes"/>  
>
> its a simple registry entry for storing ComputerName. I preformed the
> Repair via Maintenance mode, and I saw that now both registry entries gets
> deleted.
>
> This is pretty strange. Is it happening because of:
>
> NOT 
> Installed After="CA_SetProperty_MACHINENAME">NOT Installed
>   After="AppSearch">Installed Action="CA_SetProperty_INSTALLPATH" 
> After="CA_SetProperty_SDKMACHINE">Installed
>
>
>
> On Fri, Jun 15, 2012 at 11:43 AM, Ravi Raj wrote:
>
>> The three components are:
>>
>> 
>>
>>   Not Installed  >   Key="Software\!(loc.CompanyName)\!(loc.ProductName)">
>>   
>> 
>>Not Installed  > Key="Software\!(loc.CompanyName)\!(loc.ProductName)">
>> > Value="[INSTALLMACHINE]" KeyPath="yes"/>  
>>Not Installed  > Key="Software\!(loc.CompanyName)\!(loc.ProductName)">
>> > KeyPath="yes"/>  
>>
>> First and last component remains the same but middle one gets flushed. I
>> have this following log:
>> MSI (s) (80:C8) [17:42:54:941]: Executing op: CacheSizeFlush(,)
>> MSI (s) (80:C8) [17:42:54:941]: Executing op:
>> ActionStart(Name=WriteRegistryValues,Description=Writing system registry
>> values,Template=Key: [1], Name: [2], Value: [3])
>> Action 17:42:54: WriteRegistryValues. Writing system registry values
>> MSI (s) (80:C8) [17:42:54:941]: Executing op:
>> ProgressTotal(Total=4,Type=1,ByteEquivalent=13200)
>> MSI (s) (80:C8) [17:42:54:941]: Executing op: 
>> RegOpenKey(Root=-2147483647,Key=Software\MyServer\MyServer
>> Management ,,BinaryType=0,,)
>> MSI (s) (80:C8) [17:42:54:941]: Executing op: RegAddValue(,Value=Default
>> Value,)
>> WriteRegistryValues: Key: \Software\MyServer\MyServer Management , Name:
>> , Value: Default Value
>> MSI (s) (80:C8) [17:42:54:941]: Executing op:
>> RegAddValue(Name=ServiceMachine,,)
>> WriteRegistryValues: Key: \Software\MyServer\MyServer UCS Management Pack
>> 2012, Name: SDKServiceMachine, Value:
>> MSI (s) (80:C8) [17:42:54:941]: Executing op:
>> RegAddValue(Name=InstallPath,Value=C:\Program Files (x86)\MyServer\MyServer
>> Management\,)
>> WriteRegistryValues: Key: \Software\MyServer\MyServer Management, Name:
>> InstallPath, Value: C:\Program Files (x86)\MyServer\MyServer Management\
>> MSI (s) (80:C8) [17:42:54:941]: Executing op:
>> RegAddValue(Name=Virtualization,,)
>> WriteRegistryValues: Key: \Software\MyServer\MyServer Management , Name:
>> Virtualization, Value:
>>
>> The Virtualization value is not populated because checkbox is not set a
>> value for it, this is normal but i am worried about ServiceMachine value.
>>
>>
>> On Fri, Jun 15, 2012 at 11:29 AM, Hoover, Jacob <
>> jacob.hoo...@greenheck.com> wrote:
>>
>>> Would it be possible to provide the 3 components which describe the 3
>>> values in question? In addition, since I assume you are rewriting these
>>> values during a repair it would be interesting to see how you are
>>> populating the property values. Have you searched the log files after
>>> re-invoking the installer with a /l*v .log?
>>>
>>> If I had to guess, you are missing the loading of the property in
>>> maintenance mode and the installer is deleting it cause it has no value.
>>> Verbose logging would tell you the value of the properties and the changes
>>> to the components.
>>>
>>>
>>> -Original Message-
>>> From: Ravi Raj [mailto:raviraj.callin...@gmail.com]
>>> Sent: Friday, June 15, 2012 12:31 AM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] Only one Registry Entry gets deleted while
>>> Repair
>>>
>>> Ok to test Repair I manually delete some files and rerun the installer.
>>> It puts back all  the file at the same places again (great, I guess). But
>>> even if i don't delete or touch any files and just simply runs the repair.
>>> Same thing happens. the registry gets deleted but other two remains the
>>> same and this only happens on Maintenance mode repair else Right-click
>>> repair has normal behavior?
>>>
>>> I am unable to track this behavior.
>>>
>>> On Fri, Jun 15, 2012 at 10:49 AM, Hoover, Jacob
>>> wrote:
>>>
>>> > >From msiexec /?,
>>> >
>>> > Repair Options
>>> >/f[p|e|c|m|s|o|d|a|u|v] 
>>> >Repairs a product
>>> >p - only if file is missing
>>> >o - if file is missing or an older version is installed
>>> > (default)
>>> >e - if file is missing or an equal or older version is
>>> > installed
>>> >d - if file is missing or a different version is
>>> installed
>>> >c - if file is missing or checksum does not match the
>>> > calculated value
>

Re: [WiX-users] Burn: Planning: package customization

[Kannan24]

Hi,

1. I followed the update  to set the msiproperty values in managed code, but
i cannot achieve to set the property value.

I have used the below code.

Bundle.wxs:



  

  

BA Managed code:

  SyncBA.Model.Engine.Plan(LaunchAction.Install);

  SyncBA.Model.Engine.Apply(SyncBA.hwnd);

  SyncBA.Model.Bootstrapper.Engine.StringVariables["UI"] = "FALSE";

In product.wxs i used the USER_INTERFACE as TRUE, now i changing the
USER_INTERFACE in managed code. I got the USER_INTERFACE as UI instead of
FALSE. Please point out me where i need to change.

2. I need to display the MSI features in managed code, i found the
BootstrapperApplicationData.xml file under the temp folder, it shows all the
msifeatures but not in an order. I need to display in treeview control as it
same order in product.wxs. Is there any way to display the msifeatures list
in managed code?

Thanks,
Kannan

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Planning-package-customization-tp6040489p7578859.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Passing component Id in Custom Action

[Ravi Raj]

I want to pass a file name in the argument of Custom Action. These files
are getting installed into the system. Can I pass the component id of these
files rather than passing hard coded name?

-- 
Thanks and Regards,
Ravi Raj
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Light.exe error: Value cannot be null

[Neil Sleightholm]

I seem to remember getting this error in one of the builds, have you tried the 
latest nightly build 3.6.3014.0 for example.

Neil

Neil Sleightholm
n...@x2systems.com


On 15 Jun 2012, at 06:39, Miss Parker wrote:

Hi,

1) I tried that clean/rebuild before posting, and it didn't make a
difference.

2) The only info I get is what I wrote in my first message:

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7578853/screen.png

I really would like to know which value can't be null.

There's nothing out of the ordinary with my msi package. It contains the id,
Vital , SourceFile and Visible attributes.

Regards,
Caisa

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Light-exe-error-Value-cannot-be-null-tp7578782p7578853.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Only one Registry Entry gets deleted while Repair

[Ravi Raj]

I was checking the conditions for the registry entry and added a new
component:

  Not
Installed  
  

its a simple registry entry for storing ComputerName. I preformed the
Repair via Maintenance mode, and I saw that now both registry entries gets
deleted.

This is pretty strange. Is it happening because of:

NOT
InstalledNOT Installed
 InstalledInstalled



On Fri, Jun 15, 2012 at 11:43 AM, Ravi Raj wrote:

> The three components are:
>
> 
>   Not InstalledKey="Software\!(loc.CompanyName)\!(loc.ProductName)">
>   
> 
>Not Installed  Key="Software\!(loc.CompanyName)\!(loc.ProductName)">
>  Value="[INSTALLMACHINE]" KeyPath="yes"/>  
>Not Installed  Key="Software\!(loc.CompanyName)\!(loc.ProductName)">
>  KeyPath="yes"/>  
>
> First and last component remains the same but middle one gets flushed. I
> have this following log:
> MSI (s) (80:C8) [17:42:54:941]: Executing op: CacheSizeFlush(,)
> MSI (s) (80:C8) [17:42:54:941]: Executing op:
> ActionStart(Name=WriteRegistryValues,Description=Writing system registry
> values,Template=Key: [1], Name: [2], Value: [3])
> Action 17:42:54: WriteRegistryValues. Writing system registry values
> MSI (s) (80:C8) [17:42:54:941]: Executing op:
> ProgressTotal(Total=4,Type=1,ByteEquivalent=13200)
> MSI (s) (80:C8) [17:42:54:941]: Executing op: 
> RegOpenKey(Root=-2147483647,Key=Software\MyServer\MyServer
> Management ,,BinaryType=0,,)
> MSI (s) (80:C8) [17:42:54:941]: Executing op: RegAddValue(,Value=Default
> Value,)
> WriteRegistryValues: Key: \Software\MyServer\MyServer Management , Name: ,
> Value: Default Value
> MSI (s) (80:C8) [17:42:54:941]: Executing op:
> RegAddValue(Name=ServiceMachine,,)
> WriteRegistryValues: Key: \Software\MyServer\MyServer UCS Management Pack
> 2012, Name: SDKServiceMachine, Value:
> MSI (s) (80:C8) [17:42:54:941]: Executing op:
> RegAddValue(Name=InstallPath,Value=C:\Program Files (x86)\MyServer\MyServer
> Management\,)
> WriteRegistryValues: Key: \Software\MyServer\MyServer Management, Name:
> InstallPath, Value: C:\Program Files (x86)\MyServer\MyServer Management\
> MSI (s) (80:C8) [17:42:54:941]: Executing op:
> RegAddValue(Name=Virtualization,,)
> WriteRegistryValues: Key: \Software\MyServer\MyServer Management , Name:
> Virtualization, Value:
>
> The Virtualization value is not populated because checkbox is not set a
> value for it, this is normal but i am worried about ServiceMachine value.
>
>
> On Fri, Jun 15, 2012 at 11:29 AM, Hoover, Jacob <
> jacob.hoo...@greenheck.com> wrote:
>
>> Would it be possible to provide the 3 components which describe the 3
>> values in question? In addition, since I assume you are rewriting these
>> values during a repair it would be interesting to see how you are
>> populating the property values. Have you searched the log files after
>> re-invoking the installer with a /l*v .log?
>>
>> If I had to guess, you are missing the loading of the property in
>> maintenance mode and the installer is deleting it cause it has no value.
>> Verbose logging would tell you the value of the properties and the changes
>> to the components.
>>
>>
>> -Original Message-
>> From: Ravi Raj [mailto:raviraj.callin...@gmail.com]
>> Sent: Friday, June 15, 2012 12:31 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Only one Registry Entry gets deleted while Repair
>>
>> Ok to test Repair I manually delete some files and rerun the installer.
>> It puts back all  the file at the same places again (great, I guess). But
>> even if i don't delete or touch any files and just simply runs the repair.
>> Same thing happens. the registry gets deleted but other two remains the
>> same and this only happens on Maintenance mode repair else Right-click
>> repair has normal behavior?
>>
>> I am unable to track this behavior.
>>
>> On Fri, Jun 15, 2012 at 10:49 AM, Hoover, Jacob
>> wrote:
>>
>> > >From msiexec /?,
>> >
>> > Repair Options
>> >/f[p|e|c|m|s|o|d|a|u|v] 
>> >Repairs a product
>> >p - only if file is missing
>> >o - if file is missing or an older version is installed
>> > (default)
>> >e - if file is missing or an equal or older version is
>> > installed
>> >d - if file is missing or a different version is
>> installed
>> >c - if file is missing or checksum does not match the
>> > calculated value
>> >a - forces all files to be reinstalled
>> >u - all required user-specific registry entries (default)
>> >m - all required computer-specific registry entries
>> > (default)
>> >s - all existing shortcuts (default)
>> >v - runs from source and recaches local package
>> >
>> > I guess the real question is what are you expecting the repair to do
>> > that it isn't doing? (I see the comment of deleted files.) Are you
>> > saying you do an install, then manually delete files and d