4

I use Visual Studio 2010 to create a setup package with .NET Framework 4.0 for my project. I create a custom action using Installer class with DLL built with .NET Framework 4.0. My setup package is installed successfully.

If I remove my package and after that removing .NET Framework 4, everything is ok.

However, If I remove .NET Framework, after that I remove my setup package, I get a error: "1001 InstallUtilLib.dll unknown erro" . I think the reason I can't remove my setup package because msiexec will call my custom action which is Installer class using .NET Framework 4.0 while .NET Framework 4.0 is removed before -> Installer DLL can't be called and return a error ->removing MSI failure.

Please help me how to avoid this error or how to ignore the error code of this custom action. Thanks.

ajay_whiz
  • 17,573
  • 4
  • 36
  • 44
Leo Vo
  • 9,980
  • 9
  • 56
  • 78

3 Answers3

4

You can try this:

Visual Studio doesn't support this directly.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
  • 1
    This awesome solution looks like exactly what I need, except that after changing the value the installer no longer runs. I expect it's due to a failing checksum. Is there any way to disable that check? "Windows Installer This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package." – rfeague Nov 11 '12 at 07:12
1

mrnx's answer helped me, but I thought I would expand on that answer with what I ended up doing. In my case, I was including a driver in multiple programs, where the driver always returns 1 instead of 0.

  1. Based on the mrnx's procedure to open the MSI file and view the CustomAction table, I found that my custom actions all had the type "3090". To set the msidbCustomActionTypeContinue flag, I had to add 64, which meant changing the value to 3154.

  2. Since I wanted to automate this in my build process, I found this Question, which explained how to create an MSI transform. This solution works, but it wasn't portable between projects since the transform would only work for the one MSI file. Instead, I found that a simple VB script called from the setup project post-build step works for various MSI projects: 

Dim msiInstaller
Dim msiDatabase
Dim msiView
Dim pathToMsi

If WScript.Arguments.Count <> 1 Then
    WScript.Echo "Usage:" & vbCrLf & "  " & WScript.ScriptName & " <path-to-msi>"
    WScript.Quit 1
End If

pathToMsi = WScript.Arguments(0)
Set msiInstaller = CreateObject("WindowsInstaller.Installer")

Set msiDatabase = msiInstaller.OpenDatabase(pathToMsi, 1)
Set msiView = msiDatabase.OpenView("UPDATE CustomAction SET Type=3154 WHERE Type=3090")
msiView.Execute msiRecord

msiDatabase.Commit

Usage (set to PostBuildEvent of Project Properties):

"$(ProjectDir)..\patchMsiForDriver.vbs" "$(BuiltOuputPath)"
Community
  • 1
  • 1
6utt3rfly
  • 208
  • 3
  • 4
  • Works perfectly. I was suspicious of the typo in "BuildOuputPath", but no, that's actually what you have to use. Wat. – Chris Olsen Apr 27 '19 at 14:52
1

You can avoid this error by having a launch condition for Framework 4.0, so that when ever the setup is launched (for install or uninstall) it first checks for framework 4.0

ajay_whiz
  • 17,573
  • 4
  • 36
  • 44
  • Launch conditions are not evaluated during uninstall by default (it also applies to Visual Studio setup projects). This is so the user can uninstall the package even if some conditions are not met. – Cosmin May 11 '11 at 12:43
  • @Cosmin you can still make them evaluate during uninstall using orca – ajay_whiz May 12 '11 at 06:25