wix-users — Mailing list for questions/discussion about the Windows Installer XML toolset.

Re: [WiX-users] «Bundle Uprgade issue: the same MSI in two bundles»

[Rob M. <ro...@fi...>]

What does the bundle log file show?

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: boroda [mailto:bo....@ma...] 
Sent: Thursday, July 16, 2015 7:25 AM
To: wix...@li...
Subject: [WiX-users] «Bundle Uprgade issue: the same MSI in two bundles»

Hello, guys.
I have a problem. And the actions of bundle are not obvious. 
So, I have the follows packages: 
•	MSI ‘MSI_A_v1’
•	MSI ‘MSI_B_v1’
•	Bundle Bv1, installs MSI_A_v1 and MSI_B_v1.
•	And MSI ‘MSI_A_v2’ (Major upgrade of ' MSI_A_v1', including changing
Product Id)
•	Bundle Bv2 (the UpgradeCode is the same as the Bv1, but version is upper). 
Bundle Bv2 installs MSI_A_v2 and MSI_B_v1.

My steps:
1.	Install Bundle Bv1
2.	Install Bundle Bv2. 
During the installation, MSI_A_v2 is updating MSI_A_v1 (it’s OK), MSI_B_v1 is doing nothing (it’s OK too), and Bv2 is deleting Bv1. It’s OK too, BUT the Bv1’s uninstallation also deletes MSI_B_v1! Why! Bv2 has link to MSI_B_v1, and the product MSI_B_v1 should remain on system. This is the main problem, after installation, the MSI_B_v1 is not on the system

Re: [WiX-users] File extension association

[Rob M. <ro...@fi...>]

What does this part mean "now the association between the application and its model file is no longer established at installation"?

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Moore, Odric M. (MSFC-ER43)[MITS] [mailto:ric...@na...] 
Sent: Thursday, July 16, 2015 7:22 AM
To: wix...@li...
Subject: [WiX-users] File extension association

I have a WiX 3.7 installation package that is operating fine using perMachine IntallScope.  I want to change the installation so that it can be accomplished without admin privilege.

Changing to perUser has accomplished that, but now the association between the application and its model file is no longer established at installation.

Is this something that is not permitted under perUser?



------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
WiX-users mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system

[Edwin C. <eg...@gm...>]

I can't use semi-custom-actions for this particular piece of work because I
need to call an API to get permission to create, delete, or modify these
particular registry keys. I work at a security company where they have
implemented additional security features through drivers that disallow
normal interactions with certain resources. Otherwise, I would totally use
the semi-custom-action approach. I use it right now to add rows to the
RemoveFile table depending on whether we're uninstalling for an upgrade or
not.

In any case, RegDelete appears broken to me. At a minimum, the bitness
should be incorporated into the RegOpen call. Should I file a bug to track?


On Thu, Jul 16, 2015 at 7:01 AM, Phill Hogland <pho...@ri...> wrote:

> FYI - I just implemented a  semi-custom
> <http://www.joyofsetup.com/2007/07/01/semi-custom-actions/>   action
> using a
> similar implementation as I found in the WixGamingExtension which calls
> WcaAddTempRecord on the Registry table, to allow MSI to manage my registry
> change.  The CA code (specifically the registry path) is agnostic to
> WoW6432Node so that the CA can be built for either Win32 or x64 and used in
> either a x86 or x64 MSI.  I only needed to set Component /@Win64="no" and
> MSI handles the redirection.
>
> The MSI packages are also built using the InstallerPlatform MSBuild
> property
> to set the bitness of the MSI.  For most of the Components I never set
> Win64, but for this registry key setting Win64="no" was needed to get MSI
> to
> redirect the the registry hive.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-Bug-RegDelete-does-not-work-properly-with-REG-KEY-32BIT-on-a-64-bit-system-tp7600893p7600896.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> WiX-users mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro

[WiX-users] wix meeting #73 - new logo

[Phill H. <pho...@ri...>]

Sorry I missed the meeting, but thanks for the blog/web-stream.

My first impression was for #3 red.  I did not initially notice the
tri-color, but it is nice.

#2 was striking and caught my attention about as much as #3, but I also
thought it was "big" before I considered the comments of others.

