Auslieferung einer CLI C++ Dll



  • ja klar, das ist alles drauf, .NET 2.0 und die C Runtime Library Sp1.

    Ich hab dann einfach den Release Ordner auf den Anwendungsrechner kopiert.

    Das programm, welches meine DLL aufruft , ist auch ein .NET programm. Das startet ganz normaler... bis das programm die C++ .NET Dll laden soll.



  • Wie rufst Du die DLL auf?
    Passiert das bei deinem Entwicklungsrechner nicht (auch nicht mit Release)?



  • In meinem .NET programm gehe ich auch : "Verweis hinzufügen". Also die DLL als Assembly einbinden.

    Nein das passiert auf meinem Entwicklungsrechner nicht. Auf dem Zielrechner sind auch definitive alle DLL´s drauf.



  • Probier mal mit dem Dependecy Walker herauszufinden ob wirklich alle DLL's vorhanden sind:
    http://www.dependencywalker.com/

    Edit: Habs gerade gesehen... habe schlecht gelesen
    Was benutzt Du für eine IDE?
    Was für Versionen benutzt Du (vielleicht hast Du ja gegen das .NET Framework 3.5 kompiliert)...



  • ja ich benutzer VS2005

    Ich habe alle DLL die mir der Depency Walker gemeldet hat zusätzlich noch kopiert.
    Komisch ist, das trotz meine Release konfiguration immer noch die "D" - also DEBUG Dlls benötigt werden (Also z.b. MSVCM80D, MSVCR80D etc,..).

    Jetzt gibt mit der Depency Walker folgenden Fehler:

    Error The Side-by-Side configuration information for cchromstar7CHRFILEIOLIB.DLL contains errors. Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren (14001).

    Warning At least one module has an unresolved import due to a missing export function in a delay-load dependent module.



  • Eine Release-Version darf keine Debug-DLLs anziehen...

    Auch musst Du nach dem problem mit der komischen DLL schauen... wurde diese auch mit VS2005 erstellt? Oder mit VS2008? Dann musst Du womöglich noch das vcredist_x86 von VS2008 installieren!



  • Das ist alles ganz großer Mist.

    Ich habe einen Ordner, da sind meine Realease datein drin.

    Den Kopiere ich auf einen "Nakten" rechner. Dann installiere ist das .NET Framework. Dann installiere ich die vcr_rest aus MEINEM VC2005 ordner... also die selben, mit dem das ding compiliert wurde.

    Und dann bekomme ich nen Side by Side error. Das ist echt zum Kotzen.

    Ist das denn richtig das der DepencyWalker mir die MSVCR80D DLL als abhängigkeit anzeigt, oder ist das wohl möglich nen Fehler?

    Wenn nicht, warum benötigt mein Release compilat eine "D" DLL. Wo kann ich das überprüfen im VS2005?



  • Ist das denn richtig das der DepencyWalker mir die MSVCR80D DLL als abhängigkeit anzeigt, oder ist das wohl möglich nen Fehler?

    Es ist ein Fehler, dass bei deiner Release Version die Abhängigkeit auf die Debug Version der C Runtime besteht. Der Fehler musst Du bei deinen Kompiler / Linker Settings im Projekt finden.

    Simon



  • das hab ich mir auch alles gedacht. Und hab jede Seite im Linker / Compiler durchsuchst. Und überall wo etwas mit debug steht, ist Debug deaktiviert. Ich habe an den Projekt settings auch nichts vorgesnommen, also die sollte auch alles noch Standard sein.



  • Du linkst doch dll's dazu bzw. referenzierst .net assemblies..
    Sind das alles release versionen? (wenn eine davon eine debug version ist, und die die runtime benötigt, dann wird schlussendlich auch diese als abhängigkeit erscheinen.)



  • Du linkst vermutlich gegen irgendeine LIB, welche mit Debug erstellt wurde!



  • Die C++ .NET dll wird nur eingebunden. Einbinden tut sie selber nur den Standard .NET kram und Microsoft.VisualC.



  • Ich meinte *LIBs* welche in der C++/CLI-DLL dazugelinkt werden!!!! Da ist eine "falsche" dabei!



  • das komisch!

    Ich habe eine große projekt mappe, in der unter anderem auch meine DLL ist. Wenn ich die DLL da als realease comiliere, benötigt sie die Debug DLL´s.

    Wenn ich das Projekt aus dem Ordner kopiere, eigenstädnig öffne und Compiliere, benötigt sie die normales release DLL´s. Dabei wird die die Nur von anderebn Progarmmen eingebunden.

    Woher kommt sowas? Denn es werden doch bestimmt immer die selben Libs hinzugelinkt.



  • Woher kommt sowas? Denn es werden doch bestimmt immer die selben Libs hinzugelinkt.

    Eben: es muss nicht immer dieselbe sein, sondern einmal die release und einmal die debug *.lib.



  • also mit der richtigen release DLL scheint es zu funktionieren.

    Leider habe ich kein einfluss darauf, welche LIB´s in meine DLL eingebunden werden. Desshalb werde ich die DLL wohl immer seperat compilieren müssen.

    Mal ne andere Frage: Wie ist das eigentlich bei Vista 64? Bei Vista ist ja schon standard maßig .NET 3.5 drauf. Nun habe ich noch die C-Runtime Library für x64 installiert. Es funktioniert aber nicht. Er kann die DLL wieder nicht laden.

    Jemand eine ahnung wie das unter x64 geht?



  • Du musst ein extra build für 64bit machen.



  • In diesem Mode wie die EXE gestartet wird, werden auch alle anderen DLLs gelesen.
    Also wenn die EXE .NET mit "Any"-Target ist, dann wird diese als x64 gestartet und *alle* DLLs müssen auch für "x64" oder "Any" compiliert worden sein!

    Wenn die EXE speziell mit x86 oder x64 gestartet wird, dann müssen alle DLLs entsprechend auch für diese Platform kompiliert worden sein.

    D.h. Ist die EXE x86, so musst Du *nicht* für x64 kompilieren.



  • Ich entschuldige mich für die falsche Information.



  • ah vielen dank, ihr beide habt mir sehr geholfen!


Anmelden zum Antworten