Avoiding re-downloading of payloads

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoiding re-downloading of payloads

Heath Stewart-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding re-downloading of payloads

Heath Stewart-3
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: [hidden email]
To: [hidden email]
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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding re-downloading of payloads

Rob Mensching-7
In reply to this post by Heath Stewart-3

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:[hidden email]]
Sent: Tuesday, April 28, 2015 3:06 PM
To: [hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding re-downloading of payloads

Rob Mensching-7
In reply to this post by Heath Stewart-3

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:[hidden email]]
Sent: Tuesday, April 28, 2015 4:01 PM
To: [hidden email]
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: [hidden email]
To: [hidden email]
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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding re-downloading of payloads

SeanHall
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 <[hidden email]> 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:[hidden email]]
Sent: Tuesday, April 28, 2015 4:01 PM
To: [hidden email]
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: [hidden email]
To: [hidden email]
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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding re-downloading of payloads

Rob Mensching-7

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:[hidden email]]
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 <[hidden email]> 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:[hidden email]]
Sent: Tuesday, April 28, 2015 4:01 PM
To: [hidden email]
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: [hidden email]
To: [hidden email]
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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding re-downloading of payloads

Heath Stewart-3
In reply to this post by Heath Stewart-3
Burn does verify, yes. I've fixed and tested this already.

Since VS is close to RTM I did a minimal fox that Bob reviewed. Before I send a PR to the public source I want to clean up a possibly confusing log message first but will send something soon.

Sent from my Windows Phone

From: [hidden email]
Sent: ‎4/‎29/‎2015 9:45 PM
To: [hidden email]
Subject: Re: [WiX-devs] Avoiding re-downloading of payloads

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:[hidden email]]
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 <[hidden email]> 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:[hidden email]]
Sent: Tuesday, April 28, 2015 4:01 PM
To: [hidden email]
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: [hidden email]
To: [hidden email]
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 [hidden email] 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs