DIRCA_CHECKFX Return Value 3 - VS 2013 Deployment

问题:

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.

回答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

回答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.

回答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).

回答4:

Visual Studio deployment projects were so horrible that Microsoft removed them from Visual Studio 2012. Developers were so ignorant as to why they were horrible that they begged and begged for them to come back. The smart guys at Microsoft who understand MSI left the building and the people remaining caved to the developers asking for it to come back.

One of those really smart guys summed it up perfectly in a tweet:

The return of vdproj: Headshots, people, or they come back as walkers.

I wrote an article on my feelings: Visual Studio Installer Resurrection

So let's talk about the way the tool is failing you this time. Take a moment to read this article written by one of the other really smart ones to leave MSFT:

Zataoca: Custom actions are (generally) an admission of failure.

VDRPOJ created a custom action to do something MSI could have done natively and now it's failing. So let's say you find the DLL and fix it to work on your machine. What happens when you ship your MSI to 1,000,000 machines? How many machines will it fail out there? How many support calls will you get? How many tweets will you get that your product sucks?

Simply put, I'd redo your installer using a better tool such as Windows Installer XML and Industrial Strength Windows Installer XML. If you have the money to spend InstallShield Professional is a good choice also.