wix-devs — Windows Installer XML toolset developer mailing list

Re: [WiX-devs] Assignment agreement broken?

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

Fixed now. Sorry for the trouble.

For those that were playing along at home, the root issue was a password reset due to a hacking at SendGrid. The assignment agreement web server’s password was not updated so the emails were failing to send. Thus the error. Updated the password and all is well now.

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

From: Rob Mensching [mailto:ro...@fi...]
Sent: Friday, May 29, 2015 1:54 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Assignment agreement broken?

No, not known issue. We’ll investigate. Thanks.

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

From: Mat Barrie [terrafinity] [mailto:mat...@te...]
Sent: Thursday, May 28, 2015 11:09 PM
To: wix...@li...<mailto:wix...@li...>
Subject: [WiX-devs] Assignment agreement broken?


Hi all,



We're keen to contribute to the WiX toolset, but haven't had much luck getting the assignment agreement on the toolset website to work.  Hitting send just gets an ASP.NET runtime error - no idea if it actually successfully sends but I'd hazard a guess not.



Known issue?



Mat Barrie, Managing Consultant
Terrafinity Pty Ltd

✉︎ Level 21, 345 Queen Street
Brisbane, Queensland 4000
✆ 07 3012 6074 (NZ 0800 100 735)
http://www.terrafinity.com.au/

Re: [WiX-devs] Assignment agreement broken?

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

No, not known issue. We’ll investigate. Thanks.

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

From: Mat Barrie [terrafinity] [mailto:mat...@te...]
Sent: Thursday, May 28, 2015 11:09 PM
To: wix...@li...
Subject: [WiX-devs] Assignment agreement broken?


Hi all,



We're keen to contribute to the WiX toolset, but haven't had much luck getting the assignment agreement on the toolset website to work.  Hitting send just gets an ASP.NET runtime error - no idea if it actually successfully sends but I'd hazard a guess not.



Known issue?



Mat Barrie, Managing Consultant
Terrafinity Pty Ltd

✉︎ Level 21, 345 Queen Street
Brisbane, Queensland 4000
✆ 07 3012 6074 (NZ 0800 100 735)
http://www.terrafinity.com.au/

[WiX-devs] Assignment agreement broken?

[Mat B. [terrafinity] <mat...@te...>]

Hi all,


We're keen to contribute to the WiX toolset, but haven't had much luck getting the assignment agreement on the toolset website to work.  Hitting send just gets an ASP.NET runtime error - no idea if it actually successfully sends but I'd hazard a guess not.


Known issue?


Mat Barrie, Managing Consultant

Terrafinity Pty Ltd

?? Level 21, 345 Queen Street
Brisbane, Queensland 4000
? 07 3012 6074 (NZ 0800 100 735)
http://www.terrafinity.com.au/

[WiX-devs] No meeting today.

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

Monday was a holiday and Bob is out today so we'll just pick it up next week.

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

Re: [WiX-devs] Making wcautil unit-testable

[Heath S. <he...@ou...>]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

[WiX-devs] Setting ComponetRequest State in Custom action not working

[suria p. <sur...@il...>]

HI,

I have changed the component request state to local in custom action, but it
doesn,t get reflected. always shows the old state. any idea how to change
the state?

Thanks,
Suria



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Setting-ComponetRequest-State-in-Custom-action-not-working-tp7600386.html
Sent from the wix-devs mailing list archive at Nabble.com.

[WiX-devs] Setting ComponentRequest State in CustomAction not working

[Suriaprakash C. <sur...@il...>]

HI,

I have set component request to local in custom action but it dosen't get reflected , always shows old value.
Any idea how to change the state

Thanks,
Suria.

Re: [WiX-devs] Making wcautil unit-testable

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

1.       Can we actually unit test much by hooking just ::MsiProcessMessage()? If so, cool.

2.       Instead of checking in a binary MSI + external UI handler, we can just build them.

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

From: Heath Stewart [mailto:he...@ou...]
Sent: Thursday, May 14, 2015 10:43 PM
To: wix...@li...
Subject: [WiX-devs] Making wcautil unit-testable

So I'm looking at fixing http://wixtoolset.org/issues/4668/ (pretty sure I already identified the issue), but want to make sure we have coverage for the change which was lacking before.

Many of the Wca* functions call ::MsiProcessMessage via WcaProcessMessage, which provides a perfect opportunity to use overrides similar to Wiu*, Reg*, and other APIs. It's been my observation that whatever MsiProcessMessage() sends goes right back to the external UI handler without modification in most cases (when not handled exclusively by Windows Installer).

