CabLib won't load

Apr 28, 2011 at 7:10 AM
Edited Apr 28, 2011 at 7:11 AM


When trying to create a setup.exe with the InstallerLinker (2.0.4399.0) I get the following error:

ERROR: Could not load file or assembly 'CabLib, Version=, Culture=neutral, PublicKeyToken=5c838b77b53f84a0' or one of its dependencies. The application
has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. (Exception from HRESULT: 0x800736B1)

Is there a file missing, or a problem with the signature?

Apr 29, 2011 at 2:11 PM

Same error here Win7 Enterprise X64. I have installed the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update"

Event Log Message

 Activation context generation failed for "C:\Program Files (x86)\dotNetInstaller\bin\CabLib.dll". Dependent Assembly Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.5592" could not be found. Please use sxstrace.exe for detailed diagnosis.

Apr 29, 2011 at 3:57 PM

I found that the missing dll are link to CabLib project.

Which version of MsVcrXX.dll and MsVcmXX.dll should I use ? I Have installed all version of Microsoft Visual C++ Redistributable Package even on 32 bits VM but I am not able to find those DLL. The only one I have is msvcr100.dll.


Any suggestion?



<form id="aspnetForm" style="margin: 0px; padding: 0px;" action="/KB/files/CABCompressExtract.aspx" method="post">

Apr 29, 2011 at 4:11 PM

You need the x86 (not the 64-bit) version 8.0.50727.5592 of the Visual Studio CRT. But I am really not sure which one it is.

May 2, 2011 at 8:43 AM

Hello dblock

Ok, so I have downloaded the X86 package of Microsoft Visual C++ 2005 Redistributable Package and the SP1 too. I have extracted the content of the MSI and found the DLLs. But the version is not exactly the same. In the X86 the version end with 42, in the SP1 package the version is 762 and in the error in the event viewer, the version expected is 5592.

Any other suggestions?


May 2, 2011 at 11:09 AM

I've find a workaround. I have extracted DLLs from "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update" and I have modified the .manifest file set the correct version, and copy those files into dotNetInstaller folder.

It seems that it works now…



May 3, 2011 at 12:24 AM

This is all very strange. There should be a CRT redistributable version that was used to build CabLib. I'll take a look next time I make a build at what comes from where and why - it might be something from my build machine.

May 3, 2011 at 12:26 AM

Also, there was a newer build, 2.0.4400.0 that came from a newer PC (I just switched laptops) - could you please try?

May 3, 2011 at 7:50 AM

I've downloaded the latest source from source control. The version is I can try the newer one but where can I find it?

May 4, 2011 at 10:12 AM

My OS is Windows 7 64 bit. I have both version 1.0 and 2.0 of DNI on machine. The version 1.0 works well. However, I get the same error: Could not load file or assembly 'CabLib, Version= ... while working on DNI 2.0 to test creating an executable file from one of samples included.

It seems the error just happens in DNI 2.0 version.

May 11, 2011 at 9:48 AM

Hi dblock,

Do you have plan to fix this as it still happens in build 2.0.4877.0?

Thanks in advance.

May 11, 2011 at 3:09 PM

Yes, it's happening on XP SP2 with the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update" installed. It's kind of ironic that DNI can't even install its own prereqs.

May 12, 2011 at 11:15 AM

Yes, I plan to fix it. Of course you can help. This library should have a statically linked CRT so that the dependency doesn't exist, but I am not sure whether it's actually possible.

May 24, 2011 at 3:35 PM

Hello dBlock, is this issue fixed. I am using the version 2.0.673.0 and the setup.exe gets built on certain machines and it does not get built on another machines.I get the same error.

@gregoryott - could you please share your workaround with me. It will be very helpful.

May 26, 2011 at 2:52 PM
Edited May 26, 2011 at 3:13 PM

I've spent a day on this and I still can't find a solution. First, we can't link CabLib statically because it uses managed code. Then, the version of the CRT that CabLib wants is what I have on my machine - 8.0.50727.5592. It's the latest CRT available with Visual Studio SP1 (includes ATL security update).

I tried forcing it to load an older version (as described here), but it still tries to bring in 8.0.50727.5592 through some other library. Haven't been able to track which one.

