@Th69 du bist Spitze. 😉

Hatte heute mal ein bisschen Zeit mich damit zu beschäftigen. Dein Tipp mit dem Tool war natürlich goldrichtig.
Die DLL's habe ich ja mit einer neueren Redist (Runtime) erstellt. Da fehlte auf dem Test System die richtige VCRUNTIME DLL.

Kurzum, die aktuelle VC Redist installiert und da ging die Suche los, denn es hatte nicht funktioniert.

Super einfacher Fehler, aber da muss man erst mal drauf kommen:
DependencyWalker zeigte, dass meine DLL's mit der "VCRUNTIME140D.DLL" verlinkt sind, 
diese sind auf meinem System lokal auch vorhanden waren, aber in der Test VM nicht.
Denn normal müsste das eigentlich die "VCRUNTIME140.DLL" sein.

Die Erklärung:
Ja klar, wenn man mit DEBUG das Projekt erstellt, wird der Output mit einer Debug Runtime verlinkt, die Visual Studio mitbringt.
Einfach als RELEASE erstellt und alles wunderbar. Damit wurden die DLL's auch korrekt mit der "VCRUNTIME140.DLL" verlinkt.

Das wusste ich nicht, da man auch bei Google über die "VCRUNTIME140D.DLL" nicht viel findet, bin nur stutzig geworden als ich irgendwo gelesen hatte, dass die "D" Variante zu Visual Studio gehört.

Ich bin jedenfalls glücklich, dass es dann doch so was banales war und jetzt alles einwandfrei funktioniert.

Vielen, vielen Dank für die Unterstützung.

Viele Grüße
Mario

Mmhh.. eingestellt und verwendet für das C++/CLI-Projekt ist v4.8

Auf beiden System ist die gleiche Version des .NET Framework installiert (4.8.09037). (laut Registry)

Auf dem Entwicklungsrechner sind die Targeting Packs für 4.7.2 (4.7.03062) und 4.8 (4.8.03761) installiert.

Hallo, i'll be back.. mit einem kleinen Problem:

Abschliessend zu diesem Thema habe ich erfolgreich dem Hauptprogramm meine DLL's untergeschoben. Auf meinem Rechner alles wunderbar.

Bei abschliessenden Tests hänge ich jedoch bei folgendem Problem:

Auf meinem lokalen Rechner (auch Entwicklungsrechner) funktioniert das tauschen der DLL einwandfrei. Die Hauptanwendung spricht diese Problemlos an und lädt diese auch. Alles Fehlerfrei.

Auf einem anderen frisch installierten Windows 10 Rechner lädt das Hauptprogramm einfach nicht die DLL's und quittiert dies natürlich mit einer Menge Fehlermeldungen.

Nach unzähligen Prüfungen habe keine Idee mehr, bin aber schon mal dahintergekommen, dass die DLL's einfach nicht geladen werden.

Noch mal zur Erkläung vom Ablauf:
Das Hauptprogramm lädt beim Start und während der Laufzeit C-ähnliche Skriptdateien. Dieser werden erst zur Laufzeit ausgeführt. In diesen Skriptdateien sind Verweise/Aufrufe zu externen DLL's eingebunden. Dieser werden auch erst bei ansprechen einer Funktion geladen und verwendet. 
Die DLL's werden also erst sehr spät geladen und verwendet.
So ist bspw. die Schnittstelle zu Outlook und Excel implementiert.

Auf meinem "Entwicklungsrechner" funktioniert dies ohne Probleme, auf zwei anderen Rechnern nicht. 
Bereits durchgeführte Maßnahmen (aber ohne Auswirkung):

• die DLLs sind alle mit einem CodeSigning Zertifikat Signiert
• alle DLLs als 32bit erstellt, da die Hauptanwendung auch 32bit ist
• Assembly Informationen hinzugefügt und vervollständigt

Hat jemand von euch da eine Idee? Habe jetzt schon ziemlich viel ausprobiert, leider schreibt die Hauptanwendung keinerlei Protokoll oder Log.

Vielen, vielen Dank
Mario

Vielen, vielen Dank noch mal für eure Hinweise und Unterstützung.

Welche Variante es nun wird, das muss ich mir noch genau überlegen.

Den Aufwand möchte ich möglichst gering gehalten. Im Grunde ist es der erste Meilenstein die paar Outlook Methoden zu implementieren.
Das ist das einzige Hindernis bezüglich Erneuerung der Office Software Umgebung und endlich die "Entkopplung" zu der alten Produktionssoftware.

Mit O365 ist meine Firma nicht so glücklich, wegen der allgemeinen "Cloud" Abhängigkeit. Aber mal sehen, sehr wichtig war hier einen Fuss in diese Schnittstelle zu kriegen.

Also, vielen vielen Dank noch mal an alle Mitwirkenden.

Viele Grüße
Mario

Hallo.. und Freude, Freude, Freude..

@Th69

Dein Testbeispiel hat funktioniert. Ich habe ein CLR Projekt erstellt und das Testbeispiel als .cpp Datei implementiert. Diese als DLL kompiliert und in das Verzeichnis vom Hauptprogramm kopiert.

An einer passenden Stelle in einem Script vom Hauptprogramm habe ich einen Toolbarbutton erzeugt und eine Methode ausgeführt, welche den externen Aufruf in die DLL macht. So sieht der Aufruf aus dem Script aus (genau wie bei der Outlook DLL):

external string function MyTest(long id)  "DllTest", "MyTest";
void function DllTest_ButtonClick()
{
    // use external method from DllTest.dll
    string result = MyTest(999);   
    // show result as MessageBox
    MgB(result);
}  

