Side-by-side screwup

I think this thread describes actually two issues:

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 was able to fix this by statically linking MFC. I was not able to get this to work any other way.

Just install the vcredist_x86.exe on your target machine. Use the vcredist_x86.exe from the machine where you compiled your application (found at the following location:
%HOMEDRIVE%\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86\ )

This worked for me

yup, just to confirm what rajesh said, an updated c++ runtime redistributable was shipped with VS05 SP1. we located and ran this on the target machine and the side-by-side error was cured.

kh

EDIT: fwiw, the dll which was giving us problems was an unmanaged c++ win32 library

I was also getting the "This application has failed to start because the application configuration is incorrect" error for my Vista/Visual Studio 2005 generated executables when I tried to run them on XP.

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

This thread was a life saver.

Have a Visual Studio 2005 compiled dll, called by a
.NET 1.1 assembly (built with Visual Studio 2003).

The dll wouldn't start on Windows XP.  I had to do all of the
following to make it work:

o - install Visual Studio 2005 SP1 and build the dll with it.
     This is a 4.5 Gb download from MS.
o - install the new vcredist_x86.exe (from VS 2005 SP1)
     on the target platform (XP).
o - install .NET 1.1. SP1 on the target platform.
o - back out "Embed Manifest" = "false" (set it back to true).

We had tried setting Embed Manifest = "false" in the dll
and that helped a little but didn't completely solve the problem.

All four things are required for our app (ASP.NET 1.1) to start
and to be able to call the assembly that calls the dll.

A strange thing is the assembly would work fine under ASP.NET if I
ran it under .NET 2.0.  It leads me to believe the old .NET 1.1
run-time wasn't coping with a corrupted manifest generated
by pre-SP1 VS 2005.

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

I would suggest removing type=win32 from the manifest for your SxS component.

So, your manifest file should look like,
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"><assemblyIdentity version="0.0.0.0" name="SoftFX.dll"></assemblyIdentity></assembly>

Let us know if that works.

I wanted to add some information to this thread because my problem was similar but different.  I moved  an app from vc6 to 2005 and it wouldn't run on certain systems, noteably server 2003.  We found an error in the event viewer:
Source: SideBySide
Description: Syntax error in manifest or policy file "\\MachineName\Program\progname.exe." on line 0
Source: SideBySide
Description: Generate Activation Context failed for \\MachineName\Program\progname.exe.  Reference error message: Manifest Parse Error: Invalid at the top level of the document.

The problem turned out to be Telock (free PE-File Encryptor/-Compressor which is designed to process most .exe, .dll and .ocx files).  It corrupts the manifest so we had to remove the manifest to allow the app to run and still use Telock.

I hope this helps someone.

Hi,

I just faced the same issue and for me that problem was working on a dynamic view of ClearCase - switching to a snapshot view fixed the problem...

br

i was really struggling on this problem and then read the post by Mikael about not adding the Policy.

I had two dependencies on CRT and MFC. I'd added the MSM and policy for CRT but only the MSM for MFC.

I then added the policy for MFC and it worked fine. In the process of trying to get to the bottom of this problem, I have also updated to SP1.

I had tried copying the dlls, the manifest folder etc and this made no difference. Adding the Policy was the solution.

many thanks to everyone who contributed - it really helped me in a tight situation.

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

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.

None of the solutions here were exactly what I needed to do but they did help me figure out my problem, so I wanted to share.  Here is how I figured it out:

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?