ich steh gerade vor einem verzwickten Problem.
Ich möchte die SvnCppApi von RapidSVN in meinem Programm verwenden. Mein Programm startet ohne Probleme, solange ich nichts aus dieser API verwende. Sobald ich aber etwas aus dieser API verwende, d.h. die LIBs und DLLs davon verwendet werden, bekomme ich beim Start der Applikation folgenden Fehler:

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: c:\Temp\SvnAddin (2)\SvnAddin\debug\SVNTest2.exe

R6034

An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.

---------------------------
OK
---------------------------

Laut MS liegt das an fehlender Manifest-Dateien (Siehe http://msdn2.microsoft.com/en-us/library/ms235560.aspx). Das fehlende Manifest kann aber nicht in meiner Applikation sein, da diese ja korrekt hochkommt, solange ich nichts aus der API verwende. Die API selbst ist eine Lib, d.h. dort wird überhaupt keine DLL geladen, allerdings gibt es einige DLL-Abhängigkeiten zu Subversion-DLLs.
Bei Interesse kann ich das kleine Testprojekt gerne auch verschicken, eine Lösung für dieses Problem ist eher dringend und ich komm leider nicht weiter

Danke für eure Hilfe!

Das fehlende Manifest kann aber nicht in meiner Applikation sein, da diese ja korrekt hochkommt, solange ich nichts aus der API verwende.

Warum glaubst Du das?
Die DLL prüft beim Laden der DLL in den Prozess ob ein Manifest vorhanden ist. Wenn nicht kommt die oben gezeigte Fehlermeldung. Ob Du nun was daraus verwendest oder nicht spielt dabei keine Rolle... (aber Du verwendest ja irgendwas daraus, sonst würde die DLL ja gar nicht geladen ).

Also: Manifest verwenden (kann auch eine externe sein):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Kann ich meinem VS2005 beibringen die alte Runtime zu verwenden?

Nein. Du kannst aber statisch linken.

Du hast nun zwei Möglichkeiten:
1. Du lieferst mit Deiner EXE eine separate Datei mit, welche "name-der.exe.manifest" heist
2. Du bettest diese Manifestdatei in die Resourcen Deiner EXE ein

Zum Inhalt:
Eigentlich erzeugt das VS2005 automatisch eine Manifest-Datei und bindest diese auch autoamtisch ein. Du kannst auch nochmals in Deinen Projekteinstellungen nachschauen: "Configuration Properties|Manifest Tool|Input and Output|Embed Manifest:Yes"
In Deinem Debug/Release-Verzeichnis müsste auch irgendwas mit dem Namen "manifest" auftauchen.

Oder eben Du nimmst den Inhalt, den ich weiter oben gepostet habe.

Vermutlich braucht aber noch die DLL ein Manifest mit der ID2... (irgendwas war da mal).

Kannst du da genauer werden?

Jochen Kalmbach schrieb:

Vermutlich braucht aber noch die DLL ein Manifest mit der ID2... (irgendwas war da mal).

Kannst du da genauer werden?

Ich suche noch... hab da nur was im Hinterkopf gehabt...

ADD: Vermutlich lag ich aber falsch. Es muss gehen, wenn Du in der EXE das korrekte Manifest drin hast. Was steht denn in dem Manifest für die EXE drin?
Versuche es doch mal mit einem externen Manifest!

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugMFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Bitte schick mir eine eMail über das Forum, so dass ich deine eMail-Adresse habe, dann würde ich es dir mal zuschicken.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> 
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugMFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Oder (besser) Du linkst gegen die korrekte LIB, welche auch die Debug-CRT verwendet. Meine Vermutung ist, dass wenn Du gegen die Release-LIBs Deiner DLLs linkst und Du gemeinsamen Speicher über die DLL Grenzen hinweg verwendest, dann wird es sowieso zu abstürzen kommen, da Du ja unterschiedliche CRT-Versionen verwendest.
Also: Linke gegen die korreten Debug-LIBs, welche die *gleiche* CRT verwenden!

dank dir, das war das Problem! Wenn ich das ganze als Release kompilere, dann tritt der Fehler nicht mehr auf.

Werde mich dann mal auf die Suche der Debug-DLLs machen.