TomasDeml wrote:

If you mean manifest of visual styles (comctl32.dll v6.0.0.0), it looks like this:

I have VS 2005 on my desktop here at work, and I installed VS 2005 SP1 Beta on my work laptop to try it out. Software compiled on my laptop will give the 14001 SxS error that we have all been struggling with on my desktop (and all the other computers I tried to deploy on).

A valid solution is creating an msi installer with merge modules for MFC and the CRT included, but that is not practical for testing and deploying small apps. Also, if you are installing at a customer site, you don't want to install new SxS policies and manifests that could break other 3rd party apps that the customer depends on. I don't recommend manually messing with the WinSxS directory, as some have had success with. If you copy dll directories only, and not policies and manifests, you can really screw things up. Also, don't just dump tons of DLLs into your System32 folder, another good way to mess things up. Merge modules are cleaner, but have some dev overhead and leave a global footprint. (A policy file will re-route any app asking for an old version of a dll to the newest version. Not good if some other app is not validated with the latest dlls yet.)

BEST SOLUTION FOR ME:
I like to drop dlls that my app depends on into the same folder I drop my app into. The trick is to know which dlls your app was compiled with. VS 2005 and the Beta SP1 have different versions of MFC and CRT. Browse to:
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86
Here you will find folders of what you are looking for, little groups of dlls and manifest files to go along. Just copy all the contents into the local path of the exe you are deploying.
(Most people only see an x86 folder here, but some have AMD x64 and Intel x64 folders for those compile options.)
You'll notice that Debug dlls are NOT redistributable.
This local copy also makes uninstalling much easier. Just delete them!

I was guided by this article, which today apparently does not exist in English, but hopefully MSDN will fix it before anyone clicks on it:

http://msdn2.microsoft.com/en-us/library/ms235317(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/ms235317(VS.80).aspx

You can either copy these files manually in a debugging deployment scenario, or add post-build events to copy from your actual Visual Studio 8 folder (use $(Configuration) macro for Debug/Release switch), or add these files to a Setup project.

-Matt

1. the dependent assemblies can not be found. This is the case when the manifest file of your app requires assemblies that do not exist on the target machine. This can be resolved by the various copying around dlls into the winsxs folder. One should make sure the versions map as well as debug/release map from the manifest file to the directory

2. it seems like windows XP stock installation has some issues looking up the dependent libs in the winsxs folder despite the manifest and the folder dir matching up. I got around it the following way:
- I copy the dependent dlls as well as their manifest file into the dir of the app (taken from C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT) - version 8.0.50727.363, which is also the version of the apps manifest file.
- this manifest file, however, does not contain the correct version of the dependent dlls (it contained 8.0.50608.0, but needed 8.0.50727.363). Once you changed the version in the dependent dll manifest's file, everything works like a charme.

Christian

I managed to fix the problem by setting the Property "Linker / Manifest File / Generate Manifest" to NO and changing the libs to ignore from:

libcmt.lib

to:

libc.lib,msvcrt.lib

(properties / linker / input / ignore specific library)

It also fixed the "This application has failed to start because MSVCR80.dll was not found" error on my Vista development machine

m_eiman said:

I'd like to add another possible cause of this error: when I built by MSI for application I added the CRT merge module, but forgot to add the police merge file for it.

After way too much time spent looking for a reason for why Windows couldn't find the CRT DLL I rebuilt the MSI with the policy merge added and my blood pressure could return to normal. Phew.

Not sure if VS adds the policy file by default, but the MSI builder I use sure didn't.

- Mikael

BINGBINGBING! We have a winner!  I'm grateful I stayed with this thread long enough to see this post.  As evidenced by the length of this thread, one can chase a lot of dead ends before finding this key fix.  Thanks for the insight, Mikael.

rfeague said:

m_eiman said:

*snip*

BINGBINGBING! We have a winner!  I'm grateful I stayed with this thread long enough to see this post.  As evidenced by the length of this thread, one can chase a lot of dead ends before finding this key fix.  Thanks for the insight, Mikael.

