Quantcast

Heat -generate

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Heat -generate

David L. Beckwith
I'm using Burn and I got to say I love it!!!

However, it makes me want more...

I'm trying to get a legacy installation package chained and am
struggling. I would like to containerize the legacy install so my
bootstrapper is small and incremental. I've tried heat in the hopes of
it saving time and doing it right in the first place. However, it seems
the "-generate" switch is ignored. I've tried "-generate payloadgroup"
and container but seem to only get components.

What am I doing wrong?

David L. Beckwith

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

robmen
Heat has lots of gaps. It's an area for us to invest in WiX v4.

On Wed, Oct 19, 2011 at 10:08 AM, David L. Beckwith <
[hidden email]> wrote:

> I'm using Burn and I got to say I love it!!!
>
> However, it makes me want more...
>
> I'm trying to get a legacy installation package chained and am
> struggling. I would like to containerize the legacy install so my
> bootstrapper is small and incremental. I've tried heat in the hopes of
> it saving time and doing it right in the first place. However, it seems
> the "-generate" switch is ignored. I've tried "-generate payloadgroup"
> and container but seem to only get components.
>
> What am I doing wrong?
>
> David L. Beckwith
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
I was hoping output from heat payloadgroups and containers would help me understand how to create such an animal. Where do you suggest I look for clues on how to take a legacy install and "containerize" it?

Rob Mensching-7 wrote
Heat has lots of gaps. It's an area for us to invest in WiX v4.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

Bob Arnson-6
On 24-Oct-11 10:10, David L. Beckwith wrote:
> I was hoping output from heat payloadgroups and containers would help me
> understand how to create such an animal. Where do you suggest I look for
> clues on how to take a legacy install and "containerize" it?
Maybe you could explain what "containerize" means...<g>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
Bob Arnson-6 wrote
On 24-Oct-11 10:10, David L. Beckwith wrote:
> I was hoping output from heat payloadgroups and containers would help me
> understand how to create such an animal. Where do you suggest I look for
> clues on how to take a legacy install and "containerize" it?
Maybe you could explain what "containerize" means...<g>
Hopefully I'll use the correct terminology....

I'll try to describe what I would like to do and what steps I did to get there. Some of the documentation in Rob's blogs, etc. imply I can do what I want and some of what I've done leads me to believe it is possible. I just don't know how.

Basically, I have a legacy install program that I would like chained. Specifically, it is Microsoft's Point of Service for dotNet. There is no "ClickOnce" install, instead it is delivered as a self extracting zip. It has a setup bootstapper with a scad full of files in different directories including an MSI.

I'm under the impression I can create a container or payloadgroup that contains all these files. Once in a container, I can then include it in the chain and execute the setup. That is where heat came in. I wanted it to traverse the tree and give me a container with all the files. But only -generate component works (not container nor payloadgroup). If it did, I could probably figure it out from there.

I want this payload to be external from the burn generated bootstrapper (i.e. not compressed) because it will only be installed once, but not for updates.

I've been able to use burn and take the MSI and external files it needs to a payloadgroup and create a standalone bootstrapper. I can then add this into the chain (I have five other packages chained that work great!!!!). However, this introduces other issues (multiple UACs), another line item in the installed product list among other issues. I can also add it as a chain internal to the bootstrapper, but this doubles the size of my install for something that may not be needed. Thus, it is close to what I need.

Suggestions?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

Bob Arnson-6
On 25-Oct-11 13:51, David L. Beckwith wrote:
> Basically, I have a legacy install program that I would like chained.
> Specifically, it is Microsoft's Point of Service for dotNet. There is
> no "ClickOnce" install, instead it is delivered as a self extracting
> zip. It has a setup bootstapper with a scad full of files in different
> directories including an MSI. I'm under the impression I can create a
> container or payloadgroup that contains all these files.

You want a package group (which contains the MSI and payload files). If
you want, you can include the package group in a container (a single
file that contains all the packages/payloads). But containers are just a
delivery mechanism; they're not involved in how a package is installed.

> That is where heat came in.

I don't think Heat has been updated to harvest files for a bundle. But
it's not clear to me that you need it. The WiX binder will automatically
"harvest" the loose files that an .msi refers to. So try a PackageGroup
with an MsiPackage child that points to the POS .msi. Use
PackageGroupRef in your Chain to include the package in the chain. If
you want a container, use PackageGroupRef to include the POS package
group into the container.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
OK, I'm now able to create a detached container. How awesome!

Any suggested file extension to use? Is it a cab file?