Would we want to provide overrides for unit testing, or maybe just have a small MSI (though I hate checking in binaries to Git) we can set "install" with an external UI handler. We could remove the RegisterProduct action to avoid it ever actually installing.

Thoughts?

Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths

[WiX-devs] WiX Online Meeting #67

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

Next WiX Online meeting will be: May 19th, 2015 @14:30 PST

Agenda items:

*       Triage
*       NET Framework v4.5.1 and .2 EULA


.........................................................................................................................................
--> Join Skype Meeting<https://meet.lync.com/firegiant/rob/VY94G86G>
Help<http://go.microsoft.com/fwlink/?LinkId=389737>

[!OC([1033])!]
.........................................................................................................................................

Re: [WiX-devs] Removing Folder during UnInstallation

[Messenger, J. <jme...@nx...>]

Hello Harish,

This mailing list is for development of the WiX toolset itself. You should
use the WiX Users mailing list for help or usage questions. The information
on the users list may be found at
http://wixtoolset.org/documentation/mailinglist/ or you can join it
directly via this link
<mailto:wix...@li...?subject=subscribe>.

Thanks & Regards,

Joshua Messenger
Engineering Technician

NxStage Medical, Inc.
350 Merrimack Street
Lawrence, MA 01843
Tel: (978) 332-8468
Fax:  (978) 687-4800
jme...@nx...

This email transmission is intended only for the use of the individual to
which it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify me immediately by replying to this
message or by contacting NxStage at 978-687-4700 and destroy all copies of
this message and any attachments without reading or disclosing their
content. Thank you.



On Mon, May 18, 2015 at 6:25 AM, harish n <nha...@gm...> wrote:

> Hi ,
>
> I started learning wix this week. I came across this usecase.
>
> Say I  want to delete a folder during uninstallation.
> This folder is not  created by the installer during installation. It is
> created by the application to save some logs.
>
> Lets say "LogData " folder is present in C drive. I want to delete this
> during uninstallation.
>
> I tried this ,
>
>  <Directory Id="LogData " Name="LogData ">
>         <Component Id="LogData "
> Guid="c850748b-6955-479b-8d54-18819272688c">
>           <RemoveFolder Id='LogData' On='uninstall'/>
>         </Component>
>       </Directory>
>     </Directory>
>
> Please let me know what Im doing wrong.
>
>
> Regards
> harish
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>

[WiX-devs] Removing Folder during UnInstallation

[harish n <nha...@gm...>]

Hi ,

I started learning wix this week. I came across this usecase.

Say I  want to delete a folder during uninstallation.
This folder is not  created by the installer during installation. It is
created by the application to save some logs.

Lets say "LogData " folder is present in C drive. I want to delete this
during uninstallation.

I tried this ,

 <Directory Id="LogData " Name="LogData ">
        <Component Id="LogData "
Guid="c850748b-6955-479b-8d54-18819272688c">
          <RemoveFolder Id='LogData' On='uninstall'/>
        </Component>
      </Directory>
    </Directory>

Please let me know what Im doing wrong.


Regards
harish

[WiX-devs] Feature #4382: Add support for "files in use" in WixStdBA

[Georg v. K. <gv...@cr...>]

Hey guys,

 

I know it took me a long time, but I've finally managed to finish feature
http://wixtoolset.org/issues/4382/. I've send a pull request and would be
happy to hear your feedback.

 

Kind regards,

Georg 

 

 

[WiX-devs] Making wcautil unit-testable

[Heath S. <he...@ou...>]

So I'm looking at fixing http://wixtoolset.org/issues/4668/ (pretty sure I already identified the issue), but want to make sure we have coverage for the change which was lacking before.
 
Many of the Wca* functions call ::MsiProcessMessage via WcaProcessMessage, which provides a perfect opportunity to use overrides similar to Wiu*, Reg*, and other APIs. It's been my observation that whatever MsiProcessMessage() sends goes right back to the external UI handler without modification in most cases (when not handled exclusively by Windows Installer).
 
Would we want to provide overrides for unit testing, or maybe just have a small MSI (though I hate checking in binaries to Git) we can set "install" with an external UI handler. We could remove the RegisterProduct action to avoid it ever actually installing.
 
Thoughts?



Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths
  		 	   		  

[WiX-devs] Sorry, no meeting today.

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

This is a short week for me (travel Thursday) and I'm a bit squished. So no meeting this week. We'll get to all the bugs next week.

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

Re: [WiX-devs] .Net 4.5.x Eula - question for Bob

[Bob A. <bo...@fi...>]

You're just trying to take all the fun parts of my unpaid job, aren't you? :) Thank you! This is great.

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