The orange was much less appealing (probably because of being conditioned to
expect red in the context of WiX.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wix-meeting-73-new-logo-tp7600899.html
Sent from the wix-users mailing list archive at Nabble.com.

[WiX-users] «Bundle Uprgade issue: the same MSI in two bundles»

[boroda <bo....@ma...>]

Hello, guys.
I have a problem. And the actions of bundle are not obvious. 
So, I have the follows packages: 
•	MSI ‘MSI_A_v1’
•	MSI ‘MSI_B_v1’
•	Bundle Bv1, installs MSI_A_v1 and MSI_B_v1.
•	And MSI ‘MSI_A_v2’ (Major upgrade of ' MSI_A_v1', including changing
Product Id)
•	Bundle Bv2 (the UpgradeCode is the same as the Bv1, but version is upper). 
Bundle Bv2 installs MSI_A_v2 and MSI_B_v1.

My steps:
1.	Install Bundle Bv1
2.	Install Bundle Bv2. 
During the installation, MSI_A_v2 is updating MSI_A_v1 (it’s OK), MSI_B_v1
is doing nothing (it’s OK too), and Bv2 is deleting Bv1. It’s OK too, BUT
the Bv1’s uninstallation also deletes MSI_B_v1! Why! Bv2 has link to
MSI_B_v1, and the product MSI_B_v1 should remain on system. This is the main
problem, after installation, the MSI_B_v1 is not on the system




--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-Uprgade-issue-the-same-MSI-in-two-bundles-tp7600898.html
Sent from the wix-users mailing list archive at Nabble.com.

[WiX-users] File extension association

[Moore, O. M. (MSFC-ER43)[MITS] <ric...@na...>]

I have a WiX 3.7 installation package that is operating fine using perMachine IntallScope.  I want to change the installation so that it can be accomplished without admin privilege.

Changing to perUser has accomplished that, but now the association between the application and its model file is no longer established at installation.

Is this something that is not permitted under perUser?

Re: [WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system

[Phill H. <pho...@ri...>]

FYI - I just implemented a  semi-custom
<http://www.joyofsetup.com/2007/07/01/semi-custom-actions/>   action using a
similar implementation as I found in the WixGamingExtension which calls
WcaAddTempRecord on the Registry table, to allow MSI to manage my registry
change.  The CA code (specifically the registry path) is agnostic to
WoW6432Node so that the CA can be built for either Win32 or x64 and used in
either a x86 or x64 MSI.  I only needed to set Component /@Win64="no" and
MSI handles the redirection.

The MSI packages are also built using the InstallerPlatform MSBuild property
to set the bitness of the MSI.  For most of the Components I never set
Win64, but for this registry key setting Win64="no" was needed to get MSI to
redirect the the registry hive.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-Bug-RegDelete-does-not-work-properly-with-REG-KEY-32BIT-on-a-64-bit-system-tp7600893p7600896.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system

[Nir B. <ni...@pa...>]

You shuold OR it with the KEY_READ
See  Registry Key Security and Access Rights
<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724878(v=vs.85).aspx>  



-----
Nir Bar 
Freelance Developer 
Mail: ni...@pa... 
Web: www.panel-sw.com 
   - C++ On Windows, Linux and Embedded Platforms 
   - WiX & InstallShield 
--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-Bug-RegDelete-does-not-work-properly-with-REG-KEY-32BIT-on-a-64-bit-system-tp7600893p7600894.html
Sent from the wix-users mailing list archive at Nabble.com.

[WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system

[Edwin C. <eg...@gm...>]

I was trying to use RegDelete from the dutil library and I noticed my
32-bit key did not get deleted on a 64-bit system. I think the problem is
the following RegOpen call

hr = RegOpen(khRoot, wzSubKey, KEY_READ, &hkKey);
if (E_FILENOTFOUND == hr)
{
    ExitFunction1(hr = S_OK);
}

Since KEY_WOW64_32KEY is not specified then RegOpen checks the 64-bit hive,
doesn't find the key, and exits RegDelete.

In other words, I think RegDelete only works with REG_KEY_DEFAULT!

-- 
Edwin G. Castro

Re: [WiX-users] Creating an ARP button for "Uninstall/Change" vs. "Uninstall" & "Change"

[Joel B. <joe...@gm...>]

Sure thing. I’ll probably dig through the burn source code.

Thanks Phill.
> On Jul 15, 2015, at 1:58 PM, Phill Hogland <pho...@ri...> wrote:
> 
> I cannot speak to not using Burn, but in the last link that you originally
> posted, the last post indicates that the information was posted earlier in
> that thread, so I would guess that there is an MSI property that controls
> it.  WiX is open source so it should be in the code for research.  I also
> expect that to some degree the behavior of the ARP feature of windows
> depends on which version/edition of the OS is being targeted.
> 
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-an-ARP-button-for-Uninstall-Change-vs-Uninstall-Change-tp7600885p7600891.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> WiX-users mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating an ARP button for "Uninstall/Change" vs. "Uninstall" & "Change"

[Phill H. <pho...@ri...>]

I cannot speak to not using Burn, but in the last link that you originally
posted, the last post indicates that the information was posted earlier in
that thread, so I would guess that there is an MSI property that controls
it.  WiX is open source so it should be in the code for research.  I also
expect that to some degree the behavior of the ARP feature of windows
depends on which version/edition of the OS is being targeted.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-an-ARP-button-for-Uninstall-Change-vs-Uninstall-Change-tp7600885p7600891.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] Creating an ARP button for "Uninstall/Change" vs. "Uninstall" & "Change"

[Joel B. <joe...@gm...>]

What if ‘not’ using a Burn bundle?

> On Jul 15, 2015, at 6:14 AM, Phill Hogland <pho...@ri...> wrote:
> 
> Using a Burn bundle set Bundle/@DisableModify="button"
> 
> 
> 
> --
> View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-an-ARP-button-for-Uninstall-Change-vs-Uninstall-Change-tp7600885p7600886.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> WiX-users mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] IIS 10 support

[Matteo C. <Mat...@mi...>]

Hi to everyone,

My installer cannot create virtual folders on Windows 10 / IIS 10 whereas it works fine on any previous Windows / IIS version.
I tried both Wix 3.9 and upcoming Wix 3.10 RC: anyone know if Wix (3.9 or 3.10, with IIS extension) support Windows 10 / IIS 10?


Many thanks,

Matteo

[WiX-users] IIS 10 support

[Matteo C. <Mat...@mi...>]

Hi to everyone,

My installer cannot create virtual folders on Windows 10 / IIS 10 whereas it works fine on any previous Windows / IIS version.
I tried both Wix 3.9 and upcoming Wix 3.10 RC: anyone know if Wix (3.9 or 3.10, with IIS extension) supports Windows 10 / IIS 10?


Many thanks,

Matteo

Re: [WiX-users] Creating an ARP button for "Uninstall/Change" vs. "Uninstall" & "Change"

[Phill H. <pho...@ri...>]

Using a Burn bundle set Bundle/@DisableModify="button"



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-an-ARP-button-for-Uninstall-Change-vs-Uninstall-Change-tp7600885p7600886.html
Sent from the wix-users mailing list archive at Nabble.com.

[WiX-users] Creating an ARP button for "Uninstall/Change" vs. "Uninstall" & "Change"

[Joel B. <joe...@gm...>]

I've been trying to google around for how to create a single
"Uninstall/Change" button in the windows ARP for my installer, and
I've run into a number of forum posts that don't seem to answer the
problem:

http://installjournal.blogspot.com/2012/12/combining-uninstall-change-on-same.html

http://stackoverflow.com/questions/1741857/remove-change-and-repair-buttons-in-add-or-remove-programs/20212073

https://social.msdn.microsoft.com/Forums/windows/en-US/c8156aa6-98a7-40a6-9ad1-e6bb347650c1/how-to-combine-uninstallchange-in-add-remove-program-using-orca-editor?forum=winformssetup

Anybody have an answer?

Thanks,
Joel

[WiX-users] RemoveExistingProducts does not set MsiLogFileLocation

[Edwin C. <eg...@gm...>]

I know this is now a WiX specific question. Please point me to a better
place to ask this.

I have a custom action that launches an exe. The custom action uses
MsiLogFileLocation as a base to construct a log file path for the exe
command line. This all works great during install and uninstall because my
bundle ensures that a log is always created and I'm targeting Windows Vista
or greater with Windows Installer 4.0 or greater.

During an upgrade I see that MsiLogFileLocation is set in the context of
the upgrade msi but during the execution of RemoveExistingProducts I don't
see MsiLogFileLocation set and this causes my uninstall custom action to
fail because I'm not constructing a proper path for the log command line
argument.

I expected that MsiLogFileLocation would be automatically set by
RemoveExistingProducts when uninstalling related products but that
assumption appears to be incorrect.

Does anybody have any suggestions on how I might pass the value of
MsiLogFileLocation to the uninstalling msi to produce the correct log file?

The exe in question does not write the contents of this log to standard
output so I can't use CAQuietExec to capture the log.

-- 
Edwin G. Castro

Re: [WiX-users] How to detect if prevous version uninstall is triggered by RemoveExistingProducts

[TimM <Tim...@sm...>]

Okay I have been searching around and found the following property:
UPGRADINGPRODUCTCODE

I totally forgot about this property and therefore this is the one that I
should be setting my custom action conditions on. 



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-detect-if-prevous-version-uninstall-is-triggered-by-RemoveExistingProducts-tp7600881p7600882.html
Sent from the wix-users mailing list archive at Nabble.com.

[WiX-users] How to detect if prevous version uninstall is triggered by RemoveExistingProducts

[TimM <Tim...@sm...>]

I would like to know if there is a way to detect what triggered a product
uninstall.

Issue: We have some custom actions that should NOT be triggered if the
install is running in Upgrade mode. This is true for the upgrade install,
but the custom actions in the previous version, that is being uninstalled by
RemoveExistingProducts, do get triggered and therefore removes content that
we do not removed on an upgrade install.

We have the custom actions conditioned on the property WIX_UPGRADE_DETECTED,
the this property only gets set in the upgrade install, not the previous
version that is being uninstalled.

So we need to know how the previous version is being triggered to uninstall,
that it can detect, so that we can turn off the custom actions. We know if
we get something that will work it would mean that it will not take affect
until the current install project becomes the previous version, but at least
if we get something built in now to detect this then it would work for
future releases...

So if there is anything that we can detect to know that the previous version
is being uninstalled by an upgrade install then this would greatly help us
out...

Thanks,




--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-detect-if-prevous-version-uninstall-is-triggered-by-RemoveExistingProducts-tp7600881.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] Publisher policy registry entries not cleaned up after an uninstall

