Hallo,

ich bräuchte mal ein wenig Hilfe, da ich vor einem Rätsel stehe.

Ich habe mit C# und Visual Studio 2019 in einem WinForms Tool eine uralte C++ DLL wie folgt eingebunden:

Wenn ich das Ganze per Visual Studio, also im Debug Mode starte, funktioniert alles wie es sollte.

Lasse ich die kompilierte Version direkt laufen, dann reagiert die Anwendung nach kurzer Zeit nicht mehr. Ich habe übrigens mehrere dieser Funktionseinbindungen wie oben in meinem C# Tool, manche funktionieren, die meisten allerdings nicht und wie gesagt im Debug Mode geht immer alles.

Woran kann das liegen?

Danke schon einmal im Voraus für eure Hilfe.

Moderiert von Th69: C#-Tags hinzugefügt

C++ verwendet meines Wissens standardmäßig cdecl als Aufrufkonvention, c# aber stdcall.
Du solltest einmal schauen welche dort verwendet wird und diese ggf. im DllImport angeben (vermutlich passt das so, prüfen sollte man es dennoch, wenn man nicht sicher ist).

Kannst du dich, wenn das Programm hängt, noch mit Debuggen --> "An den Prozess anhängen..." damit verbinden? Vielleicht siehst du dann ja etwas.

Zitat:

Kannst du dich, wenn das Programm hängt, noch mit Debuggen --> "An den Prozess anhängen..." damit verbinden? Vielleicht siehst du dann ja etwas.

Hier hilft vielleicht auch das Tool DnSpy - ist an VisualStudio angelehnt, allerdings arbeitet man nicht auf dem Quellcode, sondern der kompilierten bzw. dekompilierten Assemblies.
Hat mir schon ein paar Mal den Allerwertesten gerettet ^^

Zitat:

Wenn ich das Ganze per Visual Studio, also im Debug Mode starte, funktioniert alles wie es sollte.

Du meinst wenn du automatisch einen Debugger attached hast oder wenn du eine andere Buildkonfiguration benutzt?
Die Debug oder Release Konfiguration hat erstmal nichts damit zu tun ob man auch mit dem Debugger dranhängt.

Wenn ein Release Build nicht funktioniert würde ich denn mal aus Visual Studio starten und debuggen.

Nein ich meinte wenn ich im Visual Studio auf "Start" klicke, dann funktioniert alles egal ob ich Breakpoints gesetzt habe oder nicht. Wenn ich allerdings die kompilierte Exe Datei direkt starte, bleibt das Tool hängen sobald es eine Funktion aus der alten C++ DLL benutzen will. Obwohl es auch hier ein paar wenige Funktionen gibt, die normal laufen.

Moderiert von Th69: Voll-Zitat entfernt.

Zitat:

Wenn ich allerdings die kompilierte Exe Datei direkt starte, [...]

Und danach kannst Du Visual Studio oder DnSpy attachen und debuggen.

Der Tipp mit DnSpy hat mich ein Stück weiter gebracht. Danke schon mal dafür.

Jetzt weiß ich das mein Tool nicht hängt, sondern die Funktionen aus der C++ DLL einfach viel langsamer ausführt, was dann im C# Teil diverse Nebenwirkungen hat.

Die Nebenwirkungen kann ich abfangen, aber was verursacht die langsamere Ausführung und wie komme ich auf die gleiche Ausführungs- oder Reaktionsgeschwindigkeit wie im Debug Mode?

Wie kommst Du darauf, dass es langsamer ist?

Zumindest der C#-Teil verhält sich ziemlich sicher genauso, wie im Debug-Mode. Wenn sich etwas anders verhält, dann weil Du es aktiv so programmiert hast.
Debug- und Release-Mode sind nur Konfigurationen (quasi sowas wie ein IF in der csproj) mit ein paar Default-Einstellungen, wie z.B. ob der Code optimieren werden soll oder nicht.

