5

I have a project that I'm building on Windows 7 (32-bit) using Visual Studio 2005. The program builds fine, and I can move it to another Windows 7 machine and run it just fine. The problem comes when I try to move it to a Windows XP Pro machine. When I try to run the file, I get the following error:

"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

When I open the event viewer, there are three system errors related to this issue:

  • Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
  • Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system.
  • Generate Activation Context failed for [path to my exe]. Reference error message: The operation completed successfully.

I've tried installing the Visual C++ 2005 SP1 Redistributable Package, which doesn't help.

If I build the project on an XP computer, I'm able to run it on another XP computer (that doesn't have the C++ redistributable) and a Windows 7 computer.

Always building on the XP isn't a viable option since I'm not the only person who will be building this and everyone else will be using Win7.

MaddHatter
  • 212
  • 2
  • 10
  • Is this a Debug version you are trying to run, or Release? – Steve Townsend Jun 10 '11 at 20:48
  • Because you're seeing these errors, your executable had an embedded manifest. Could you post it? – Aaron Klotz Jun 10 '11 at 22:17
  • Your Win7 machine probably has a recent security patch for the VS2005 runtime libraries installed. You need to create a Setup project to get the correct DLLs installed on the target machine. This is in general a requirement for programs compiled with /MD. – Hans Passant Jun 11 '11 at 19:57
  • The manifest's version number is newer than what XP has, if I save the XP exe's file as a .manifest file in same directory it works... is there a way to change the version number in the manifest to the lower one? – MaddHatter Jun 12 '11 at 01:43

5 Answers5

1

Check the missing system DLLs with Dependency Walker if it's a native binary - http://www.dependencywalker.com/

Also check that you have needed WINVER - http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx otherwise the SDK falls back to SDK version, which is Vista+ for newer versions. Therefore you might accidentally call a few functions that are not even available on XP.

ildjarn
  • 62,044
  • 9
  • 127
  • 211
Coder
  • 3,695
  • 7
  • 27
  • 42
  • The value of the `WINVER` macro is most likely the problem here, +1 – ildjarn Jun 11 '11 at 01:29
  • I used Dependency Walker on both the Win7 and WinXP .exe's. They have the same .dll's required, but the Win7 one was missing. I used ResHack to open both files and view their manifests (someone mentioned them on here and I did a quick Google). They're the same except for the version number of the missing .dll. I copied the manifest content from the WinXP version and saved it in a .manifest file in the same directory as the Win7 version, and it now runs. Is there anyway to make the embedded manifest use the lower version number? – MaddHatter Jun 11 '11 at 02:41
  • @MaddHatter : Changing the manifest is taking a step backwards -- what you _should_ do is make sure the most recent redist is installed, which I believe currently is [this one](http://www.microsoft.com/download/en/details.aspx?id=1065). – ildjarn Jun 13 '11 at 17:31
0

This is what ended up fixing the problem:

Copy the following folder: "C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT" (since this is the file mentioned in the event viewer) into the same directory as the .exe I was having trouble executing. This lets the program use the dependency it was built against.

Trufa
  • 39,971
  • 43
  • 126
  • 190
MaddHatter
  • 212
  • 2
  • 10
  • While this may solve your problem it is not the best way to handle this. After the next security update of the CRT you might have the same situation. The best solution is to install the matching CRT redistributable with your setup. This way your customers would also benefit from security updates from microsoft to the CRT. – frast Jul 13 '11 at 09:57
0

We experienced similar problem after have updated our version of Visual Studio to Visual Studio 2005 SP1. It ship with an updated version of MFC and of the CRT.

You can detect the problem using Dependency Walker (http://www.dependencywalker.com/).

If it appear to be that try to make sure the windows update are applied. You can also download and run the Visual Studio 2005 SP1 redistributable.

Visual Studio 2005 redistributable http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14431

Visual Studio 2005 SP1 redistributable http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5638

Vivian De Smedt.

Vivian De Smedt
  • 1,019
  • 2
  • 16
  • 26
-1

Assemblies are .NET, not native code. You may be missing the .NET framework. The Visual C++ Redistributable will not include a .NET assembly.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • 3
    In an effort to confuse programmers, MSFT also calls strongly named native DLLs assemblies. Read here: http://msdn.microsoft.com/en-us/library/ms235624(v=vs.80).aspx Assemblies listed there have nothing to do with .NET – Pablo Jun 10 '11 at 21:24
  • @Pablo : I believe that for a native library to be accurately labeled an 'assembly', it must be accompanied by a manifest (but I'm not positive on this). – ildjarn Jun 11 '11 at 02:08
-3

Software built on newer operating systems or library versions will likely have dependencies on new APIs or capabilities that do not exist in older versions of the operating system or libraries.

You can either:

  • build your software on the oldest system you intend to support. This presumes that newer versions of the system have retained backwards compatibility with the base version. Your software will not be able to take advantage of features available in newer versions of the OS, but should be able to run on all backwards compatible systems delivered in the future.

  • build your software once for each system on which you intend to deploy it. This is more work, but means that you can configure your software to take advantages of new APIs and capabilities as they are available on various release iterations of the platform.

acm
  • 12,183
  • 5
  • 39
  • 68