But I don't have the install working yet. It seems not all "loose files" were harvested. Those in sub-directories were caught but those in the same directory as the msi were not. Is there an option for this? I tried to create a PayLoadGroup with each Payload and then add this PayloadGroupRef into the PackageGroup with no luck. The "Layout" option prompts for the missing files so it thinks they should be included.

Bob Arnson-6 wrote
On 25-Oct-11 13:51, David L. Beckwith wrote:
> Basically, I have a legacy install program that I would like chained.
> Specifically, it is Microsoft's Point of Service for dotNet. There is
> no "ClickOnce" install, instead it is delivered as a self extracting
> zip. It has a setup bootstapper with a scad full of files in different
> directories including an MSI. I'm under the impression I can create a
> container or payloadgroup that contains all these files.

You want a package group (which contains the MSI and payload files). If
you want, you can include the package group in a container (a single
file that contains all the packages/payloads). But containers are just a
delivery mechanism; they're not involved in how a package is installed.

> That is where heat came in.

I don't think Heat has been updated to harvest files for a bundle. But
it's not clear to me that you need it. The WiX binder will automatically
"harvest" the loose files that an .msi refers to. So try a PackageGroup
with an MsiPackage child that points to the POS .msi. Use
PackageGroupRef in your Chain to include the package in the chain. If
you want a container, use PackageGroupRef to include the POS package
group into the container.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
David L. Beckwith wrote
OK, I'm now able to create a detached container. How awesome!

Any suggested file extension to use? Is it a cab file?

But I don't have the install working yet. It seems not all "loose files" were harvested. Those in sub-directories were caught but those in the same directory as the msi were not. Is there an option for this? I tried to create a PayLoadGroup with each Payload and then add this PayloadGroupRef into the PackageGroup with no luck. The "Layout" option prompts for the missing files so it thinks they should be included.
Maybe my enthusiasm about making a detached container was premature.

Once a detached container is created, how do you reference it? I added a ContainerRef in the in the bundle, but how do I get the payload into the chain from the container? Do I create the container with one project and suck it in as a Payload source file in another?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

Bob Arnson-6
In reply to this post by David L. Beckwith
On 26-Oct-11 12:48, David L. Beckwith wrote:
> Any suggested file extension to use? Is it a cab file?

It is, though that's an implementation detail.

> But I don't have the install working yet. It seems not all "loose files"
> were harvested.

Only those referenced in the .msi would be automatically included. Are
they actually used?

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

Bob Arnson-6
In reply to this post by David L. Beckwith
On 26-Oct-11 16:15, David L. Beckwith wrote:
> Once a detached container is created, how do you reference it? I added
> a ContainerRef in the in the bundle, but how do I get the payload into
> the chain from the container? Do I create the container with one
> project and suck it in as a Payload source file in another?

Containers aren't part of a chain; they're just a delivery mechanism.
Packages are part of a chain, so use PackageGroupRef in your Chain.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
In reply to this post by Bob Arnson-6

Bob Arnson-6 wrote
On 26-Oct-11 12:48, David L. Beckwith wrote:

> But I don't have the install working yet. It seems not all "loose files"
> were harvested.

Only those referenced in the .msi would be automatically included. Are
they actually used?
Yes, two critical files are used by a custom action in the msi but I never see an entry when I look at the msi through orca. So I understand how this could be missed. It gives the following error in the logs:

*** C:\Microsoft POS for dotNET\bin\Release\PidGenX.dll
*** Could not load PidGenX.dll

If I copy them to the target folder it works fine:

PidGenX.dll
PidGenX.xrm-ms

I entered two payloads within the PackageGroup for the MsiPackage.

<Payload Compressed="yes" SourceFile="C:\Microsoft POS for dotNET\Source\PidGenX.dll" />
<Payload Compressed="yes" SourceFile="C:\Microsoft POS for dotNET\Source\PidGenX.xrm-ms" />

What is even weirder, is /layout pulls them out in the correct folder. They also show up in the ProgramData\Package Cache\GUID folder just fine.

There must be something with the cache. I've tried both yes and no cache on the MsiPackage. But no difference.

Again, if I copy these two files to the bootstrap app, it works fine.

I have to be missing something obvious.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
In reply to this post by Bob Arnson-6
Bob Arnson-6 wrote
On 25-Oct-11 13:51, David L. Beckwith wrote:
> Basically, I have a legacy install program that I would like chained.
> Specifically, it is Microsoft's Point of Service for dotNet. There is
> no "ClickOnce" install, instead it is delivered as a self extracting
> zip. It has a setup bootstapper with a scad full of files in different
> directories including an MSI. I'm under the impression I can create a
> container or payloadgroup that contains all these files.

