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.

Groggery

If it was me, I'd switch to a tool that is smart enough to know how to check for .NET without using custom actions. This is what AppSearch is for. – Polyandrist

Tell that to Microsoft, they wrote the CA as part of a deployment project, I'm just trying to move my environment forward without a full WiX rewrite. – Groggery

Garbage in garbage out. It's your problem now. Sorry. – Polyandrist

BTW, moving to WiX is more like a refactoring then a rewrite. I run an open source project that provides graphical UI designers and project templates to make it all easier. I doubt it would take more then 1-2 hours to convert your installer if you'd ever like to do a complimentary team viewer session. – Polyandrist

@Groggery did you get this solved? This is still a problem for us building installers in VS2013 versus 2010 using the new installer extension. My colleague has asked a question about this here #25040068 – Kaila

Drumroll: Solution was to work in 2013, then build the MSI in VS 2008... Microsoft have no intention of fixing the DLL issue and as such this is the only choice. You could take the pain of using the WiX tools to reverse engineer your MSI DB but this will be ugly. I'm fighting for a budget right now to rewrite the MSI... – Groggery

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

Strawser

They released a hotfix into this file... Thats why they rebuilt it and broke the IIS api. I might look at this but update the MSI instead of altering my visual studio installation. – Groggery

@Strawser - I would give you 100 points for this answer, if I could! I have had an "installation interrupted" error on a VS2013 setup and spent at least 40 hours looking for the cause. Your simple file swap fixed the problem. Thank you a million times! – Holp

This should be the accepted answer, at least until MS releases a fix – Pusillanimous

@Pusillanimous - I'm not sure that MS will release a fix, because it does not make sense to produce patch, which is not supported Windows XP. – Strawser

@Strawser Although Windows XP is out of support this also affects "POSReady 2009" which is still in extended support until April 2019. – Heptad

@Strawser I also wish I could give you 100 points for this answer. I spent days trying to figure out why my installer wouldn't run on Server 2003. Your solution made my weekend! – Sanskritic

Will replacing the dpca.dll have any negative impacts? – Engrossing

@zSwizz I have not found any. – Strawser

The better answer is to use an installer authoring tool that doesn't require a custom action to check for .NET. It's really a poor design in the first place as MSI can do this natively. – Polyandrist

@Strawser Thanks you very much. I spent about 5 hours trying to fix the issue. I finally found your answer. Very good fix :) – Exorable

@GhostCKY, thank you bunch for saving my day. As people said before I would give 100 points if I can... – Frambesia

I spent a few hours chasing numerous errors: "Windows cannot open this program because it has been prevented by a software restriction policy.", "Error 0x80070643", "1603", etc. all to do with a new service I created in VS2013 for Windows Server 2003. Thanks again! – Odel

I am getting this error with VS 2013 Community running on Windows Server 2008 R2 Standard. Same on Windows 7 Home edition. Both are 64-bit. – Ritenuto

FYI, this fix also works on VS2015, I was in a jam and thankfully @Strawser came through, thanks very much! – Calvincalvina

@Strawser thank you very much for this. I really can't thank you enough – Halda

can I use dpca.dll of visual studio 2008 ? as I don't have VS2013 – Mochun

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.

Invalidity

There wasn't anything in that article about the compatibility. I'd be interested in a reference, as I'll have to force a migration to WiX if it's incompatible. – Groggery

I just suggested it because if they have fixed the problem, it might be in the update. As it's a preview release, I wouldn't recommend using it for a production release. – Invalidity

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

Vladimir

Answer 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.

Polyandrist

All new projects are using WiX. This is a legacy project and right now I'm just trying to shift the compiler forward. Secondly this is in the Microsoft code itself, I was just trying to see if there is a way to identify which DLL is missing so I could try to work out if there is a dependency that I've missed... – Groggery

The messages indicate that the issue is not a missing Dll. The issue is that the code is calling an entrypoint that doesn't exist in one of the Dlls, such as an API that was added to msi.dll, just as an example. Dependency Walker should tell you which one I'm sure it does that. It should highlight the missing call somewhere. – Gastrocnemius

Here's my point.. let's say you identify it and fix it on one machine so it works. What about the other 1,000,000 machines in the world? How can you fix those also? – Polyandrist

Complaining about the VS Project won't help. – Gabriella

It helps people avoid them. – Polyandrist

This is a 6 year old legacy project, that worked. All I wanted to do was upgrade my environment, which Microsoft made a conscious choice to break my compatibility to. They removed it to prevent people making new vdproj files, but at the end of the day breaking 2003 support was a bit unfair... – Groggery

I bet we could rewrite your installer in WiX in 1 hour. – Polyandrist

Do you have a post where you talk about why they are so terrible? That tweet makes 0 sense to me. Also do you have to do a WiX setup in command line or is there something else you can use? I rather figure out WiX than have 2 different setups for XP and Win7. – Underwing

Here's a good read: blogs.msdn.com/b/robmen/archive/2006/09/18/761580.aspx – Polyandrist

Jesus! People really do hate it. I'll work with WiX and figure out how to make my installer work with Win7 and XP than having one for each then. – Underwing

Let alone the fact the VS team uses WiX themselves instead of their own freaking product...that should've been a sign to EVERYONE to switch. – Underwing

I offer free 30-60 minute consultations using ISWIX. I had a customer tell me the other day that my 7 hours of work saved him 100 hours. – Polyandrist

Visual Studio deployment projects were not horrible; they worked; they were the best way to quickly deploy a simple project. MS introduced breaking changes in IIS 7.5 that require you to go into Windows Features and the 'Role Services' for security and IIS management console. – Noyade

Hardly. I've been authoring installers full time for 20 years and I have a list of 100 things I hate about VDPROJ. I have you tube videos showing how to code simple projects (desktop, service, web), create the installer using WiX and IsWiX, check the whole thing into TFS (CI Build) and finally test the installer ... all under 2 minutes. Then as your simple project grows you have the full power of WiX and MSI at your disposal rather then the small subset that VDPROJ exposed. Trust me, I've been there, done that. – Polyandrist

Upvoted. This is correct information - despite the rant :-). – Paleolith