Managed Code, Native Code, C++ und C#: Jede Menge Probleme


Thomas Wölfer
Thomas Wölfer

01. September 2004


Wenn man eine Solution mit unmanaged c++ Code, managed c++ Code und C# Code am Leben halten will, dann bekommt man jede Menge Problem. Viele davon resultieren direkt aus der Tatsache, das Visual Studio .Net 2003 nicht ganz das tut, was man meint das es tut. Besonders wenn es um Referenzen im Projekt-Tree geht.

In einem C# Projekt klappen Referenzen auf andere C# DLLs ganz wunderbar. Aergerlicher wird die Sache mit C++ Projekten. Auf folgendes muss man aufpassen:

  • Hat man in einem managed C++ Projekt eine Referenz auf ein anderes managed C++ Projekt, und verschiebt man dann im anderen Projekt den Zielort der DLL, dann wird das im referenzierenden Projekt nicht bemerkt. Resultat: Cannot find the ... blablabla. Lösung: Nach der Aenderung des Zielortes muss man die Referenz entfernen und danach wieder einfügen - dann gehts wieder. (Macht Spass, wenn man mit über 30 Projekten hantiert... :-( )
  • Entfernt man die Referenz, linkt statt dessen gegen die Import-Library und kümmert sich andersweitig darum das die referenzierte DLL kopiert wird, dann gehts. Hat man aber ein #using Statement zur DLL im C++ Code, dann wird die referenzierte DLL hintenrum manchmal doch wieder kopiert. Resultat: Cannot copy blablabla... diesmal, weil die Ziel-DLL schon da ist. :-( Lösung: Man vermeide in diesem Zusammenhang #using
  • Hat man eine Referenz auf ein Projekt mit einer unmanaged DLL, dann kopiert die IDE diese DLL _einmal_ in das Zielverzeichnis - und zwar, wenn man die Refernez anlegt. Danach aber nie wieder. Gibts ein neues Build und startet man das Projekt, dann wird entweder falscher Code (der vom letzten Build) verwendet, oder die DLL fehlt ganz und man kann erst gar nicht starten.

Folgendes funktionert hier bisher hingegen verlässlich:

  • Kein #using in c++, egal ob managed oder unmanaged
  • Keine Referenzen auf Projekte mit nativen DLLs
  • Linken immer gegen die c++ Import-Library
  • Kopieren der erwünschten DLLs von Hand mit einem Post-Build Step
  • Managed-DLLs immer brav in dem Verzeichnis anlegen lassen, in dem VS das per Default tut