1

My installer needs to redistribute the .NET framework, but I don't want to have a setup.exe wrapper so I've written a Custom Action to launch the web installer for .NET if the end-users machine does not already have it. This works perfectly fine with .NET 4.0 and .NET 3.5 but for .NET 4.5 the .NET installer reports "waiting for another install to complete" and fails - this error msg would be correct if my Custom Action was in the Exec sequence, but I specifically placed it very early in the UI sequence to allow for a nested installation.

The exact same InstallShield configuration/code works fine with .NET 3.5 and .NET 4.0 but fails with .NET 4.5, I'm using the standard web installer from Microsoft: http://www.microsoft.com/en-ca/download/details.aspx?id=30653

Does anyone know of any solution or workaround to this problem ?

Here's the code for my Custom Action:

if ( hasDotNET45 = FALSE ) then
    MessageBox( "Missing .NET 4.5 framework!", INFORMATION );
    LAAW_SHELLEXECUTEVERB = "runas";
    LaunchApplication( szSupportDir^"\\dotNetFx45_Full_setup.exe", "", "", SW_SHOWNORMAL, 100000, LAAW_OPTION_USE_SHELLEXECUTE | LAAW_OPTION_WAIT_INCL_CHILD );
    Delay( 333 );
endif;
Nothing 2 Lose
  • 180
  • 1
  • 3
  • 8

2 Answers2

2

I'm surprised that .Net 4 and 3.5 even work like this; launching an installer that likely uses MSI under the hood as a custom action in your MSI installer is a bad idea.

If you want to make sure .Net4.5 (or any other piece of software) is present you either need to chain it before you start your installer ala Setup / Feature Prerequisites in Installshield or use the LaunchCondition table to prevent your installer from continuing if environment does not meet requirements.

Community
  • 1
  • 1
NGaida
  • 688
  • 3
  • 10
  • It'll work in a handful of scenarios such as a fully interactive installation running from an elevated command session and the custom action is scheduled in the UI sequence. This breaks all best practices so it's clearly not the way to go. Suite Installers or Setup Prereqs are the correct approach as you mention. – Christopher Painter May 15 '13 at 14:19
  • I've been using this Custom Action approach to deploy my applications Prereqs for a while and never had any problems reported by end-users, so why exactly does this "break all best practices" ? – Nothing 2 Lose May 16 '13 at 15:12
  • This link describes the Microsoft best practices, and specifically mentions this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb204770(v=vs.85).aspx#concurrent_installs – NGaida May 16 '13 at 16:37
2

The solution is to first extract the contents of the .NET 4.5 installer executable using the command: dotnetfx45_full_x86_x64.exe /x

Then I can use a Custom Action in my UI sequence to invoke the .MSI version of the .NET installer (without it's setup.exe wrapper!)

msiexec.exe /i netfx_Full_x64.msi EXTUI=1 /l*v “Install.log”

This fully resolves my original question.

Nothing 2 Lose
  • 180
  • 1
  • 3
  • 8
  • 1
    a custom action that calls an msi is janky... you want to chain the msis – thekbb Dec 14 '13 at 04:12
  • How to chain the msis? – godblessfq Nov 29 '15 at 16:45
  • As it is stated correctly before, MSIs should not be (cannot be easily) nested. But for some reasons a number of people starts prereq MSIs from the user sequence, and this works normally fine. If this is "nesting", depends on the point of view. Main disadvantage is that you can not run this setup silently- you depend on the exact dialog mode. If this is acceptable, I see little reasons to tell all those, this is bad- it is easy and it works. Only some setups like .NET 4.5 do not only test the common MSI mutex, but more. So this workaround of unpacking is necessary here. – Philm Feb 15 '16 at 10:39
  • Talking about chaining- good idea in theory, I have seen a number of setups which tried it and doubled their instability.Chaining is not guaranteed to be hassle-free in my eyes. _Sometimes_ the easiest solution (user sequence custom action) is not bad. At least for setups where simpleness is a point. Of course working with bundle installers like Burn is smarter, but you depend on another tool or/and get complicated dependencies- choose this, if your setup is quite complex already, and you are ready for another tool or dialog level. – Philm Feb 15 '16 at 10:40