[kirannhegde <kir...@gm...>]

Hello,

Does anyone has any ideas here?

Regards,
Kiran Hegde



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Publisher-policy-registry-entries-not-cleaned-up-after-an-uninstall-tp7600854p7600880.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] Why Does Bundle Prompt For Source During Uninstall?

[Rob M. <ro...@fi...>]

The attached container is stripped (to save [often signification] disk space). Look higher in the log to see what package is requesting to be cached during uninstall. Probably an ExePackage.

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Edwin Castro [mailto:eg...@gm...] 
Sent: Monday, July 13, 2015 4:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Why Does Bundle Prompt For Source During Uninstall?

I have a bundle that I have successfully installed. When I try to uninstall I get the following:

[0E54:03D0][2015-07-13T15:34:03]i300: Apply begin
[07F0:0814][2015-07-13T15:34:03]i360: Creating a system restore point.
[07F0:0814][2015-07-13T15:34:10]i361: Created a system restore point.
[0E54:01C4][2015-07-13T15:34:10]w341: Prompt for source of container:
WixAttachedContainer, path: C:\Original\path\to\bundle\setup.exe
[0E54:01C4][2015-07-13T15:34:10]e054: Failed to resolve source for
file: C:\Original\path\to\bundle\setup.exe, error: 0x80070643.
[0E54:01C4][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while prompting for source (original path 'C:\Original\path\to\bundle\setup.exe').
[0E54:01C4][2015-07-13T15:34:10]e311: Failed to acquire container:
WixAttachedContainer to working path:
C:\Windows\TEMP\{e2007576-a648-4b3f-8e4d-eccd898e4591}\75A375A2F5B5EE0C8914C4790878E0D2772E4838,
error: 0x80070643.
[0E54:03D0][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while caching, aborting execution.
[0E54:03D0][2015-07-13T15:34:10]i399: Apply complete, result: 0x80070643,
restart: None, ba requested restart:  No
[0E54:03D0][2015-07-13T15:34:11]i500: Shutting down, exit code: 0x643

I checked C:\ProgramData\Package Cache to make sure my bundle was still cached (it was).

Under what circumstances does the burn engine try to resolve the original bundle location?

I was under the impression that the bundle was cached at C:\ProgramData\Package Cache to avoid needing the original source to be available.

--
Edwin G. Castro 

[WiX-users] Why Does Bundle Prompt For Source During Uninstall?

[Edwin C. <eg...@gm...>]

I have a bundle that I have successfully installed. When I try to uninstall
I get the following:

[0E54:03D0][2015-07-13T15:34:03]i300: Apply begin
[07F0:0814][2015-07-13T15:34:03]i360: Creating a system restore point.
[07F0:0814][2015-07-13T15:34:10]i361: Created a system restore point.
[0E54:01C4][2015-07-13T15:34:10]w341: Prompt for source of container:
WixAttachedContainer, path: C:\Original\path\to\bundle\setup.exe
[0E54:01C4][2015-07-13T15:34:10]e054: Failed to resolve source for
file: C:\Original\path\to\bundle\setup.exe, error: 0x80070643.
[0E54:01C4][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while
prompting for source (original path 'C:\Original\path\to\bundle\setup.exe').
[0E54:01C4][2015-07-13T15:34:10]e311: Failed to acquire container:
WixAttachedContainer to working path:
C:\Windows\TEMP\{e2007576-a648-4b3f-8e4d-eccd898e4591}\75A375A2F5B5EE0C8914C4790878E0D2772E4838,
error: 0x80070643.
[0E54:03D0][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while
caching, aborting execution.
[0E54:03D0][2015-07-13T15:34:10]i399: Apply complete, result: 0x80070643,
restart: None, ba requested restart:  No
[0E54:03D0][2015-07-13T15:34:11]i500: Shutting down, exit code: 0x643

I checked C:\ProgramData\Package Cache to make sure my bundle was still
cached (it was).

Under what circumstances does the burn engine try to resolve the original
bundle location?

I was under the impression that the bundle was cached at
C:\ProgramData\Package Cache to avoid needing the original source to be
available.

-- 
Edwin G. Castro

Re: [WiX-users] .NET Prerequisite, Burn, and the ARP

[Phill H. <pho...@ri...>]

I believe that there 'may' be a bug in the existing implementation along the
lines that Colin described or and related to the comment "Burn should keep
registration in ARP when the first non-permanent package is installed (aka:
there is something Burn would do).".  In the scenarios where I had
difficulty I could not do an Uninstall or a Major Upgrade of a Burn chain
which had previously failed after only successfully installing 'permanent'
items in the chain.  To get past this issue at the time I removed a Rollback
boundary which immediately followed the last permanent item in the chain
(just before the non-permanent item in the chain which had failed) in the
original installation.  While I never did find a way to uninstall the
original failed setup, every since I removed the RollbackBoundary from my
chain I have not been able to recreate the problem scenario.  So I think
there might be a problem in handling this scenario in 3.9/3.10 but I did not
go back an validate my memory that this did not happen in 3.8, nor have I
had a chance to setup a more indepth debug to see if I can track down where
the problem is.  I suspect that the non-trivial new feature issue of making
Burn behave like a fire-and-forget bootstrapper is a separate issue (which I
do not have an interest in).



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-Prerequisite-Burn-and-the-ARP-tp7600376p7600877.html
Sent from the wix-users mailing list archive at Nabble.com.

Re: [WiX-users] .NET Prerequisite, Burn, and the ARP

[Rob M. <ro...@fi...>]

Yes. There are very good reasons why Burn behaves the way it does today and handling this case requires additional (non-trivial) code (not fixing existing code).

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Jiri Tomek [mailto:ka...@vo...] 
Sent: Monday, July 13, 2015 3:23 AM
To: wix...@li...
Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP

So just to make sure, the current behavior is kind of "by design" and currently there is no way how to not get ARP entry if .NET prereqba succeeds? It needs to be implemented as a new feature to Burn?

Re: [WiX-users] .NET Prerequisite, Burn, and the ARP

[Jiri T. <ka...@vo...>]

So just to make sure, the current behavior is kind of "by design" and
currently there is no way how to not get ARP entry if .NET prereqba
succeeds? It needs to be implemented as a new feature to Burn?



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-Prerequisite-Burn-and-the-ARP-tp7600376p7600875.html
Sent from the wix-users mailing list archive at Nabble.com.