Dll Klassen Problem bei Release Version

[Johannes251298]

Hallo,
ich habe jetzt ein paar Klassen in eine Dll gepackt. Wenn ich jetzt aber die Klassen anwende in einem Program, so lange ich im Debug Mode erstelle, funktioniert alles, aber wenn ich in der Release kompiliere (Dll oder MT), hat er dan probleme beim Initialisieren von den Klassen, und das auch nur wenn ich es auserhalb von Visual Studio aufrufe, also ganz normal die exe ausführe. Die DLL ist im verzeichnis. Er kann dan nur eine bestimmte Anzahl der Klassen initialisieren, egal welche und danach beendet sich das Programm von selbst.

Vielen Dank
Johannes

[Martin Richter]

Debugge doch...
Auch im Release mode kann man Symboldateien erzeugen.

[Johannes251298]

Das ist ja auch unter anderem mein Problem! Wenn ich es mit dem Visual Studio öffne (also mit Debugger aber im Release Mode), dan habe ich garkeine Probleme; Es ist nur wenn ich es auserhalb aufrufe, über den Explorer oder einer Verknüpfung...

Oder kann ich das dan trotzdem irgendwie "Debuggen"?

[Jonas OSDever|logoff]

Den Debugger an den Prozess anhaengen lassen?

[Johannes251298]

Und wie mache ich das?

[Jonas OSDever|logoff]