-----Original Message-----
From: Phill Hogland [mailto:pho...@ri...] 
Sent: Wednesday, 29 April, 2015 18:12
To: wix...@li...
Subject: Re: [WiX-devs] .Net 4.5.x Eula - question for Bob

Here is a  link
<https://onedrive.live.com/redir?resid=ac7f61c6c8074409!547&authkey=!AEcZbJIyujeKD0g&ithint=folder%2c>
to the 4.5.1 and 4.5.2 Eula files (and the folder has the name of the package from which they were extracted).

I hope this helps.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Net-4-5-x-Eula-question-for-Bob-tp7600139p7600140.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

[WiX-devs] WiX Working Group #66

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

Next WiX Online meeting will be: May 5th, 2015 @14:30 PST

Agenda items:

*       Triage

.........................................................................................................................................
--> Join Skype Meeting<https://meet.lync.com/firegiant/rob/KQ038YVK>

Help<http://go.microsoft.com/fwlink/?LinkId=389737>

[!OC([1033])!]
.........................................................................................................................................

Re: [WiX-devs] Wix bootstrapper with UI dialogs

[John C. <JoC...@ja...>]

WiX-users would serve you far better.  This is a development list only.

--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.(r) | Lenexa, KS  66214 | Ext:  431050 |JoC...@ja...<mailto:JoC...@ja...>



From: Suriaprakash Chellappa [mailto:sur...@il...]
Sent: Monday, May 4, 2015 9:28 AM
To: wix...@li...
Subject: [WiX-devs] Wix bootstrapper with UI dialogs

Hi,

I am new to Wix installer. Iam using Wix bootstrapper to install multiple Msi packages, each of Msi package have their own UI dialogs to get inputs from users.
Is it possible to create UI dialogs in bootstrapper to get input from users and pass it to multiple MSI packages. How to achieve that? Theme file are seems to be restricted.

Thanks,
Suria.

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

[WiX-devs] Wix bootstrapper with UI dialogs

[Suriaprakash C. <sur...@il...>]

Hi,

I am new to Wix installer. Iam using Wix bootstrapper to install multiple Msi packages, each of Msi package have their own UI dialogs to get inputs from users.
Is it possible to create UI dialogs in bootstrapper to get input from users and pass it to multiple MSI packages. How to achieve that? Theme file are seems to be restricted.

Thanks,
Suria.

Re: [WiX-devs] Avoiding re-downloading of payloads

[Heath S. <he...@ou...>]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

Re: [WiX-devs] Avoiding re-downloading of payloads

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

1.       I’m not positive Burn verifies during layout. I think it does but would have to look.

2.       I’m quite sure that Burn does not “detect” during layout which is why Burn doesn’t know whether packages are already in the “layout” yet. Not sure that Detect() is the way to solve the problem but “normal” operations, detect is what would do it.

3.       I’m not against verifying the layout but the layout is not a trusted location. It’s just a place where all the files get put so you can burn a DVD or layout a network share or something.

It would be nice if Burn was a touch smarter about layout… I think that’s what those bugs are about.

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

From: Sean Hall [mailto:r.s...@gm...]
Sent: Wednesday, April 29, 2015 4:12 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Avoiding re-downloading of payloads

After downloading a payload during layout, does Burn verify the hash?  If not, then 3060 seems to be two feature requests: skipping packages that are already in the layout directory, and verifying the files during layout (so that you can run layout on upgraded bundles with the same destination folder and replace the payloads that were updated).  Rob's response makes it sound like we don't want to verify during layout, which would mean we would never fully implement 3060.

On Tue, Apr 28, 2015 at 8:23 PM, Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote:
Adding a package’s “Package Cache” location as a source seems completely reasonable.

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

From: Heath Stewart [mailto:he...@ou...<mailto:he...@ou...>]
Sent: Tuesday, April 28, 2015 4:01 PM
To: wix...@li...<mailto:wix...@li...>
Subject: Re: [WiX-devs] Avoiding re-downloading of payloads

For the time being, I thought I'd share that internally I've added - if set - the layout directory (whether doing a layout or not - seems the BA might want to do something special here) + package path to the rwzSourcePaths array in the CacheVerifyLocalContainerOrPayload() function we check before asking the BA. This works and feels like a good long-term fix unless we do want to consider the layout directory a sort of cache.
Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths

________________________________
From: he...@ou...<mailto:he...@ou...>
To: wix...@li...<mailto:wix...@li...>
Date: Tue, 28 Apr 2015 15:05:51 -0700
Subject: [WiX-devs] Avoiding re-downloading of payloads
I'm looking into fixing http://wixtoolset.org/issues/3060/ (rather, I'm fixing it anyway and was wondering if it already was so may as well pick this up) and have determined a couple different ways but wanted to get architecture guidance (or feedback in general).

