C++ Application doesn't work after installing newer version of C++ redistribute

Question

0.00/5 (No votes)

See more:

My C++ application was running on windows XP using shared run-time assemblies version 9.0.30729.1. But recently I installed new C++ redistribute package and it deployed newer version of run-time assemblies version 9.0.30729.6161.

In Winsxs\policies directory this new policy file also deployed by new C++ redistribute package.

XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation.  All rights reserved. -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32-policy" name="policy.9.0.Microsoft.VC90.ATL" version="9.0.30729.6161" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.ATL" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
<bindingRedirect  oldVersion="9.0.20718.0-9.0.21022.8" newVersion="9.0.30729.6161"/>
<bindingRedirect  oldVersion="9.0.30201.0-9.0.30729.6161" newVersion="9.0.30729.6161"/>
</dependentAssembly>
</dependency>
</assembly>

After this new Visual C++ 2008 Redistributable installation my program shows "This Application Has Failed to Start Because the Application Configuration Is Incorrect" error. But if I delete above policy file it works fine. Any idea?

Posted 11-Apr-13 20:44pm

Nayana Adassuriya

Updated 11-Apr-13 21:05pm

Mohibur Rashid

v2

Add a Solution

Comments

Richard MacCutchan 12-Apr-13 4:08am

Did you rebuild your project with the new runtimes in place?

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

KarstenK · Answer 1 · 2013-04-11T21:48:00

Solution 1

Looks like the installer overwrote the "1" with "6161"

9.0.30729.1
9.0.30729.6161

My solution is to use static linking to avoid such mess.

Posted 11-Apr-13 21:48pm

KarstenK

Comments

Nayana Adassuriya 12-Apr-13 3:56am

Static linking is not a recommended method. And for large scale project with multiple DLLs conflict by the static linking. Run time assemblies normally not overtiring one by other. Those just forward usage by policies.

KarstenK 12-Apr-13 4:41am

Large scale projects are with a complete installer which should handle the dll mess.
In smaller projects is static linking an easy way to make the setup an "easy fruit" and avoid such problems.

H.Brydon · Answer 2 · 2013-04-12T06:53:00

Solution 2

You can adjust the tolerance to this in the manifest file(s) for your application. I'll let you chase MSDN for this.

If you use external manifest files, you can fix your existing app without recompiling with the 'redirect' technique which is described here[^].

Posted 12-Apr-13 6:53am

H.Brydon