Und siehe da, es geht einfach. 😃

Das ist doch mal ein Ansatz.. aber noch ein Weg. 😉

Ja.. das werde ich die nächsten Tage einmal testen. Ich werde berichten 😉...

Vielen Dank an euch und dass ihr euch die Zeit dafür nehmt. Das schätze ich sehr.

Viele Grüße
Mario

@gfoidl

Da habt ihr aber eine sehr weitsichtige Führungsetage. Das ist schon fast grob fahrlässig -- leider aber auch sehr oft anzutreffen.
Wir hier ernsthaft daran geglaubt, dass das System, an welchem die ganze Produktion hängt, durch Reverse Engineering, Rumbasteln an einer DLL, etc. in die Zukunft gehebelt wird?

ja, du hast ja so recht... leider :- |  seit ich hier die letzten 2 Jahre arbeite, mache ich nur solche Dinge, um hier irgendwie Ordnung und Fortschritt zu ermöglichen. Das letzte Update dieser Software war 2013 und hat nach Aussagen der Mitarbeiter fast 1 Jahr benötigt bis alles wieder lief. Kein Wunder, durch das integrierte Scripting wurde die Sofware zu >80% customized.

Als einziger mit Entwickler Know-How versuche ich solche Dinge ohne große "Schmerzen" zu lösen. Hier gibt es eben noch etliche andere Projekte.

Mir ist die ganze Architektur hier noch unklar und du beantwortest leider die Fragen nicht.

Das habe ich schon erklärt, die Hauptanwendung unterstützt eine Scriptsprache (ähnlich C). Letztendlich ein Software-Kern, der per Scriptsprache gesteuert und weiterentwickelt werden kann. Ein Großteil der Programmlogik ist damit abgebildet. In dieser Scripts werden aber auch externe DLL (wie die Outlookanbindung) angesprochen. Siehe das Bild, was ich mit gepostet hatte.

• Ist die Hauptanwendung nativ od. managed -- also C/C++ od. C#?

Ist keinesfalls C# , vermutlich C++. Woran könnte man das erkennen? Vom Stil her sieht der Client aus wie ein Office 2010. Die Anwendung benötigt die vcredist_x86.exe Runtime als Vorraussetzung.

Was soll die zu ersetzende DLL genau ansprechen? Neueres Outlook...

Ja, ein neues Outlook oder eine neuere API. Die Methoden sollten weitestgehend gleich bleiben, um die Anwendungslogik nicht überall anpassen zu müssen.
Die Idee war eigentlich schon, eine .NET Implementierung als Brücke zu nehmen.

Ich hoffe, dass die Infos nun etwas besser sind.. 😉

Achso als Nachtrag:

ist das lizenzrechtlich hier gestattet?

Wie haben einen "guten Draht" zum Softwarehersteller, bzw. zum Implementierer. Der Tipp kam vom Entwickler selbst, in diese Richtung zu gehen. Der Hersteller, bzw. die Ansprechpartner wissen, dass wir nie ein Update machen werden. Kaufmännisch gesehen ist es hier verbrannte Erde. Unsere GF möchte dafür keinen mehr Invest tätigen. 
Und ja, ich weiß, dass das eine schwieriges Thema ist. Aktuell habe ich das nur als Test, wenn überhaupt, wird mir das nur bei der Rekonstruktion der Methoden Signatur helfen.

oh vielen Dank Th69..  das ist doch schon mal ein Ansatz.. dem werde ich nachgehen und mal testen.. 😃

Achso, mein aktueller Stand ist:

Ich habe die DLL erfolgreich als Visual Studio Projekt per Reverse E. erstellen können.  Daher kenne ich zumindest die externen Methoden.
Dieses Projekt kann ich bereits als eigene DLL wieder kompilieren und dem Hauptprogramm "unterschieben" ohne einen Programmfehler zu verursachen.

Da ich aber kein C++ Profi bin, komme ich nicht wirklich richtig weiter.

Guten Morgen, vielen vielen Dank für eure Posts, Anregungen und Analysen.

Der Beschreibung - leider hat das der Thread-Ersteller vergessen - könnte das die alte/veraltete C++ API von Outlook (2010?) sein.

Ja, es ist eine DLL, welche ein "altes" Outlook bis 2013 anspricht.

Der Architektur nach zu urteilen wird die DLL dynamisch (per Linker) angesprochen. 
Allerdings bin ich mir da nicht sicher, da diese auch beim Programmstart entweder geprüft oder aufgerufen wird.

Als weiterführende Info (siehe Screenshots):
Das Hauptprogramm ist durch Scripting anpassbar (C ähnliche Sprache). Die Funktionen der "Outlook" DLL werden in den Scripts per Import angesprochen, ich nehme an, dass das zur Laufzeit per Linker dynamisch angesprochen wird?

Ich kann nicht beurteilen, ob es eine alte Microsoft Bibliothek ist, die DLL ist jedenfalls vom Softwarehersteller.

Ich suche nach einem Weg, diese Schnittstelle zu ersetzen, um eine neueres Office/Outlook damit ansprechen zu können.
Genau diese Schnittstelle ist der Grund, weshalb die ganze Firma immer noch mit Office 2010 arbeiten muss.

Ein Upgrade der Hauptsoftware ist aus Kostengründen (>100.000€) nicht möglich und nach heutigem Stand auch nicht mehr sinnvoll. 
Ein Ersatz ebenfalls nicht, da eine ganze Produktion daran hängt.