Mainly, is a layout directory considered a local cache? I'm assuming not, since "cache" also carries some guarantees like that the file is protected (at least in per-machine cases). I ask, because one way is to check if we're doing a layout and, if so, track the layout path as the cache. This will avoid adding cache actions.

Similarly, I could add a member to track a layout specifically and avoid adding cache actions, but that blurs the line between cache and layout directory.

If we want to disassociate the cache and layout (as they appear to be now), the most straight forward way is to consider the layout directory (if doing a layout, or maybe just query the variable anytime since maybe the BA wants that to be considered regardless of bundle action) in CacheVerifyLocalContainerOrPayload(). We still plan cache actions, but not until before downloading it do we consider whether it's already downloaded. I'm leaning toward this one given that a layout isn't really a cache, but if we want to consider layout as a type of cache than the ideas above make more sense.

Thoughts?
Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths

------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
WiX-devs mailing list
WiX...@li...<mailto:WiX...@li...>
https://lists.sourceforge.net/lists/listinfo/wix-devs

Re: [WiX-devs] Avoiding re-downloading of payloads

[Sean H. <r.s...@gm...>]

After downloading a payload during layout, does Burn verify the hash?  If
not, then 3060 seems to be two feature requests: skipping packages that are
already in the layout directory, and verifying the files during layout (so
that you can run layout on upgraded bundles with the same destination
folder and replace the payloads that were updated).  Rob's response makes
it sound like we don't want to verify during layout, which would mean we
would never fully implement 3060.

On Tue, Apr 28, 2015 at 8:23 PM, Rob Mensching <ro...@fi...> wrote:

>  Adding a package’s “Package Cache” location as a source seems completely
> reasonable.
>
>
>
> _______________________________________________________________
>
> FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
>
>
> *From:* Heath Stewart [mailto:he...@ou...]
> *Sent:* Tuesday, April 28, 2015 4:01 PM
> *To:* wix...@li...
> *Subject:* Re: [WiX-devs] Avoiding re-downloading of payloads
>
>
>
> For the time being, I thought I'd share that internally I've added - if
> set - the layout directory (whether doing a layout or not - seems the BA
> might want to do something special here) + package path to the
> rwzSourcePaths array in the CacheVerifyLocalContainerOrPayload() function
> we check before asking the BA. This works and feels like a good long-term
> fix unless we do want to consider the layout directory a sort of cache.
>
> *Heath Stewart*
> Software Engineer
> Visual Studio, Microsoft
> http://blogs.msdn.com/heaths
>
>
>  ------------------------------
>
> From: he...@ou...
> To: wix...@li...
> Date: Tue, 28 Apr 2015 15:05:51 -0700
> Subject: [WiX-devs] Avoiding re-downloading of payloads
>
> I'm looking into fixing http://wixtoolset.org/issues/3060/ (rather, I'm
> fixing it anyway and was wondering if it already was so may as well pick
> this up) and have determined a couple different ways but wanted to get
> architecture guidance (or feedback in general).
>
>
>
> Mainly, is a layout directory considered a local cache? I'm assuming not,
> since "cache" also carries some guarantees like that the file is protected
> (at least in per-machine cases). I ask, because one way is to check if
> we're doing a layout and, if so, track the layout path as the cache. This
> will avoid adding cache actions.
>
>
>
> Similarly, I could add a member to track a layout specifically and avoid
> adding cache actions, but that blurs the line between cache and layout
> directory.
>
>
>
> If we want to disassociate the cache and layout (as they appear to be
> now), the most straight forward way is to consider the layout directory (if
> doing a layout, or maybe just query the variable anytime since maybe the BA
> wants that to be considered regardless of bundle action) in
> CacheVerifyLocalContainerOrPayload(). We still plan cache actions, but not
> until before downloading it do we consider whether it's already downloaded.
> I'm leaning toward this one given that a layout isn't really a cache, but
> if we want to consider layout as a type of cache than the ideas above make
> more sense.
>
>
>
> Thoughts?
>
> *Heath Stewart*
> Software Engineer
> Visual Studio, Microsoft
> http://blogs.msdn.com/heaths
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications Performance
> metrics, stats and reports that give you Actionable Insights Deep dive
> visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________ WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> WiX-devs mailing list
> WiX...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>

Re: [WiX-devs] .Net 4.5.x Eula - question for Bob

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

