winsxs

How do I force a native application to use an older C runtime

断了今生、忘了曾经 提交于 2019-12-07 08:44:12
问题 Visual Studio 2010 installs version ...4974 of the VC9 runtime whose .pdbs are unavailable. How can I force my GME.exe to use an older VC9 runtime? I've tried putting this into GME.exe.config : <?xml version="1.0"?> <configuration> <windows> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <assemblyIdentity type="win32" name="GME" processorArchitecture="x86" version="1.0.0.1"/> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" publicKeyToken=

Can I modify the side-by-side assembly search sequence?

╄→尐↘猪︶ㄣ 提交于 2019-12-06 09:54:09
I have a Windows, C++ software project (built with Visual Studio 2005, SP1) that has the following (simplified) file layout: {App. Root Directory} |-- bin | |-- Microsoft.VC80.CRT | +-- Microsoft.VC80.MFC +-- utils There are various executables that live in both the bin and utils directories. Each of these executables rely on the side-by-side assembly (C++ run-time DLLs) that we store in bin , but we have segregated them into these separate folders for various reasons (e.g., the exes in the utils folder are supplemental tools to our primary application, and are run infrequently). As a direct

How do I force a native application to use an older C runtime

女生的网名这么多〃 提交于 2019-12-05 16:08:29
Visual Studio 2010 installs version ...4974 of the VC9 runtime whose .pdbs are unavailable . How can I force my GME.exe to use an older VC9 runtime? I've tried putting this into GME.exe.config : <?xml version="1.0"?> <configuration> <windows> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <assemblyIdentity type="win32" name="GME" processorArchitecture="x86" version="1.0.0.1"/> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" publicKeyToken="1fc8b3b9a1e18e3b" processorArchitecture="x86" /> <bindingRedirect oldVersion="9.0.21022.8-9.0.21022.4974"

TortoiseSVN side-by-side configuration is incorrect

旧时模样 提交于 2019-12-04 19:38:56
问题 After upgrading to the latest version of TortoiseSVN (1.5.2.13595), it's context menu is no longer available. When attempting to run it manually, I get this error: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail The application log shows this Activation context generation failed for "C:\Program Files\TortoiseSVN\bin\TortoiseSVN.dll". Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="x86"

Visual C++ Redistributables without using VCRedist_x86.exe

混江龙づ霸主 提交于 2019-12-02 19:27:38
问题 I'm developing in an environment that is severely constrained, but the developers also have tight control over. VCRedist_x86.exe - A 4Mb redistributable - is no fun (four hours to transfer). I'd really prefer to just redistribute MFC90.dll, msvcm90.dll, msvcp90.dll and msvcr90.dll - that's more like 2Mb. However, Redistributing Visual C++ Files says: It is not supported to redistribute C/C++ applications that are built without a manifest. Visual C++ libraries cannot be used by C/C++

MSVCR90D.dll not found in debug mode with Visual C++ 2008

末鹿安然 提交于 2019-11-30 05:57:16
问题 I have a problem with Visual C++ 2008. I have installed opencv and I've created a new program and I build it with no errors. However, it complains about not finding MSVCR90D.dll when debugging. In release mode there is no problem at all. I do have MSVCR90D.dll in one of Winsxs folders. Does anyone know a get-around to this problem? Is this a known bug? Gerard 回答1: There are several potential solutions described in this forum post. See if any of those help. One hint from there: Go to %System

Visual C++ 2010: Changes to MSVC runtime deployment (no more SxS with manifest)

烂漫一生 提交于 2019-11-29 20:41:40
Where can I find some official note, kb article or other documentation describing changes to the Visual Studio 2010 C/C++ runtime linking and deployment policy? Under Visual Studio 2008 (with the VC90 runtime) a manifest was embedded in native images, and the runtime libraries were deployed as side-by-side assemblies (WinSxS). This caused problems when rebuilding a native exe or library using VS 2008 SP1, in that an updated version of the C++ runtime was required by the embedded manifest. For VS 2010 and the MSVCR100 runtime version, the policy seems to have changed completely. The file

How to install VC80CRT debug runtimes without full visual studio 2005?

早过忘川 提交于 2019-11-29 09:29:34
I can't run a debug sdk application because it requires both VC 8 and VC 9 versions of the CRT. But it only requires visual studio 2008 for plugin dev, which is what I need. How do I install the debug runtimes from 2005 on to a Windows7 machine? I can't figure out how to make them run app local nor can I copy anything into the winSxS folder without a trusted installer. Refer to this post . As per this the debug dlls can be found at: For Visual Studio 2005: C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86 For Visual Studio 2008: C:\Program Files\Microsoft Visual Studio 9

Visual C++ 2010: Changes to MSVC runtime deployment (no more SxS with manifest)

我是研究僧i 提交于 2019-11-28 17:21:10
问题 Where can I find some official note, kb article or other documentation describing changes to the Visual Studio 2010 C/C++ runtime linking and deployment policy? Under Visual Studio 2008 (with the VC90 runtime) a manifest was embedded in native images, and the runtime libraries were deployed as side-by-side assemblies (WinSxS). This caused problems when rebuilding a native exe or library using VS 2008 SP1, in that an updated version of the C++ runtime was required by the embedded manifest. For

MSVCR90D.dll not found in debug mode with Visual C++ 2008

霸气de小男生 提交于 2019-11-28 06:55:23
I have a problem with Visual C++ 2008. I have installed opencv and I've created a new program and I build it with no errors. However, it complains about not finding MSVCR90D.dll when debugging. In release mode there is no problem at all. I do have MSVCR90D.dll in one of Winsxs folders. Does anyone know a get-around to this problem? Is this a known bug? Gerard There are several potential solutions described in this forum post . See if any of those help. One hint from there: Go to %System Drive%\Windows\WinSxS and look for the directory x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x