I currently have a working .msi built with WiX that has a user interface I'm quite happy with. The only thing missing is to detect for missing .NET 4.5 and either:
Install it using an embedded web setup, or
Direct the user to the .NET 4.5 download
The previous Setup and Deployment project I was using simply added it as a LaunchCondition with a URL and that worked well enough.
How can I add this to the WiX installer without resorting to a bootstrapper. From what I can tell using a bootstrapper like burn would require re-implementing a new user interface, likewise a tool like dotNetInstaller would also introduce a new UI.
If I can have the bootstrapper not implement it's own UI but trigger the .NET installation then open the msi's current user interface that would also work for me.
This is the code I ended up using... hasn't been through full testing yet!
Product.wxs:
...
<!-- custom actions -->
<InstallUISequence> <!-- .NET dialog runs only in UI mode and we skip it on the wrong platform so platform condition test is triggered later -->
<?if $(var.Platform) = x64 ?>
<Custom Action="InstallCA" Before="LaunchConditions">(NOT REMOVE~="ALL") AND NOT (Installed OR NETFRAMEWORK45) AND VersionNT64</Custom>
<?elseif $(var.Platform) = x86 ?>
<Custom Action="InstallCA" Before="LaunchConditions">(NOT REMOVE~="ALL") AND NOT (Installed OR NETFRAMEWORK45) AND NOT VersionNT64</Custom>
<?endif?>
</InstallUISequence>
</Product> <!-- end product -->
<Fragment>
<Binary Id="WiXCustomActions" SourceFile="$(var.WiXCustomActions.TargetDir)$(var.WiXCustomActions.TargetName).CA.dll" />
<CustomAction Id="InstallCA" BinaryKey="WiXCustomActions" DllEntry="DotNetCheck" Execute="firstSequence" />
</Fragment>
And the custom action (in a C# class library):
[CustomAction]
public static ActionResult DotNetCheck(Session session)
{
try
{
MessageBoxResult result = System.Windows.MessageBox.Show(
"This application requires that .NET Framework 4.5 is installed." + Environment.NewLine
+ "Would you like to open the Microsoft download page for" + Environment.NewLine + ".NET Framework 4.5?",
".NET Framework 4.5 is missing",
MessageBoxButton.YesNo, MessageBoxImage.Information, MessageBoxResult.No, MessageBoxOptions.DefaultDesktopOnly);
switch (result)
{
case MessageBoxResult.Yes:
System.Diagnostics.Process.Start("http://go.microsoft.com/fwlink/p/?LinkId=245484");
break;
} //else just finish
}
catch (Exception ex)
{
session.Log("Error. " + ex.Message);
System.Windows.MessageBox.Show("Error:" + ex.Message);
}
return ActionResult.SkipRemainingActions;
}
It works good enough for me...
I also wanted to keep the UI from the MSI so I added this code to start an exe installer for hardware keys. I know it goes against MSI Best Practices but this is the only one I intend on breaking. Hope this helps.
<Property Id="WixShellExecTarget" Value="[#myapplication.exe]" />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" Impersonate="yes" />
I then ran the custom action from a button click. You could spawn an error dialog with a download button on it and link it via that. Not very elegant at all but it works for me and my company as a work around..:)
EDIT: you could also use this code from a button click to launch the URL for the download, the Value attribute having the full hyperlink.
And one important things, when you will be creating this DLL lib
And the custom action (in a C# class library):
Need to add next References:
using WixSharp
using Microsoft.Deployment.WindowsInstaller
using System.Windows.Forms
also replace "MessegeBoxResult" to "DialogResult" and MessegeBox should get from class System.Windows.Forms
Related
My first question is about the error below :
Module [Path/Name of dll].dll failed to register. HRESULT -2147024769. Contact your support personnel.
I can continue the installation but i want to get rid of this error if possible.
The second question is about the following error :
Error 1001. Exception occured when initializing the installation.
System.IO.FileNotFoundException: could not load file or assembly 'file:///C:\Windows\SysWOW64\files' or one of it's dependencies. The system cannot find the file specified.
I saw in different site and thread that the cause was the custom Action (in the value : /target=”[TARGETDIR]” -> /target=”[TARGETDIR]\”) but I can't found where is the error in my custom action. Here are the custom action realized using Designer for Wix Toolset :
<CustomAction Id="DIRCA_TARGETDIR" Property="TARGETDIR" Value="[ProgramFilesFolder][Manufacturer]\[ProductName]" Execute="firstSequence" />
<CustomAction Id="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall" Execute="deferred" BinaryKey="InstallUtil" DllEntry="ManagedInstall" adx:VSName="Primary Output from Project" />
<CustomAction Id="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall.SetProperty" Property="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall" Value="/installtype=notransaction /action=uninstall /LogFile= /targ="[TARGETDIR]\" /usr=[ALLUSERS] /usr2=[MSIINSTALLPERUSER] /CommonProjAppData="[PROJCOMMONDATA]\" "[#_F521D169_ECD0_42B5_87F7_C2D8B6F9CA54]" "[VSDFxConfigFile]"" adx:VSName="Primary Output from Project" />
<CustomAction Id="_BE73DAD9_3524_4376_B45C_148B5871465B.Install" Execute="deferred" BinaryKey="InstallUtil" DllEntry="ManagedInstall" adx:VSName="Primary Output from Project" />
<CustomAction Id="_BE73DAD9_3524_4376_B45C_148B5871465B.Install.SetProperty" Property="_BE73DAD9_3524_4376_B45C_148B5871465B.Install" Value="/installtype=notransaction /action=install /LogFile= /targ="[TARGETDIR]\" /usr=[ALLUSERS] /usr2=[MSIINSTALLPERUSER] /CommonProjAppData="[PROJCOMMONDATA]\" "[#_F521D169_ECD0_42B5_87F7_C2D8B6F9CA54]" "[VSDFxConfigFile]"" adx:VSName="Primary Output from Project" />
<CustomAction Id="CA_CreateConfig" BinaryKey="ADXDPCADLL" DllEntry="GetConfig" />
Thanks for helping.
You're basically going in the wrong direction. You've converted a Visual Studio setup to WiX but you're trying to carry that VS custom action framework into WiX. The VS framework that calls managed code custom actions involves calling a C++ binary that then tries to load a NET runtime then use reflection to get into your assembly, instantiate classes and call methods. Apart from the fact that the InstallUtil Dll is transparent, undocumented and architecture dependent (you need either the 64-bit version or the 32-bit version) and therefore impossible to debug in cases like this, nobody actually bothers to propagate all this stuff into the WiX world because there are much better alternatives. For example if you're using installer classes to install services you don't need them at all. See ServiceInstall and ServiceControl. For generic custom action calls into managed code use the DTF managed code custom action framework.
I'm in a kind of misery. I got an installer installing and starting a tray icon app (common .exe)
This is working properly, but now i want to stop that app before this UI telling the user to close the app manually comes up, because during the deinstall routine, my tray icon is removed but the process is still running.
I applied this custom action to close the app before uninstall (or even during)
<CustomAction Id="CloseTrayApp" ExeCommand="-exit" FileKey="TrayApp" Execute="immediate" Return="asyncNoWait" />
<InstallExecuteSequence>
<Custom Action="CloseTrayApp" Before="InstallValidate" />
</InstallExecuteSequence>
But the "close all running apps" dialog still pops up, but i thought that this will solve my issue.
I already tried to use the CloseAction but i got into a hurry using it because of error while compiling the stuff. It says that the WixUtils namespace may be missing but i double checked that it is there:
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
How can I avoid the dialog window poping up and trigger this custom action to be executed?
You also have to add a reference to WixUtilExtension.dll. If you are using Visual Studio / Votive you just right click add reference and select the DLL from [ProgramFilesFolder]Windows Installer XML v3.5\bin. Otherwise you have to make the extension available to the compiler and linker:
candle.exe yourfile.wxs -ext %full path to WixUtilExtension.dll%'
light.exe yourfile.wixobj -ext %full path to WixUtilExtension.dll% –out yourfile.msi yourfile.wixout'
More information can be found at:
Using Standard Custom Actions
Please note that the CloseApp custom action has a limitation that it won't "terminate" your application. It will only politely send your app a WM_CLOSE message and it's up to your trayapp to receive and process that message with a shutdown.
I've got a custom action I've defined for my installer. The installer doesn't seem to be running.
Here's the lines in the WXS file that define the custom action:
<CustomAction Id="GetConfigProperties" BinaryKey="GetPropertiesDLL" DllEntry="GetPropertiesFromConfigFile" />
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
<Custom Action="NewerVersionDetected" After="FindRelatedProducts">NEWERVERSIONDETECTED</Custom>
<Custom Action="GetConfigProperties" After="FindRelatedProducts"></Custom>
. . .
</InstallExecuteSequence>
<Binary Id="GetPropertiesDLL" SourceFile="$(var.LPRCore Installer CBP Helper.TargetDir)\LPRCore Installer CBP Helper.CA.dll" />
I've checked the MSI with Orca and the appropriate entries are in the MSI's tables.
Here's an excerpt of the code in the CustomActions.cs file:
[CustomAction]
public static ActionResult GetPropertiesFromConfigFile(Session session) {
// Output a start message to the install log
session.Log( "Begin GetPropertiesFromConfigFile" );
. . .
return ActionResult.Success;
}
There are a few other session.Log statements in the code at places where I wanted to see what was going on.
Now, I have logging enabled. When I look at the log file in Notepad, I see no messages from my calls to session.Log. I see no references to GetConfigProperties either. It appears that the custom action is not executing at all. What have I done wrong?
It turns out that the custom action wasn't running because:
It was scheduled to run in the wrong place. My fault, I needed to put it in the InstallUISequence section, not the InstallSequence section.
I was aborting the install before the action could run.
When I put the custom action into the InstallUISequence section and in the right place, everything ran fine.
Thanks for trying.
Tony
In case you don't see any entries of GetConfigProperties custom action in your log file, most likely the reason is that InstallExecutesequence element resides in a separate Fragment, which is not included into the package. To include the contents of the Fragment into the package, you should reference any element in it from inside the Product element.
For instance, you can add the following line to the Product element:
<CustomActionRef Id="GetConfigProperties" />
I think you are missing condition on which custom action should run. Either give some condition <Custom Action="GetConfigProperties" After="FindRelatedProducts">NOT INSTALLED AND NOT REMOVE</Custom> or if you want to make it default then put 1 as condition
<Custom Action="GetConfigProperties" After="FindRelatedProducts">1</Custom>
I'm trying to close a process before uninstallation using Wix. I've confirmed that it works as long as there's a visible window, but if there isn't a visible window (which is the case most of the time with this app since it's a system tray app), the uninstaller just hangs, and eventually continues with the uninstallation, leaving the process running.
According to this forum post, it seems like Wix has had trouble closing minimized apps in the past, so I wonder if this is related?
Any suggestions as to what else I can do to make sure the process gets shut down? Is there any way I can try and capture the message in my app using the Win32 api maybe?
Here's the CloseApplication declaration:
<util:CloseApplication Id="CloseApp" CloseMessage="yes" Target="App.exe" RebootPrompt="yes" />
And here's the custom action:
<Custom Before="InstallInitialize" Action="WixCloseApplications">REMOVE = "ALL"</Custom>
It looks like you are scheduling the WixCloseApplications custom action before the installation transaction. The way the custom action works, is it scheduled a deferred action that actually closes the applications. It can't do that work unless it happens during the transaction (After="InstallInitialize").
The fix is probably pretty easy. Remove the Custom/#Action="WixCloseApplications" element.
At first, don't forget to reference WixUtilExtension.dll assembly.
Also check if Wix element contains definition of UtilExtension namespace:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
I've noticed that you should change your custom action to be executed before InstallInitialize.
<Custom Before="InstallInitialize" Action="WixCloseApplications">REMOVE = "ALL"</Custom>
If you apply those changes and CloseApplications extension doesn't work, try logging installation process using
msiexec /i MyApplication.msi /l*v MyLogFile.txt
I also faced this problem.
Changing the Before attribute to "InstallValidate" worked for me.
<Custom Before="InstallValidate" Action="WixCloseApplications"/>
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.