DIRCA_CHECKFX Return Value 3 - VS 2013 Deployment Project

Question

I have the dreaded issue from my attempted installation of an MSI:

MSI (c) (98:B0) [18:01:22:818]: Invoking remote custom action. DLL: C:\DOCUME~1\sspencer\LOCALS~1\Temp\1\MSI19.tmp, Entrypoint: CheckFX
MSI (c) (98:FC) [18:01:22:833]: Cloaking enabled.
MSI (c) (98:FC) [18:01:22:833]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (98:FC) [18:01:22:833]: Connected to service for CA interface.
Action ended 18:01:22: DIRCA_CheckFX. Return value 3.

After quite a bit of digging, this is actually indicating that the DLL failed to load outright, the CA server was unable to connect and start hitting the DLL entry points.

I used orca and 7zip to extract the custom action for the DIRCA_CheckFX which is inserted by Visual studio when the deployment project builds. I grabbed the DLL and then executed Dependency Walker in the host system (Server 2003 R2) which gave the error:

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.

I recompiled the system using the VS 2010 compiler, extracted the DLL and ran dependency walker on it, which did not create the same error. I.e VS 2010 compilation works, VS 2013 compilation fails as the included DLL won't load in the target environment.

My question is how do I troubleshoot which DLL(s) are missing in order to troubleshoot that error reported by Dependency Walker.

Answer 1

Must be installed VS 2010 from which you can get the valid file "dpca.dll".

1. Close Visual Studio 2013
2. Copy file with replace dpca.dll from C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\Deployment to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\VSI\bin.
3. Open Project
4. Rebuild

Answer 2

The preview of the .vdproj resurrection uses DLLs that don't support Windows XP or Server 2003. Microsoft posted an update that might have fixed that bug.

Answer 3

Here's what I did to workaround this issue for a 32-bit deployment project.

1. Build the setup project in VS2010 once. This package is not dogged by the issue but I didn't want to have to keep building in a different VS version.

2. Open the resulting msi with Orca, select the Binary table and export the content of MSVBDPCADLL to a file.

3. Now after you build it in VS2013 use Orca to import the exported data into Binary\MSVBDPCADLL to fix the package.

I have to do a similar thing with the 64-bit project but in this case it's to import the correct InstallUtil binary (being C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtilLib.dll).