Du startest zunaechst dein Programm, moeglichst so, dass es noch nicht crasht (notfalls vor dem crashverursachenden Code das Programm unterbrechen, z.B. std::cin.get(); .
Dann unter "Debuggen" auf "An Prozess anheangen..." gehen und in der Liste deinen Prozesa auswaehlen. Dann kannst du debuggen.

[hustbaer]

Oder das Programm einfach crashen lassen.
Dabei kommt dann eh der "Scheisse, Fehler!" Dialog. Normalerweise läuft dieser Dialog noch im gecrashten Prozess, d.h. man kann sich auch erst zu dem Zeitpunkt mit dem Debugger draufhängen und sehen was schief gelaufen ist.

Wenn man Visual-Studio installiert hat sollte eigentlich auch ein "Scheisse, Fehler!" Dialog kommen, wo ein "mit Visual Studio Version X debuggen" Button drinnen ist. Der dann automatisch VS startet und den gecrashten Prozess attached.

[Johannes251298]

hustbaer schrieb:

Oder das Programm einfach crashen lassen.
Dabei kommt dann eh der "Scheisse, Fehler!" Dialog. Normalerweise läuft dieser Dialog noch im gecrashten Prozess, d.h. man kann sich auch erst zu dem Zeitpunkt mit dem Debugger draufhängen und sehen was schief gelaufen ist.

Wenn man Visual-Studio installiert hat sollte eigentlich auch ein "Scheisse, Fehler!" Dialog kommen, wo ein "mit Visual Studio Version X debuggen" Button drinnen ist. Der dann automatisch VS startet und den gecrashten Prozess attached.

Es kommt ja garkein Fehler oder Runtime-Error, nichts! Er bleibt nur bei der initialisierung der Klassen stehen und nach ungefähr 1er sekunde schliest sicht das Program.

[Jonas OSDever|logoff]

Seltsam. Im Falle eines Fehlers muesste da immer irgendwas kommen. Es sei denn, du faengst ihn ab und beendest dich selbst.
Kannst du mal etwas relevanten Code zeigen. Also beispielhaft eine Klasse und wie du sie erstellst. Besser noch ein minimales kompilierbares Beispiel, dass den Fehler reproduziert.

[Martin Richter]

Breakpoints setzen.
Bist Du sicher dass DLL und EXE auch beides als Release/Debug compiliert sind.
Oder könnte es sein, dass Du Release EXE mit Debug DLL betreiben willst (oder vice versa).

[Johannes251298]

Also, es sind beide mit Release ausgewählt und Multithreaded MT erstellt worden, DLL und Programm.

Und das mit dem Beispiel einer Klasse wird auch schwierig da nehmlich die meisten 1000 bis 3000 Zeilen haben.

Aber so sind sind sie alle ungefähr aufgebaut:

class CONTROLSDLL_API Controls::CButtonEx 
{
public:
	// ...
private:
	// ...
};

Und anwenden mach ich immer so:

#include <Controls.h>
#pragma comment(lib, "Controls.lib")
using namespace Controls;

CButtonEx *Button1 = new CButtonEx;

Vielen Dank für eure Hilfe!
Johannes

[Gast]

C und Ex sind ja schon geil, aber die Kombination von C und Ex topt alles!

[hustbaer]

Johannes251298 schrieb:

hustbaer schrieb:

Oder das Programm einfach crashen lassen.
Dabei kommt dann eh der "Scheisse, Fehler!" Dialog. Normalerweise läuft dieser Dialog noch im gecrashten Prozess, d.h. man kann sich auch erst zu dem Zeitpunkt mit dem Debugger draufhängen und sehen was schief gelaufen ist.

Wenn man Visual-Studio installiert hat sollte eigentlich auch ein "Scheisse, Fehler!" Dialog kommen, wo ein "mit Visual Studio Version X debuggen" Button drinnen ist. Der dann automatisch VS startet und den gecrashten Prozess attached.

Es kommt ja garkein Fehler oder Runtime-Error, nichts! Er bleibt nur bei der initialisierung der Klassen stehen und nach ungefähr 1er sekunde schliest sicht das Program.

Dann knall irgendwo ganz am Anfang ne MessageBox rein, oder einen DebugBreak Aufruf.

[Johannes251298]

Das mit den MessageBoxen habe ich schon probiert, aber ich glaube das ich einfach nur eine bestimmte Anzahl von den Klassen initialisieren kann, weil wenn es nur eine oder zwei sind geht's.

Leider brauche ich aber mehr als nur eine oder zwei.

EDIT: Gerade eben habe ich gemerckt das das Problem nur bei der CButtonEx Klasse ist, sobald eine CButtonEx initialisiert wird, Crash. Was kann zu solchen Problemen führen? Damit ich weis wo nach ich suchen muss, die hat nehmlich 1500 Zeilen!!! Um da nen Fehler zu finden...

[Johannes251298]

Problem behoben!
Es waren nur ein paar typedefs die ich in der DLL auserhalb des namespace Controls hatte und im include header für's Programm waren sie im namespace drin.

[hustbaer]

WTF???

Hast du die öffentlichen Deklarationen/Definitionen etwa doppelt vorliegen (1x im öffentlichen Include-File und 1x extra irgendwo in einem privaten Include-File)? Sowas macht man einfach nicht.
Inkludiere einfach das öffentlichen Include-File auch wenn du die DLL selbst baust, dann kann sowas gar nicht mehr vorkommen.

[Johannes251298]

hustbaer schrieb:

WTF???

Hast du die öffentlichen Deklarationen/Definitionen etwa doppelt vorliegen (1x im öffentlichen Include-File und 1x extra irgendwo in einem privaten Include-File)? Sowas macht man einfach nicht.
Inkludiere einfach das öffentlichen Include-File auch wenn du die DLL selbst baust, dann kann sowas gar nicht mehr vorkommen.

Und wie bringe ich dan das CONTROLSDLL_API da rein damit er die Klasse exportiert oder importiert???

[hustbaer]

#ifdef BUILDING_CONTROLSDLL
#define CONTROLSDLL_API __declspec(dllexport)
#else
#define CONTROLSDLL_API __declspec(dllimport)
#endif

Im DLL Projekt definierst du dann einfach über die Projekteigenschaften das Makro BUILDING_CONTROLSDLL . Tadaa.

Zweite Möglichkeit (geht genau so, ist aber glaub ich weniger verbreitet):
Stdafx.h der Controls.dll :

#define CONTROLSDLL_API __declspec(dllexport)

Öffentliches Header File der Controls.dll :

#ifndef CONTROLSDLL_API
#define CONTROLSDLL_API __declspec(dllimport)
#endif

Wenn das Projekt mehr als nur Windows unterstützt dann brauchst du ggf. weitere #if/#ifdef , aber auch das lässt sich machen.

ps: das ist keine Rocket-Science, da kann man auch selbst draufkommen. Oder es sich von einem der Millionen Open-Source Projekte abgucken, die auch alle irgendwie dieses Problem lösen. Ein wenig Selbständigkeit könnte nicht schaden.

[Johannes251298]

Vielen Dank !!! Klappt alles perfekt.