Wow, was that worth resurrecting a 6 year-old thread?

I found the easy and reliable way to fix this was to statically link the C runtime.  This is a COMPILER (not Linker) option.  Change Project->Properties->configuration Properties->C/C++->Code Generation->Runtime Library from Multi-threaded DLL to Multi-threaded (without the dll).  Adds about 55k to the target dll.

pbbipj said:

I tried many of the suggestion in this thread to no avail.  The root problem in my case was that my build machine was creating a dll that want to link to c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989\MSVCR80.DLL and it would fail when run on machines that had c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.3053_x-ww_b80fa8ca\MSVCR80.DLL.  Note the difference at 4053 and 3053.

 

I found the easy and reliable way to fix this was to statically link the C runtime.  This is a COMPILER (not Linker) option.  Change Project->Properties->configuration Properties->C/C++->Code Generation->Runtime Library from Multi-threaded DLL to Multi-threaded (without the dll).  Adds about 55k to the target dll.

FYI, the most recent case I've seen of this seems to have been triggerred by a recent Windows Update.  Specifically, in my case, it was via KB971090. 

This update had some security fixes which caused our build server to compile against different binaries. Of course, the minute we tried to install our application on a system, we realized that our binaries were build against version Y, but our installer was only packaging the older version. Consequently, we had to choose between re-bundling the DLLs that we ship with our product, OR rolling back that specific Windows Update and just not having the security fixes in our product.

See the following for more info:

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/793f1dc8-bdd5-429f-8d42-589116cb0061

hyveedoughboy said:

pbbipj said:

*snip*

FYI, the most recent case I've seen of this seems to have been triggerred by a recent Windows Update.  Specifically, in my case, it was via KB971090. 

 

This update had some security fixes which caused our build server to compile against different binaries. Of course, the minute we tried to install our application on a system, we realized that our binaries were build against version Y, but our installer was only packaging the older version. Consequently, we had to choose between re-bundling the DLLs that we ship with our product, OR rolling back that specific Windows Update and just not having the security fixes in our product.

 

See the following for more info:

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/793f1dc8-bdd5-429f-8d42-589116cb0061

FYI, another solution works for me is deleting *.pdb file in binary folder after building the program and then just running the exe.  Then you will probably never have to delete again *.pdb file.

1)  Thanks to this thread, I realized it was a Side-by-Side issue.

2)  With "Embed Manifest" set to "No" in my project properties, I had a manifest file that I could open with notepad.  My Manifest was looking for version "8.0.50727.4053" of "Microsoft.VC80.CRT" and "Microsoft.VC80.MFC".  On my local machine (Windows XP Pro SP3 x86), I found these files in C:\Windows\WinSxS\ under "x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989" and "x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_b77cec8e" respectively.  When I looked on the target machine (Windows Server 2003 SP2 x86), these folders did not exist, so I knew the solution was to (somehow) get these folders/dlls installed.

3)  Tried running, on target machine, vcredist_x86 that I copied from the "bootloader" folder under my VS install, but the SxS folders would not appear.  Also tried downloading the Visual Studio 2005 SP1 Redestributables from Microsoft and installing that, still nothing.  Found "Visual C++ 2005 Redestributables" in Add/Remove Programs, uninstalled it, then ran vcredist_x86, it shows up in Add/Remove programs again but the SxS folders are STILL missing.

4)  Using WinRAR, extracted the MSI and CAB file from vcredist_x86 and ran MSI.  Installation works pretty much the same as running the vcredist_x86 file, except it skips the "extracting" step.  Once install is complete, SxS folders are there and dlls on target machine now work fine.

So the first thing I would do is check the manifest for the necessary SxS dlls and versions, then check in the target machine's WinSxS folder to make sure the corresponding dlls are there.  If they are not there, then the solution is to get them installed.

The roadblock for me was that vcredist_x86 was not installing those SxS files for some reason, but still the installation did not show any sign of errors.  I have no idea why extracting the MSI and CAB worked, maybe a user rights issue?