I'm writing the custom wpf bootstrap application which installs the .Net framework and redistributables (downloading and installing) but it is skipping the msi package for installation.
Wix code:
Please kindly go through the above wix bundle code
Below is the event for to download the redist and install i have added
void Bootstrapper_ResolveSource(object sender, ResolveSourceEventArgs e)
{
if (!String.IsNullOrEmpty(e.DownloadSource))
{
e.Result = Result.Download;
this.Engine.Log(LogLevel.Verbose, "download source is not empty "+e.DownloadSource);
}
else
{
e.Result = Result.Continue;
}
}
Currently i'm using wix 3.10 version.
Log file :
https://drive.google.com/open?id=0B-iKQhr12DRmVjZzbDE0US1vcm8
Alternate link:
https://drive.google.com/file/d/0B-iKQhr12DRmVjZzbDE0US1vcm8/view
Kindly provide your valuable help for further step.Thanks in advance
From your log:
Detected package: xyz, state: Present, cached: None
Windows Installer detects that the package is already installed.
Related
I have a WiX 3.11-based installer with a managed bootstrapper application. One of the packages in the installer chain could trigger a restart. In my MBA, I handle the resume-from-restart behavior in the PlanPackageBegin event handler, inspired by the standard bootstrapper app:
private void Bootstrapper_PlanPackageBegin(object sender, PlanPackageBeginEventArgs e)
{
// _bootstrapper.Status.ForcedRestartPackage comes from the WixBundleForcedRestartPackage engine variable
if (_bootstrapper.Status.ForcedRestartPackage != null)
{
// Resuming after forced restart
// Skip packages until after the package that forced the restart
e.State = RequestState.None;
if (e.PackageId == _bootstrapper.Status.ForcedRestartPackage)
{
_bootstrapper.Status.ForcedRestartPackage = null;
}
}
else
{
...
}
}
My problem is, if the installer fails to install a package after the restart, it will only rollback the packages that were installed after the restart. If the install fails and starting rolling back, I want it to rollback all installed packages, even ones before the restart. Is there a way that I can configure my bundle or MBA to do this?
There's no way to do this today. The BA has pretty much no control over rollback behavior.
If you're trying to install and want to completely uninstall after the failure, then the BA can choose to uninstall if the user wants to close the installer instead of trying again.
I create my instalator Wix with msi and bootstrapper.
I am do test for update my program. And trying install new version. I want always use bootstrapper. I don't know if this was always the case, but I did some tweaks and added a progress bar to the bootstrapper for MSI installations. And it turns out that when updating, this bar stops at 60/70% and after closing MSI a new bootstrapper window appears. Closing the window a few times causes the progress bar in the first window jump to 100% and I can close the window.
I dont have idea why it happen.
I check logs and in both cases last line looks like:
Applying execute package: Installer, action: Install, path: C:\ProgramData\Package Cache{9428A5CF-824D-42D0-ABF7-BC69D4B8FEE7}v1.0.26.40\EkInstaller.Elements.msi, arguments: ' MSIFASTINSTALL="7" CONFIGFILELOCATION="C:\svn\122\dotNet\products\3_ek-graf-pre-v2\trunk\src\Ek.Installer\Ek.Installer.Bootstrapper\bin\Debug"'
And besides this lines I dont show differents in logs:
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{2e954545-621e-4062-a306-99197563c483}, type: Upgrade, scope:
PerMachine, version: 1.0.24.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{770a1869-f4b5-4307-b05f-1f8be006757b}, type: Upgrade, scope:
PerMachine, version: 1.0.23.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{ff8d8a34-989d-4fb9-9aa7-2ab0440f514d}, type: Upgrade, scope:
PerMachine, version: 1.0.25.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i103: Detected related package:
{D512899C-F7CC-412C-9110-54CDE5BB2741}, scope: PerMachine, version:
1.0.25.40, language: 0 operation: MajorUpgrade
Probably first three are for NetFramework, Sql and SSMS which install bootstrapper and last is for my MSI.
I was trying change InstallerVersion in Package and Schedule in MajorUpgrade.
The installer is very complex, I can't make all the code available. Maybe someone knows the reasons for this behavior and can direct me to why it is.
Noticed when MSI progress bar status = "Delete Files" in then progress bar bootstrapper stop.
Edit:
It spawn additional window bootstrapper for event previous version bootstrapper.
If i dont change version bootstrapper it dont spawn dialog and it goes to 100% normally when updating msi.
Seems to be a wix bug. For each subsequent bootstrapper version installed, new bootstrapper windows appear when the MSI window is closed. You can fix it by following through change UpgradeCode for each new version Bundle. If you additionally set DisableModify = "yes" DisableRemove = "yes" then there will be no additional bootstrapper instances in add / remove program.
I am developing a wix installer. This wix installer installs a 3rdparty msipackage.
I want my wix bootstrapper project to install this msipackage no matter what version that should already exist on the users pc. This means that if the same version(or a newer version) exists it should overwrite that installation.
I install my msipackage like this:
<MsiPackage Id="InstacalFull" Name="Measurement Computing InstaCal" Vital="yes" Compressed="yes" SourceFile="../Suite.SetupBootstrapper/3rdparty/Instacal/InstaCal.msi">
Does anyone have any ideas on how to achieve this?
Use InstallCondition="1"
This will install it every time
http://wixtoolset.org/documentation/manual/v3/xsd/wix/msipackage.html
InstallCondition
String
A condition to evaluate before installing the package. The package will only be installed if the condition evaluates to true. If the condition evaluates to false and the bundle is being installed, repaired, or modified, the package will be uninstalled.
I know this one is old, but since I came across this issue, maybe it would help someone, too.
In my case Repair was enough, so although technically it wasn't reinstall, practically Repair = Reinstall.
I needed to reinstall URLrewrite, because it could get broken when IIS Windows feature was disabled.
What you need it to add custom handler for PlanPackageBegin in you custom BootstrapperApplication class, for example:
CustomBootstrapperApplication.Model.Bootstrapper.PlanPackageBegin += this.PlanPackageBegin;
...........
private void PlanPackageBegin(object sender, PlanPackageBeginEventArgs e)
{
if (e.PackageId.ToLower().Contains("urlrewrite"))
{
if (CustomBootstrapperApplication.Model.Command.Action != LaunchAction.Uninstall && e.State == RequestState.Present)
{
CustomBootstrapperApplication.Model.Engine.Log(LogLevel.Verbose, string.Format("{0} is installed, forcing Repair", e.PackageId));
e.State = RequestState.Repair;
}
}
_packageList.Add(e.PackageId, e.State);
}
And in the the Bundle:
<!-- Note: this Id is used in PlanPackageBegin -->
<MsiPackage Id='urlrewrite2X64' Vital='no'
Permanent='yes'
SourceFile="rewrite_amd64.msi"
DownloadUrl="http://example.com/rewrite_amd64.msi"
DisplayInternalUI="no"
Visible="yes"
InstallCondition="VersionNT64"/>
You can force uninstallation of previous MSI during upgrade by something like this inside PlanPackageBegin:
if (LaunchAction.Uninstall == CustomBootstrapperApplication.Model.Command.Action && (CustomBootstrapperApplication.Model.Command.Relation == RelationType.Upgrade))
{
e.State = RequestState.None;
}
I'm creating a custom wizard-style bootstrapper based on Wix/Burn (3.6 release version). I've based in on the Wix 3.6 bootstrapper code.
The problem is that I cannot get the bootstrapper to detect the install state of my setup.msi that is part of the bundle.
As I understand it, all that's required is to call Engine.Detect(), where Engine is an instance of the Wix Engine from the Bootstrapper Application. At that point I should be able to look in Bootstrapper.Command.Action to see what the required launch action is.
My bundle contains two items: .NET 4 (web install) and my setup.msi.
I suspect that I'm missing a step to determine whether I should put my wizard into maintenance mode vs. install mode.
First, to determine if the package is being detected or not you can check the log files in the temp directory of the current user. It will tell you whether or not the package has been detected.
Now to determine whether or not to go into maintenance mode vs. install mode, you can check the package state by subscribing to the DetectPackageComplete event. In the example below, my UI uses two properties, InstallEnabled and UninstallEnabled to determine what "mode" to present to the user.
private void OnDetectPackageComplete(object sender, DetectPackageCompleteEventArgs e)
{
if (e.PackageId == "DummyInstallationPackageId")
{
if (e.State == PackageState.Absent)
InstallEnabled = true;
else if (e.State == PackageState.Present)
UninstallEnabled = true;
}
}
The code sample above is from my blog post on the minimum pieces needed to create a Custom WiX Managed Bootstrapper Application.
An easy way to determine if your Bundle is already installed is to use the WixBundleInstalled variable. That will be set to non-zero after your Bundle is successfully installed.
Additionally, in WiX v3.7+ the OnDetectBegin callback now tells you if the bundle is installed so you don't have to query the variable normally.
These changes were made to make it easier to detect maintenance mode to avoid the completely reasonable solution that #BryanJ suggested.
I'm trying to create a custom action for my Wix install, and it's just not working, and I'm unsure why.
Here's the bit in the appropriate Wix File:
<Binary Id="INSTALLERHELPER" SourceFile=".\Lib\InstallerHelper.dll" />
<CustomAction Id="HelperAction" BinaryKey="INSTALLERHELPER" DllEntry="CustomAction1" Execute="immediate" />
Here's the full class file for my custom action:
using Microsoft.Deployment.WindowsInstaller;
namespace InstallerHelper
{
public class CustomActions
{
[CustomAction]
public static ActionResult CustomAction1(Session session)
{
session.Log("Begin CustomAction1");
return ActionResult.Success;
}
}
}
The action is run by a button press in the UI (for now):
<Control Id="Next" Type="PushButton" X="248" Y="243" Width="56" Height="17" Default="yes" Text="!(loc.WixUINext)" >
<Publish Event="DoAction" Value="HelperAction">1</Publish>
</Control>
When I run the MSI, I get this error in the log:
MSI (c) (08:5C) [10:08:36:978]: Connected to service for CA interface.
MSI (c) (08:4C) [10:08:37:030]: Note: 1: 1723 2: SQLHelperAction 3: CustomAction1 4: C:\Users\NATHAN~1.TYL\AppData\Local\Temp\MSI684F.tmp
Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action SQLHelperAction, entry: CustomAction1, library: C:\Users\NATHAN~1.TYL\AppData\Local\Temp\MSI684F.tmp
MSI (c) (08:4C) [10:08:38:501]: Product: SessionWorks :: Judge Edition -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action SQLHelperAction, entry: CustomAction1, library: C:\Users\NATHAN~1.TYL\AppData\Local\Temp\MSI684F.tmp
Action ended 10:08:38: SQLHelperAction. Return value 3.
DEBUG: Error 2896: Executing action SQLHelperAction failed.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: SQLHelperAction, ,
Neither of the two error codes or messages it gives me is enough to tell me what's wrong. Or perhaps I'm just not understanding what they're saying is wrong.
At first I thought it might be because I was using Wix 3.5, so just to be sure I tried using Wix 3.0, but I get the same error.
Any ideas on what I'm doing wrong?
For your custom action assembly you need a config file and set the useLegacyV2RuntimeActivationPolicy attribute to true. Make sure you name your config file CustomAction.config. If you don't, it won't work. I am assuming you are running on the .NET 4 Framework.
See here for more info. Also, as AntonyW already pointed out, fuslogvw.exe is very helpful in this scenario.
instead of referencing the .dll reference the .CA.dll, it worked for me.
Custom Actions launched via DoAction are not able to write to the log file.
This confused me as well, when I first started using WiX.
If you want to see what is going on, you can use System.Diagnostics.Debugger.Launch() at the start of the Custom Action. This will prompt you to attach Visual Studio to the process so you can debug it.
For me, it was my CustomAction DllEntry did not match my method name. i.e.
<CustomAction Id="CheckingPID" BinaryKey="CheckPID.CA" DllEntry="BadValue" />
public static ActionResult CheckPID(Session session)
This error comes when you have installer project configuration/platform set to debug/x64 and custom action project configuration/platform set to debug/x86 repectively.
Correct the platform setting to build the projects for same platform
In my case changing platorm solved the issue.
Thanks
Yogesh
One more possible answer - you may have specified the right CA DLL, and specified the right method, but if the method is not decorated with [CustomAction] you will receive that error.
Have you tried changing the runtime library settings on the custom action DLL? The debug mode options /MDd and /MtD require debug versions of the C++ runtime in particular, which are not available on production machines (there is no redistributable license for them). If you use the /MD compiler option you might also need to install the Visual Studio C++ runtime version that you require on the users' machines, there is a merge module for that: C++ Redistributable package with WIX.