5

I'm working with a WIX installer and keep getting this error message:

WIX Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run.

Are there any other issues that would cause the 1723 error which are not related to the DLL not being found?

I can say with 100% certainty that the DLL has to be found because previous custom actions in the same installer work and they all use the same DLL.

I had this error before and solved it by renaming the custom action so I assumed it was related to the length of the name allowed for the custom action. This time I have tried both a shorter name and a name the exact length of other working custom actions and still get this error.

I have investigated causes of 1723 and the most common one seems to be that the installer fails to unpack the DLL due to access rights. Although this is very unlikely as other custom actions in the same file referencing the same DLL work fine I have ensured that the folder the installer is trying to access has full access for this user, also I am running the installer from a command prompt in administrator mode so we should have no issues there.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Purplegoldfish
  • 5,268
  • 9
  • 39
  • 59
  • That isn't a WiX toolset error code so I'm a little confused. Are you getting that from the Windows Installer (MSI) during an install? If so can you share out a bit more information about the custom action, what its dependencies are, etc? – Rob Mensching May 07 '13 at 13:25
  • It's not a WIX toolset error, as far as I can tell it is a standard error code for a windows installer not being able to find the DLL. However I'm pretty sure that it is being caused by WIX not building the installer correctly. I think / hope I have just found the cause being an _ in the custom action name. – Purplegoldfish May 07 '13 at 13:48
  • Well, we need more details about how you are including the custom action in your MSI and how the custom action .dll is built to really be of service. – Rob Mensching May 07 '13 at 15:52
  • 1
    Is there a log file? What does it say? Try **[Rob's tool-less log file quick review](http://robmensching.com/blog/posts/2010/8/2/the-first-thing-i-do-with-an-msi-log/)**. For crashing packages I like to add **["flush to log file"](http://www.installsite.org/pages/en/msifaq/a/1022.htm)**: **msiexec.exe /I "C:\Test.msi" /QN /L*V! "C:\msilog.log"** – Stein Åsmul Aug 15 '14 at 14:14

6 Answers6

4

WIX 3.x (more specifically MakeSfxCA) has a known bug of possibly producing incorrect native dll files leading to an error "1723". The bug is triggered depending on the names of the custom actions (the methods decorated with the "CustomAction" attribute).

If you have two custom actions having the same prefix the one followed by a lower case, the other followed by an upper case letter (coming later in the alphabet), you may run into the "1723" error. E.g. two custom actions named "isactive" and "isBlocked" are troublesome.

This has to do with MakeSfxCA incorrectly sorting the entry points of exported methods.

Cf. http://wixtoolset.org/issues/4502 for WIX's issue and Adding a new Custom Action to a project prevents an existing Custom Action from being run for more technical details.

Community
  • 1
  • 1
Hille
  • 4,096
  • 2
  • 22
  • 32
  • Although it says that it is fixed in 3.8/9, I had an issue related to common prefix of the custom actions in 3.10 – Uriel Katz Aug 05 '16 at 20:32
1

I got this error lately and the issue was a DLL dependency. My DLL had other DLL dependencies which were present on my development machine and were not on the target machine were I saw the error. You can check your dependencies with the Dependency Walker http://www.dependencywalker.com to find out if this is the case. That certainly helped me.

user190650
  • 11
  • 1
  • 3
1

We'e spent months to address bloody error 1723.

After decompilation by dumpbin /Exports CustomAction.CA.dll (runnable from visual studio developer tools), there are sorted entries in following manner:

121 78 000039DE Dev*****************
122 79 000039F4 DML*****************
123 80 00003A0A DoN*****************

Assuming that sorting should be done using ASCII it looks like this is incorrect. Big letter M should be before small letter e thus entries 121 and 122 should be replaced.

We've reproduced that issue on Wix 3.9 R2 however on some Windows 7 Ultimate virtual machines issue didn't occur but was reproducible on Windows 7 Enterprise.

For us solution was to change in CustomAction project, name of CustomAction from DML********* to DmL******** making sorting works correctly.

PS: I was trying to give that feedback directly on WiX webpage, however I couldn't register.

henioStraszny
  • 183
  • 1
  • 8
  • Wix used to have an [error](http://wixtoolset.org/issues/4502/) when ordering entries but that is fixed in Wix 3.9 RC3 onward. Can you double-check the wix version, please. For more technical info look [here on SO](http://stackoverflow.com/a/25299512/2300713). – Hille Aug 09 '15 at 16:25
  • The issue exists in 3.10 on Win10 for sure, not sure if it is because of ordering but I got an error with common prefix too. – Uriel Katz Aug 05 '16 at 20:34
0

I beat my head against the wall for weeks with this very same problem. My solution came in not only renaming the custom action method name but renaming the id in the CustomAction.

<CustomAction Id="CA_InstallerDll.install"
              BinaryKey="B_CustomAction_CA"
              DllEntry="Install_InstallerDll"
              Execute="deferred"
              Return="check"
              Impersonate="no"/>

...to...

<CustomAction Id="CA_DllInstaller.install"  //changed InstallerDll to DllInstaller
              BinaryKey="B_CustomAction_CA"
              DllEntry="Install_DllInstaller" //Changed the CA Method name too
              Execute="deferred"
              Return="check"
              Impersonate="no"/>

I'm not sure if this is what you meant by "renaming the custom action" but this is what fixed it for me. The other frustrating thing was that even if I went and renamed it back to InstallerDll, it would still fail for the same reason.

Brett Wertz
  • 412
  • 4
  • 19
  • 1
    Yea thats what I did, basically changed the ID of the custom action and the name of the method to remove an _ and things seem to be working. – Purplegoldfish May 08 '13 at 08:45
0

For me, it was a renaming of the custom action method. I changed one letter from lower case to upper case and forgot to change it in the XML as well.

Papa Mufflon
  • 17,558
  • 5
  • 27
  • 35
0

In my case, I had to compile the CustomActions project first and then compile the Setup project.

chadisbad
  • 385
  • 2
  • 4
  • 16