You want a package group (which contains the MSI and payload files). If
you want, you can include the package group in a container (a single
file that contains all the packages/payloads). But containers are just a
delivery mechanism; they're not involved in how a package is installed.
How do I take that detached container and use it in burn?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

Bob Arnson-6
In reply to this post by David L. Beckwith
On 26-Oct-11 22:57, David L. Beckwith wrote:
> What is even weirder, is /layout pulls them out in the correct folder.
> They also show up in the ProgramData\Package Cache\GUID folder just fine.

If Burn's putting them in the same relative place as they were
originally, there must be something peculiar with the MSI.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World&#153; now supports Android&#153; Apps
for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
Bob Arnson-6 wrote
On 26-Oct-11 22:57, David L. Beckwith wrote:
> What is even weirder, is /layout pulls them out in the correct folder.
> They also show up in the ProgramData\Package Cache\GUID folder just fine.

If Burn's putting them in the same relative place as they were
originally, there must be something peculiar with the MSI.
Yes, the MSI is peculiar. I think it assumes it is run from the same folder. Since the Burn bootstapper is cached in a different folder than the MSI, the custom action is looking for the dlls in the the bootstrapper folder, not the MSI folder (is my theory). This isn't my MSI but the Microsoft Point of Service for .NET setup which hasn't had action since 2008. Thus, I have to find a solution around its peculiarities.

Is there any way to have the two dlls (payloads) placed in the bootstrapper application cache? Or is there a way to tell the bootstrapper to start in the MSI folder?  I could have a bootstapper call a bootstapper but that messes up the ARP.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

robmen
Add Payload elements under the MsiPackage element to manually add files
that are not described in the MSI file itself.

On Mon, Oct 31, 2011 at 6:09 AM, David L. Beckwith <[hidden email]
> wrote:

>
> Bob Arnson-6 wrote:
> >
> > On 26-Oct-11 22:57, David L. Beckwith wrote:
> >> What is even weirder, is /layout pulls them out in the correct folder.
> >> They also show up in the ProgramData\Package Cache\GUID folder just
> fine.
> >
> > If Burn's putting them in the same relative place as they were
> > originally, there must be something peculiar with the MSI.
> >
> Yes, the MSI is peculiar. I think it assumes it is run from the same
> folder.
> Since the Burn bootstapper is cached in a different folder than the MSI,
> the
> custom action is looking for the dlls in the the bootstrapper folder, not
> the MSI folder (is my theory). This isn't my MSI but the Microsoft Point of
> Service for .NET setup which hasn't had action since 2008. Thus, I have to
> find a solution around its peculiarities.
>
> Is there any way to have the two dlls (payloads) placed in the bootstrapper
> application cache? Or is there a way to tell the bootstrapper to start in
> the MSI folder?  I could have a bootstapper call a bootstapper but that
> messes up the ARP.
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-generate-tp6909632p6948101.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World&#153; now supports Android&#153; Apps
> for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
RSA&reg; Conference 2012
Save &#36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
I've created two payloads in the MsiPackage element and it places them in the same folder (cache) as the msi. This works as expected.

However, the resulting bootstrapper exe is not placed in the same cache and thus runs from a different folder. The custom action in the MSI looks for the two files in the local or working folder and instead they are in the msi folder. There doesn't seem to be a method to place the payloads in the same cache (folder) as the bootstrapper.

Obviously the best solution would be to change the contents of the msi, but this is a redist from Microsoft which I don't have the right to do and Microsoft has not been actively working on this since 2008.

I see four options:

1. Have the bootstapper change the working directory to the msi folder (cache),
2. Place the  payloads in the bootstrapper folder (cache),
3. Place the bootstrapper in the same folder as the msi.
4. Create a bootstrapper with an ExePackage including the two payloads to another bootstapper with the MsiPackage.

I think the fourth option would work but would end up with confusing multiple UACs and multiple ARP entries. The other three would be desirable options but I don't know how to do it if it were possible.
Rob Mensching-7 wrote
Add Payload elements under the MsiPackage element to manually add files
that are not described in the MSI file itself.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

robmen
I'm a little confused. Are you saying the custom action is using the
current working folder to find files? If so, that won't work out most of
the time or rather it will work in very limited situations.
If you want Payloads cached with the bootstrapper, you can add additional
Payload elements under the BootstrapperApplication element. If you don't
want them compressed mark them Compressed="no".
On Tue, Nov 1, 2011 at 7:19 AM, David L. Beckwith
<[hidden email]>wrote:

> I've created two payloads in the MsiPackage element and it places them in
> the
> same folder (cache) as the msi. This works as expected.
>
> However, the resulting bootstrapper exe is not placed in the same cache and
> thus runs from a different folder. The custom action in the MSI looks for
> the two files in the local or working folder and instead they are in the
> msi
> folder. There doesn't seem to be a method to place the payloads in the same
> cache (folder) as the bootstrapper.
>
> Obviously the best solution would be to change the contents of the msi, but
> this is a redist from Microsoft which I don't have the right to do and
> Microsoft has not been actively working on this since 2008.
>
> I see four options:
>
> 1. Have the bootstapper change the working directory to the msi folder
> (cache),
> 2. Place the  payloads in the bootstrapper folder (cache),
> 3. Place the bootstrapper in the same folder as the msi.
> 4. Create a bootstrapper with an ExePackage including the two payloads to
> another bootstapper with the MsiPackage.
>
> I think the fourth option would work but would end up with confusing
> multiple UACs and multiple ARP entries. The other three would be desirable
> options but I don't know how to do it if it were possible.
>
> Rob Mensching-7 wrote:
> >
> > Add Payload elements under the MsiPackage element to manually add files
> > that are not described in the MSI file itself.
> >
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-generate-tp6909632p6951834.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> RSA&reg; Conference 2012
> Save &#36;700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
RSA&reg; Conference 2012
Save &#36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
Yes, unfortunately that is what the custom action in the msi is doing.

I could have sworn I tried the payloads under the BootstapperApplication element, but I'll check again.

Rob Mensching-7 wrote
I'm a little confused. Are you saying the custom action is using the
current working folder to find files? If so, that won't work out most of
the time or rather it will work in very limited situations.
If you want Payloads cached with the bootstrapper, you can add additional
Payload elements under the BootstrapperApplication element. If you don't
want them compressed mark them Compressed="no".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
David L. Beckwith wrote
Yes, unfortunately that is what the custom action in the msi is doing.

I could have sworn I tried the payloads under the BootstapperApplication element, but I'll check again.

Rob Mensching-7 wrote
I'm a little confused. Are you saying the custom action is using the
current working folder to find files? If so, that won't work out most of
the time or rather it will work in very limited situations.
If you want Payloads cached with the bootstrapper, you can add additional
Payload elements under the BootstrapperApplication element. If you don't
want them compressed mark them Compressed="no".
I remember why this did not work. The dlls need to be in the location of the bootstrapper, not the cache location. Argh!

I've given up this approach. The real solution here is a change in the MSI which I have no control. Another possibility is to use the bootstrapper that comes with this install which I suspect changes the working directory. I tried this a while ago but couldn't figure out how to create folders and designate which payload goes to what folder for burn. I also wasn't sure if an msi payload would be harvested like it is in an msiPackage.

The other four chained packages work great!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Heat -generate

David L. Beckwith
OK, I'm back where I started. Basically, heat does not create a PayloadGroup with "-generate". If that option was available this thread would probably not be here. The help says:

"Specify what elements to generate, one of: components, container, payloadgroup, layout (default is components)."

However, it only produces components. The default is the only option which means there is no option.

So here is my next harvest question...

I know the external files are automatically harvested in the msiPackage element. Is there a way to get this from heat? Or is there an option with dark? I'm at that point where I manually created payloads that the legacy setup needs. It  includes an msi that needs 135 other external files. It is error prone attempting to do this by hand at the least and a chore regardless.

David L. Beckwith wrote
David L. Beckwith wrote
Yes, unfortunately that is what the custom action in the msi is doing.

I could have sworn I tried the payloads under the BootstapperApplication element, but I'll check again.

Rob Mensching-7 wrote
I'm a little confused. Are you saying the custom action is using the
current working folder to find files? If so, that won't work out most of
the time or rather it will work in very limited situations.
If you want Payloads cached with the bootstrapper, you can add additional
Payload elements under the BootstrapperApplication element. If you don't
want them compressed mark them Compressed="no".
I remember why this did not work. The dlls need to be in the location of the bootstrapper, not the cache location. Argh!

I've given up this approach. The real solution here is a change in the MSI which I have no control. Another possibility is to use the bootstrapper that comes with this install which I suspect changes the working directory. I tried this a while ago but couldn't figure out how to create folders and designate which payload goes to what folder for burn. I also wasn't sure if an msi payload would be harvested like it is in an msiPackage.

The other four chained packages work great!
12
Loading...