Hast Du irgendwas in der csproj angepasst? Wenn im Release-Mode etwas anders läuft, dann findest Du das dort - vorausgesetzt, Du hast keinen Code spezifisch für Debug oder Release geschrieben.
Eventuell gibt es auch NuGet-Pakete, die irgendwas verändern?

By the way:
Ein Projekt sollte immer so entwickelt werden, dass man jederzeit die "bin" und "obj" Ordner löschen kann, das Projekt aber trotzdem starte, weil immer alles erneut vorbereitet wird.
Also teste das doch mal: Lösche die "bin" und "obj" Ordner und teste im Debug-Mode. Läuft es nicht, hast Du etwas darin liegen gehabt, was das Projekt nicht selber vorbereitet, aber benötigt.
Wobei der "obj" Ordner selten ein Problem ist, eher der "bin" Ordner, besonders wenn man sich da mal irgendwas zum Testen bereit legt und dann vergisst.

Ach ja und zeig mal den Inhalt der csproj.

Was heißt den jetzt DebugMode ich weiß es leider immer noch nicht

Wir können hier viele Kombinationen haben.
managed build (debug oder release für den c# code) + unmanaged build (debug oder release für den c++ code) + debugger attached (ja/nein) und dabei auch noch was für ein Debugger (managed/unmanaged oder beides gleichzeitig)

Welche von den oben genannten potentiellen Änderungen führt zu anderem Verhalten?


Letztlich müßen wir vermutlich genauer Wissen was im unmanaged Code passiert der ist für so ein Verhaltenänderung empfänglicher. Die Begriffe "COM" und "Stub" im dll Namen klingen schon nach weiteren Abhängigkeiten die da potentiell Einfluß haben.

Mit Debug Mode meine ich einfach, wenn ich im Visual Studio auf "Start" klicke. Spezielle Anpassungen für den Configuration Manager habe ich nicht vorgenommen. Es sollte also in diesem Modus exakt das Gleiche ausgeführt werden, als wenn ich die Executable direkt durch Doppelklick starte. Bei letzterem gibt es aber leider das beschriebene Problem.

Bezüglich der C++ DLL kann ich nur sagen, dass es unmanaged Code ist. Die Sourcen dazu liegen mir leider nicht vor.

Zitat:

Es sollte also in diesem Modus exakt das Gleiche ausgeführt werden, als wenn ich die Executable direkt durch Doppelklick starte.

Prinzipiell ja, aber nein

Es gibt ein paar Unterschiede, wie z.B. den Ordner, wo die Binaries abgelegt und ausgeführt werden.
Wenn dieser Ordner von Bedeutung ist (z.B. weil Du vorher irgendwas dort abgelegt hast), dann wird er das im Release nicht finden.
Daher auch mein Vorschlag, die beiden Ordner zu löschen - richtig umgesetzt sollte das nichts ändern.

Zitat:

Bezüglich der C++ DLL kann ich nur sagen, dass es unmanaged Code ist. Die Sourcen dazu liegen mir leider nicht vor.

Weist du den ungefähr was die (technisch) tut? Redet sie mit spezifischen Windowsdingen oder spezieller Hardware benutzt sie dabei bestimmte Techniken etc?

So wie Interop funktioniert ist das beim Debuggen nicht auf natürliche Weise schneller Das irgendwas in der dll passiert ist am wahrscheinlichsten. Wenn du in den Fällen die du vergleichst die gleichen Executables (und dll) benutzt nur halt einmal mit debugger attached und mal ohne dann können wir nur so Dinge wie unterschiedliche Builds, unterschiedliche Bitness, unterschiedliche Apartments (wenn ich das COM im dll Namen einfach mal in einer gewissen Weise interpretiere) etc. ausschließen.

Dann bleiben aber fast nur Dinge die in der dll passieren über. Spekulieren hilft hier dann nicht wir brauchen mehr Details. Hat die dll wenigstens irgendein Logging Feature das du kontrollieren kannst oder hast du Debug Symbole für die dll zum debuggen derjenigen?