[wix-users] Managed Bootstrapper: Error 0x80070002: Failed while prompting for source
Phill Hogland
phill.hogland at rimage.com
Thu Apr 21 13:25:56 PDT 2016
>>Also, you mentioned saving to a VM class. Hyper-V or VMWare?
Sorry, I think the thread that I responded to was talking about implementing this in a MVVM managed BA, so my VM class is my ViewModel class, the glue code between the View and the Model. Since I originally used the WiX src\Setup\WixBA as guidance for implementing my MVVM BA (although now it is quite different) you look at InstallationViewModel in WiXBA as the VM I was referring to. (So I was not talking about Hyper-V although today I feel like I am under water trying to figure out a Hyper-V problem with creating a test VM of Win10 and Sysprep.)
It has been a while since I worked on this, but I have a package which may or may not in the middle of the chain, need to do a reboot before the subsequent packages can be installed (NetFx3, which I hope to eliminate soon). And in the CA if I detect the scenario where a forced rebot in the middle of the chain is needed, then the CA calls:
WcaDeferredActionRequiresReboot();
Over in the BA, and particularly in the InstallationViewModel class of my MVVM BA, I have both a Startup and a Shutdown handlers as follows:
private void Startup(object sender, Microsoft.Tools.WindowsInstallerXml.Bootstrapper.StartupEventArgs e)
{
this.AfterForcedRestartPackage = String.Empty;
if ((myBA.Model.Wix.Command.Resume == ResumeType.Reboot) && (LaunchAction.Uninstall < myBA.Model.Wix.Command.Action))
{
this.AfterForcedRestartPackage = myBA.Model.Wix.Engine.StringVariables[LITERALS.WixBundleForcedRestartPackage];
}
}
private void Shutdown(object sender, Microsoft.Tools.WindowsInstallerXml.Bootstrapper.ShutdownEventArgs e)
{
if (this.IvmRestartRequired)
{
if (this.AutoAllowRestart)
{
e.Result = Result.Restart;
}
}
}
So if the CA signals to the mba that it needs a reboot, in the ExecutePackageComplete hanler I look for just this package which has the CA that may need to call for a mid-chain reboot, and if it happens I clear the atom and signal Burn to restart. IIRC Burn automatically populates the WixBundleForcedRestartPackage with the name of the package which was running when the restart was signaled. The ExecutePackageComplete code looks like this
private void ExecutePackageComplete(object sender, ExecutePackageCompleteEventArgs e)
{
....other stuff
// For the SomePackage package, we may need to do a forced reboot. Process whether forced reboot is allowed in ApplyComplete
if (true == e.PackageId.IsContained(@"SomePackage")) //I test for the base portion of the package name SomePackage_x64 or SomePackage_x86, etc
{
// If the CA indicated a reboot is required, then restartAtom will be a possitive integer.
ushort restartAtom = NativeInterOpCalls.GlobalFindAtom("WcaDeferredActionRequiresReboot");
if (restartAtom > 0)
{
NativeInterOpCalls.GlobalDeleteAtom(restartAtom);
e.Result = Result.Restart;
}
}
Then to answer your question when the restart happens, Burn passes in the name of the package that was being executed when the reboot was requested, the Startup handler saves that information, and then Burn, after the Detect phase does a Plan stage where that information is used to skip over the early part of the chain that was already installed successfully (which for me is in a helper function called from the PlanPackageBegin handler
// After a forced restart, we need to skip packages before (including the package which caused the restart).
if (false == string.IsNullOrEmpty(this.AfterForcedRestartPackage) && false == string.IsNullOrWhiteSpace(this.AfterForcedRestartPackage))
{
if (PackageId.Equals(this.AfterForcedRestartPackage, StringComparison.OrdinalIgnoreCase))
{
// Do not allow repair as that could result in a perpetual restart
if (RequestState.Repair == plannedState)
{
plannedState = RequestState.None;
}
this.AfterForcedRestartPackage = String.Empty; //signal no more skipping packages
}
else // skip this package
{
plannedState = RequestState.None;
}
return plannedState;
}
Here is a related post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-restore-after-reboot-not-working-td7585217.html
I saw some of these posts and studied th WiXStdBA, which has this behavior, to try and figure it out. But my memory of some of the intricate details is getting harder to recall.
I hope this helps
Phill
________________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of John Cooper <JoCooper at jackhenry.com>
Sent: Thursday, April 21, 2016 10:15:37 AM
To: WiX Toolset Users Mailing List
Subject: Re: [wix-users] Managed Bootstrapper: Error 0x80070002: Failed while prompting for source
So, it sounds like WixBundleForcedRestartPackage is persisted somehow since it is "reset on the next call to apply." What is the advantage of AfterForcedRestartPackage? Trying to understand the subtlety here.
Also, you mentioned saving to a VM class. Hyper-V or VMWare? We have hundreds of millions invested in VMWare, so we're not likely to switch. Would like to figure out how to persist for our hosting case. Finally many of our clients have actual hardware. What do you do in this case?
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoCooper at jackhenry.com
-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Phill Hogland
Sent: Monday, April 4, 2016 8:26 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Managed Bootstrapper: Error 0x80070002: Failed while prompting for source
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
Glad it helped. I knew there was a way to set the local source, but I did not need to implement that. Regarding skipping components, you might search the old nabble.com wix-users list for information on taking a reboot in the middle of a chain. Also the WixStdBA supports taking a reboot in the middle of a chain. So I used both approaches to implement taking the reboot in the middle of a chain in my mvvm mba. I am not sure that I can detail all of the points now, but I point this out because it envolves in saving the name of the package that needs the reboot, rebooting, and then on reentry skipping the part of the plan that had already been executed. While you are trying to do something different, I just thought that this last part might be helpful in your scenario.
In a very brief nutshell, in the CA for the package that may need the immediate reboot, I use the WcaDeferredActionRequiresReboot global atom to signal the mba that the CA needs an immediate reboot. In the mba in PakageComplete if I am completing the packageId that may need this reboot I use GlobalFindAtom to check for the above atom (and if I find it delete it) and return Result.Restart.
In ApplyComplete after determining if restart is allowed (see the WixStdBA to figure out this implementation) and if the user blesses a reboot I return Result.Restart
Then in a Startup handler I read the Burn variable WixBundleForceRestartPackage, and save that in a member Property of my VM class.
My InstalltionViewModel class has a AfterForcedRestartPackage property in which I store the packageId for the last package in the chain that was processed, prior to doing the reboot in my case. Then in PlanPackageBegin if this member Property is not empty, I know I need to skip past the portion of the plan already completed (by returning RequestState.None) and start processing the packageid that comes after the packagId that was stored by the forced reboot.
So in this process I did not reset the plan as you are doing, but I skipped over the part of the plan that was already processed. And I think you could do the same and then for the 'new' (to the plan items return a RequestState in PlanPackageBegin that indicates what you want the plan to be.
Sorry for the lack of detail but that is all I can pull together at the moment. I hope this helps.
________________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Farrukh Waheed <farrukh1 at gmail.com>
Sent: Saturday, April 2, 2016 12:00 AM
To: WiX Toolset Users Mailing List
Subject: Re: [wix-users] Managed Bootstrapper: Error 0x80070002: Failed while prompting for source
Hey Phill,
In my scenario, nothing would be downloaded. And I got the hint from your snippet, which has succeeded partially, i.e. In ResolveSource, I called Engine.SetLocalSource(), then called Engine.Detect(). This would reset all searches, etc, etc and would re-initiate the Add/Remove/Uninstall/Repair session with updated path in SetLocalSource. And this is working fine now.
Rest is, I have to struggle a little to hide the restart of session and continue the screen from where user selected new component (or if de-selected any), i.e. I guess PlantAction(LaunchAction.Install). That I almost figured-out where this would be injected, just have to drown into code again (its MVVM :( actually )
Thanks a bunch for your effort..
Regards
On 30 March 2016 at 18:38, John Cooper <JoCooper at jackhenry.com> wrote:
> Interesting piece of code. I was running into problems accessing an
> executable in the bundle payload. I ultimately had to take another
> tack to get the path to my IIS daemon.
>
> --
> John Merryweather Cooper
> Senior Software Engineer | Integration Development Group | Enterprise
> Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS
> 66214 | Ext: 431050 | JoCooper at jackhenry.com
>
>
>
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On
> Behalf Of Phill Hogland
> Sent: Wednesday, March 30, 2016 8:30 AM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Subject: Re: [wix-users] Managed Bootstrapper: Error 0x80070002:
> Failed while prompting for source
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> I am not sure that I really follow the original question, and I do run
> on Wix 3.10.2 and do not have any problem modifying the source for my
> MSI packages. while e.LocalSource and e.DownloadSource are read only,
> I parse those values and other information and if I need to change the
> source in Resolve source I call Engine.SetDownloadSource followed by
> returning Result.Download.
>
> Here is a snippet of the last part of my ResolveSource handler (which
> I originally based on code similar to
> WixBA::InstallationViewModel::ResolveSource. After I have determined
> if I need to change the download URL I do the following (which may be
> different than what the OP is doing since my MSI packages are staged
> to a web server similar to the WixBA, and I suspect he is using a local embedded container).
>
> if (!fIsBundle && need_to_chang_url_to_value_of_downloadURL)
> {
> try
> {
> // Throws exception when called on a bundle with
> either a ContainerId and PayloadId is provided
>
> myapp.Engine.SetDownloadSource(e.PackageOrContainerId,
> e.PayloadId, downloadUrl.ToString(), String.Empty, String.Empty);
> }
> // Since now we test for !fIsBundle this exception
> should not happen.
> catch (InvalidOperationException ex)
> {
> ....log the exception
> }
> catch (ArgumentException ex)
> {
> ....log the exception
> }
> }
> //use e.PayloadId as the downloadRetries Dicionay index,
> unless it is null. For packages (or containers) e.PayloadId and
> e.PackageOrContainer are the same value.
> string packageContainerPayloadId =
> String.IsNullOrEmpty(e.PayloadId) ? e.PackageOrContainerId :
> e.PayloadId;
>
>
> this.downloadRetries.TryGetValue(packageContainerPayloadId,
> out this.retries);
> this.downloadRetries[packageContainerPayloadId] =
> this.retries
> + 1;
> e.Result = this.retries < this.RetriesMaxLimit && (null !=
> downloadUrl) ? Result.Download : Result.Ok;
> }
>
> Not an expert and I may not understand the issue, but I hope this helps.
> My mba/the Burn Engine downloads only the packages that it needs at
> install time, and Burn caches the bundle. Later I also allow the user
> to launch and modify selecting a msi that may not have been selected,
> and it installs as expected using the downloadURL to locate the package.
>
> ________________________________________
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of
> John Cooper <JoCooper at jackhenry.com>
> Sent: Wednesday, March 30, 2016 8:08 AM
> To: WiX Toolset Users Mailing List
> Subject: Re: [wix-users] Managed Bootstrapper: Error 0x80070002: Failed
> while prompting for source
>
> In WiX 3.10.2 and later, you're going to have problems the bundle like
> that. You're getting ACCESS DENIED.
>
> --
> John Merryweather Cooper
> Senior Software Engineer | Integration Development Group | Enterprise
> Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS
> 66214 |
> Ext: 431050 |JoCooper at jackhenry.com
>
>
>
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On
> Behalf Of Farrukh Waheed
> Sent: Wednesday, March 30, 2016 7:15 AM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Subject: [wix-users] Managed Bootstrapper: Error 0x80070002: Failed
> while prompting for source
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> Hi Experts,
> I'm delivering 3 msi packages in my Managed Bootstrapper (MBA). User
> is given choice to select which packages he/she wants to install. All
> goes well. When user tries to Modify the installation from Control
> Panel, selects new package from dialog and original source (MBA.exe)
> is missing, installation failed with following log:
>
> [553C:0A88][2016-03-30T16:00:54]w341: Prompt for source of container:
> WixAttachedContainer, path:
> D:\work\MBA.Install.Bundle\bin\Debug\MBA.exe
> [553C:0A88][2016-03-30T16:00:54]e054: Failed to resolve source for file:
> D:\work\MBA.Install.Bundle\bin\Debug\MBA.exe, error: 0x80070002.
> [553C:0A88][2016-03-30T16:00:54]e000: Error 0x80070002: Failed while
> prompting for source (original path
> 'D:\work\MBA.Install.Bundle\bin\Debug\MBA.exe').
> [553C:0A88][2016-03-30T16:00:54]e311: Failed to acquire container:
> WixAttachedContainer to working path:
>
> C:\Users\Me\AppData\Local\Temp\{1338381A-F85F-4B6D-83EA-A0A2D1A369C1}\
> 10A35D6D6CAC04B3DC248033B1588CBD67AD698B,
> error: 0x80070002.
> [553C:0A88][2016-03-30T16:00:54]i000: CachePackageComplete:
> Pkg_Id=EMS.Server Resulted=None
> [553C:0A88][2016-03-30T16:00:54]i000: CacheComplete:
> Status=-2147024894
> [553C:3C24][2016-03-30T16:00:54]e000: Error 0x80070002: Failed while
> caching, aborting execution.
>
> I've tried to capture this in ResolveSource event handler.
> e.LocalSource and e.DownloadSource are readonly properties. There is
> not criteria to download missing file, all needs to be present locally.
>
> I read about the Propmpt to get the Source of original installer here:
>
> https://blogs.msdn.microsoft.com/heaths/2007/10/25/resolvesource-requi
> res-source/
>
> but this is about msi installer, while in my MBA, this dialog is
> suppressed.
>
> How can I take set the LocalSource manually (may be by taking input
> via dialog from user)?
> Can I set WixAttachedContainer to some other working path at runtime
> but taking input from user?
>
> Thanks a bunch...
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> 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 Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> 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 Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
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 Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users
mailing list