If anyone has more experience with SxS than me, please feel free to pitch in.

May 26, 2011 at 8:13 PM
Edited May 26, 2011 at 8:19 PM
dblock wrote:

If anyone has more experience with SxS than me, please feel free to pitch in.

I'll give it a shot, just give me steps and links to everything I'll need to start looking at this and I'll see what I can come up with.

First guess is that because you have to use /CLR when compiling, my workaround isn't going to work (see the comments of that link you mentioned).  But I never spent much time seeing *why* my workaround didn't work, I think it's some OBJs (that we don't have source for) that get linked in that have references to the new version of the CRT baked into them.  

May 26, 2011 at 8:53 PM

@Ted: thanks. Get source code from SVN: You should be able to do build all /p:Configuration=Release from top, it will fail at docs and stuff like that (if you want a full build environment there're details in the CHM). 

The easiest repro is to do build packagedsetupsample /p:Configuration=Release, that fails with saying can't load CabLib.dll (which is built by the project) when trying to execute InstallerLinker/bin/Release/InstallerLinker.exe.

Feel free to email me (dblock at dblock dot org) if you need additional help to get setup.

May 27, 2011 at 2:51 AM

Got it all up and compiling - same problem as you.  Now here's the scoop:

The fundamental problem is that any /clr or /clr:oldsyntax builds bring in one or more of the object files contained here:

C:\Program Files (x86)\Microsoft Visual Studio 8\VC\crt\src\intel\dll_lib\clr_obj

for example: managdeh.obj.  This file doesn't have any source code provided by Microsoft, unlike mstartup.obj (which has source code).  So if we had the source to all of these OBJs that were linked in then we would be able to target a specific version of the CRT by including all the source files in our project and ensuring msvcmrt.lib is excluded.    That would be very easy if we had all the source code.

But because Microsoft doesn't provide source code and instead provides prebuilt OBJ files (presumably to protect intellectual property) there is no way to change the embedded manifestdependency in the obj file (open up the managdeh.obj as binary and you'll see the manifest dependency right there links to 5592).  Yuk.  Big Yuk.  

So there is no clean solution to this other than to uninstall the security updates and go back to vanilla SP1 (50727.762) then rebuild.  

Another solution is to make copies of the OBJ files from the folder I mentioned at build time, and do a binary patch on them to fix the manifestdependency.  then exclude msvcmrt.lib and link to the OBJ files that you have patched instead.

But by that time you may as well have disabled automatic manifest generation for the project and then hand coded the manifest file with the desired CRT version and included that instead.  <----- I suggest this approach.  

Note this problem only affects /clr compiled stuff, unmanaged stuff can use the original workaround from my site.  This was reported back in 2006 on but no fix was ever put in.

May 27, 2011 at 3:49 AM

Ted: thank you. This makes some sense (at least to me and maybe 1-2 other people out there :).

I did several things:

  • Forced using private CRT at version .762 in CabLib's headers and added the binaries to the distribution.
  • Removed automatic manifest generation on CabLib.
  • Added an explicit dependency for InstallerLinker.exe.manifest on the 762 CRT.

It's committed @ rev. 65928. Can you please take a look at the change in case you see something I may have missed?

That seemed to work, at least on my machine, so huge thanks. I'll make a build tomorrow so people can test it out.

May 27, 2011 at 3:04 PM

the only thing i would do differently is adding back the publickeytoken to the manifest and manifestdependency lines, so that if a newer version does  exists in WinSxs then your app will automatically load it.  This is more of a philosophical difference i have with Martin.  Yes, it's nice to force a specific version, but loading the latest version (for me) outweighs that benefit.   Mainly for security issues.

May 28, 2011 at 12:46 AM

Sorry, no build today. The one problem I am still having is with a managed unit test that is loaded by NUnit that loads InstallerLib that loads CabLib (UnitTests\dotNetInstallerUnitTests\bin\Release\dotNetInstallerUnitTests.dll). I tried adding a manifest to it, but it fails to load InstallerLib. Still fighting it ...

May 28, 2011 at 2:07 AM

Ok. I uploaded build 2.0.5970.0. Please try it on those machines where you had a failure. This now uses a private manifest and side-by-side msvc*.dll's, so there should be no other dependencies that need to be installed on the build machine.