Here is a  link
<https://onedrive.live.com/redir?resid=ac7f61c6c8074409!547&authkey=!AEcZbJIyujeKD0g&ithint=folder%2c>  
to the 4.5.1 and 4.5.2 Eula files (and the folder has the name of the
package from which they were extracted).

I hope this helps.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Net-4-5-x-Eula-question-for-Bob-tp7600139p7600140.html
Sent from the wix-devs mailing list archive at Nabble.com.

[WiX-devs] .Net 4.5.x Eula - question for Bob

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

Thanks for the information in the Tuesday night meeting about how to grab the
Eula for the .Net 4.5.x.  I have the 21 localized eulas for the
NDP451-KB2859818-Web download package.

Bob;

Would be helpful for me to stage these files for you to access them?

since I have a vm configured to grab these would you like for me to grab the
4.5.2 (or any other eulas)?

Is it necessary to also grab eulas from the 'full' download package?

Phill



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Net-4-5-x-Eula-question-for-Bob-tp7600139.html
Sent from the wix-devs mailing list archive at Nabble.com.

Re: [WiX-devs] Avoiding re-downloading of payloads

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

Adding a package's "Package Cache" location as a source seems completely reasonable.

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

From: Heath Stewart [mailto:he...@ou...]
Sent: Tuesday, April 28, 2015 4:01 PM
To: wix...@li...
Subject: Re: [WiX-devs] Avoiding re-downloading of payloads

For the time being, I thought I'd share that internally I've added - if set - the layout directory (whether doing a layout or not - seems the BA might want to do something special here) + package path to the rwzSourcePaths array in the CacheVerifyLocalContainerOrPayload() function we check before asking the BA. This works and feels like a good long-term fix unless we do want to consider the layout directory a sort of cache.
Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths

________________________________
From: he...@ou...<mailto:he...@ou...>
To: wix...@li...<mailto:wix...@li...>
Date: Tue, 28 Apr 2015 15:05:51 -0700
Subject: [WiX-devs] Avoiding re-downloading of payloads
I'm looking into fixing http://wixtoolset.org/issues/3060/ (rather, I'm fixing it anyway and was wondering if it already was so may as well pick this up) and have determined a couple different ways but wanted to get architecture guidance (or feedback in general).

Mainly, is a layout directory considered a local cache? I'm assuming not, since "cache" also carries some guarantees like that the file is protected (at least in per-machine cases). I ask, because one way is to check if we're doing a layout and, if so, track the layout path as the cache. This will avoid adding cache actions.

Similarly, I could add a member to track a layout specifically and avoid adding cache actions, but that blurs the line between cache and layout directory.

If we want to disassociate the cache and layout (as they appear to be now), the most straight forward way is to consider the layout directory (if doing a layout, or maybe just query the variable anytime since maybe the BA wants that to be considered regardless of bundle action) in CacheVerifyLocalContainerOrPayload(). We still plan cache actions, but not until before downloading it do we consider whether it's already downloaded. I'm leaning toward this one given that a layout isn't really a cache, but if we want to consider layout as a type of cache than the ideas above make more sense.

Thoughts?
Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths

------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs

Re: [WiX-devs] Avoiding re-downloading of payloads

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

Quick answer: Layout is not a cache. It's not trusted or anything like that. Burn will verify the bits later.

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

From: Heath Stewart [mailto:he...@ou...]
Sent: Tuesday, April 28, 2015 3:06 PM
To: wix...@li...
Subject: [WiX-devs] Avoiding re-downloading of payloads

I'm looking into fixing http://wixtoolset.org/issues/3060/ (rather, I'm fixing it anyway and was wondering if it already was so may as well pick this up) and have determined a couple different ways but wanted to get architecture guidance (or feedback in general).

Mainly, is a layout directory considered a local cache? I'm assuming not, since "cache" also carries some guarantees like that the file is protected (at least in per-machine cases). I ask, because one way is to check if we're doing a layout and, if so, track the layout path as the cache. This will avoid adding cache actions.

Similarly, I could add a member to track a layout specifically and avoid adding cache actions, but that blurs the line between cache and layout directory.

If we want to disassociate the cache and layout (as they appear to be now), the most straight forward way is to consider the layout directory (if doing a layout, or maybe just query the variable anytime since maybe the BA wants that to be considered regardless of bundle action) in CacheVerifyLocalContainerOrPayload(). We still plan cache actions, but not until before downloading it do we consider whether it's already downloaded. I'm leaning toward this one given that a layout isn't really a cache, but if we want to consider layout as a type of cache than the ideas above make more sense.

Thoughts?
Heath Stewart
Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths