17

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.

Spence
  • 28,526
  • 15
  • 68
  • 103
  • 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. – Christopher Painter Jun 01 '14 at 11:17
  • 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. – Spence Jun 01 '14 at 13:26
  • Garbage in garbage out. It's your problem now. Sorry. – Christopher Painter Jun 01 '14 at 22:00
  • 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. – Christopher Painter Jun 01 '14 at 22:07
  • @Spence 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 http://stackoverflow.com/questions/25039568/visual-studio-2013-update-2-installer-projects-extension – Alan Macdonald Sep 11 '14 at 12:56
  • 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... – Spence Sep 12 '14 at 00:24

4 Answers4

54

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
GhostCKY
  • 764
  • 10
  • 19
  • 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. – Spence Oct 01 '14 at 04:30
  • 5
    @GhostCKY - 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! – Dave Becker Oct 16 '14 at 00:38
  • 4
    This should be the accepted answer, at least until MS releases a fix – Shy Oct 30 '14 at 10:46
  • 2
    @Shy - 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. – GhostCKY Oct 31 '14 at 12:21
  • @GhostCKY Although Windows XP is out of support this also affects "POSReady 2009" which is still in extended support until April 2019. – user1069816 Jan 12 '15 at 14:39
  • 2
    @GhostCKY 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! – Baxter Feb 07 '15 at 02:32
  • Will replacing the dpca.dll have any negative impacts? – zBomb Apr 16 '15 at 18:37
  • @zSwizz I have not found any. – GhostCKY Apr 17 '15 at 07:01
  • 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. – Christopher Painter Apr 23 '15 at 11:05
  • 1
    @GhostCKY Thanks you very much. I spent about 5 hours trying to fix the issue. I finally found your answer. Very good fix :) – denys-vega May 13 '15 at 15:25
  • 1
    @GhostCKY, thank you bunch for saving my day. As people said before I would give 100 points if I can... – jaklucky Jul 15 '15 at 18:57
  • 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! – fpsColton Sep 04 '15 at 18:10
  • 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. – Heinrich Oct 28 '15 at 20:39
  • 2
    FYI, this fix also works on VS2015, I was in a jam and thankfully @GhostCKY came through, thanks very much! – JasonH Apr 13 '16 at 16:38
  • @GhostCKY thank you very much for this. I really can't thank you enough – IgorShch Jan 13 '17 at 10:35
  • can I use dpca.dll of visual studio 2008 ? as I don't have VS2013 – sara Oct 22 '17 at 13:20
1

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.

Bob Arnson
  • 21,377
  • 2
  • 40
  • 47
  • 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. – Spence Jun 03 '14 at 22:56
  • 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. – Bob Arnson Jun 04 '14 at 16:56
1

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

Ionwerks
  • 21
  • 1
  • 4
-2

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.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • 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... – Spence Jun 01 '14 at 13:24
  • 1
    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. – PhilDW Jun 02 '14 at 16:50
  • 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? – Christopher Painter Jun 04 '14 at 02:52
  • 1
    Complaining about the VS Project won't help. – Dave Aug 26 '14 at 17:33
  • It helps people avoid them. – Christopher Painter Aug 26 '14 at 21:16
  • 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... – Spence Sep 15 '14 at 05:51
  • I bet we could rewrite your installer in WiX in 1 hour. – Christopher Painter Sep 15 '14 at 13:16
  • 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. – Luminous Apr 22 '15 at 21:23
  • Here's a good read: http://blogs.msdn.com/b/robmen/archive/2006/09/18/761580.aspx – Christopher Painter Apr 22 '15 at 21:38
  • 1
    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. – Luminous Apr 24 '15 at 19:10
  • 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. – Luminous Apr 24 '15 at 20:11
  • 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. – Christopher Painter Apr 24 '15 at 20:14
  • 1
    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. –  Jul 14 '15 at 20:47
  • 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. – Christopher Painter Jul 15 '15 at 11:08
  • Upvoted. This is correct information - despite the rant :-). – Stein Åsmul Dec 10 '20 at 23:05