DLL in Visual Studio erstellen ohne Abhängigkeit von .NET

[Georg (Gast)]

Hallo,

ich habe eine DLL in Visual Studio C++ erstellt. Die DLL benötigt nur 
ein paar Funktionen aus dem Windows Driver Kit. Leider hat sich aber 
herausgestellt, das die DLL auch auf .NET 4.0 besteht.

Mein Frage lautet nun: wie bekomme ich die Abhängigkeit von .NET 4.0 
weg? Was genau muß ich in den Compiler/Linker-Einstellungen vornehmen?

Danke und Gruß Georg

[Rufus Τ. F. (rufus)]

Georg schrieb:
> ich habe eine DLL in Visual Studio C++ erstellt

Nein, Du hast sie in "C++/CLI" bzw. "Managed C++" erstellt. Beides 
enthält zwar "C++" im Namen, ist aber kein C++, sondern eine 
Microsoft-Perversion für die .Net-Programmierung, letztlich nur ein 
anderes Dekor für C# oder VB.Net.

Visual Studio enthält aber auch einen exzellenten echten C++-Compiler, 
wenn Du also Dein Projekt neu anlegst, und bei der Auswahl des Projektes 
darauf achtest, natives C++ zu verwenden, dann geht das, was Du willst.

Nachträglich umstellen allerdings lässt sich das nicht.

[Klaus W. (mfgkw)]

Rufus Τ. Firefly schrieb:
> Nachträglich umstellen allerdings lässt sich das nicht.

Sicher?
Letztlich müsste man doch die ganzen Einstellungen, die man mit der 
Auswahl des falschen Projekts am Anfang macht, auch wieder umsetzen 
können?

Man könnte doch mal vergleichsweise je ein Projekt mit dem richtigen un 
dem falschen Projekttyp anlegen, und in dem vorhandenen alle 
entsprechend ummodeln.

[Rufus Τ. F. (rufus)]

Klaus Wachtler schrieb:
> Letztlich müsste man doch die ganzen Einstellungen, die man mit der
> Auswahl des falschen Projekts am Anfang macht, auch wieder umsetzen
> können?

Vollständig ausschließen will ich das zwar nicht, aber das dürfte beim 
Wechsel von .Net auf was richtiges ziemlich bis verdammt kompliziert 
werden, ist ja nicht so, daß MS die ganzen Optionen und Einstellungen 
sinnvoll und klar verständlich bezeichnet.

Ich traue mir das jedenfalls nicht zu, den für das Erforschen 
erforderlichen Zeitaufwand schätze ich signifikant größer ein als das 
Neuanlegen eines Projektes mit den richtigen Einstellungen. Und ich 
nutze MS-Compiler seit 1992 zum Geldverdienen.

Bei VS2010 jedenfalls ist als Ausgangstyp für ein neues Projekt "Win32 
Project" zu verwenden, ausgehend davon kann dann zwischen DLL, 
Konsolapplikation oder auch statischer Library gewählt werden.

[Georg (Gast)]

Danke erstmal für die schnellen Antworten.

>Bei VS2010 jedenfalls ist als Ausgangstyp für ein neues Projekt "Win32
>Project" zu verwenden, ausgehend davon kann dann zwischen DLL,
>Konsolapplikation oder auch statischer Library gewählt werden.

Genau das habe ich gemacht!

Anbei auch noch ein paar Compiler/Linker-Einstellungen.

Gruß Georg

[Georg (Gast)]

Kurzer Nachtrag:

Das Problem mit der .NET 4.0 tritt allerdings nur auf, wenn ich die DLL 
explizit bei C# oder VB lade.

Wenn ich bei C++ die DLL implizit (also per Header und LIB) verwende, 
dann beschwert er sich nur, dass die MSVCR100.dll fehlt, was man dann 
durch installieren von vcredist_x86.exe beheben kann (was im übrigen 
genau so umständlich und nervig ist). Für das .NET4.0 interessiert sich 
das Programm dann garnicht (ich habe das mit einem XP SP2 mit .NET3.5 
getestet).

Man könnte daraus schließen, dass es also vlt. garnicht an der DLL 
liegt, sondern an der Anwendung, die die DLL verwendet. Aber sicher bin 
ich mir da nicht.

[Rufus Τ. F. (rufus)]

Georg schrieb:
> Wenn ich bei C++ die DLL implizit (also per Header und LIB) verwende,
> dann beschwert er sich nur, dass die MSVCR100.dll fehlt

Das kannst Du auch unterbinden, indem Du unter "C Codegenerierung" für 
die Laufzeitbibliothek statt "Multithreaded-DLL" die entsprechende 
nicht-DLL-Variante einstellst.

> Man könnte daraus schließen, dass es also vlt. garnicht an der DLL
> liegt, sondern an der Anwendung, die die DLL verwendet.

Das ist dann ganz eindeutig der Fall. Deine DLL ist nicht schuld 
daran. C# ist eine .Net-Sprache und braucht zwingend die 
.Net-Runtimeunterstützung, VB ist auch eine .Net-Sprache (wenn es denn 
was neueres als VB6.0 ist, das schon ein paar Jährchen auf dem Buckel 
hat).

[Georg (Gast)]

Danke für die Antworten und Hinweise. Ich werde das mal ausführlich 
testen und mich dann ggf. bei euch beschweren:).

Gruß Georg

[Marcus B. (raketenfred)]

Das mit dem Net 4.0 kenne ich, hatte ich auch mal, du kannst unter 
Projekt eigenschatfen auswählen, für welche Framework-Version du 
entwickeln willst, kleinst mögliche ist da natürlich das beste, wenn 
alle benötigten Funktionen vorhanden sind

[Georg (Gast)]

Leider kann ich nichts auswählen. Bei mir steht .NET 4 und es ist 
ausgegraut. Das liegt entweder daran, dass ich hier die Express Version 
habe oder daran, dass nur .NET 4 installiert ist - keine Ahnung.

Das mit dem Linker, was Rufus geschrieben hat führt zwar dazu, dass die 
DLL größer wird (statt 20kb jetzt 75 kb - es werden wohl einige 
Abhängigkeiten entfernt), aber die msvcr100.dll wird weiterhin vermisst.

[Εrnst B. (ernst)]

der "dependency walker" (http://www.dependencywalker.com/)  kann, IIRC, 
anzeigen, welche DLL welche weiteren Abhängigkeiten mit reinzieht.
Damit müsstest du doch feststellen können, ob die Applikation oder deine 
DLL für die Abhängigkeiten verantwortlich ist.

[Georg (Gast)]

Hmm, nachdem ich also die DLL entsprechend für statisches Linken 
angepasst hatte , muss 'irgendwer' die Einstellungen bei der Applikation 
auf Multithreaded-DLL umgestellt haben. Das ist jetzt auch auf 
Multithreaded eingestellt und siehe da ... es geht!!

Ergebnis: DLL erstellt unter WIN7/.NET 4 (ohne CRT) - lauffähig jetzt 
auch unter XP SP2/.NET3.5 ohne irgendwelche Nachinstallationen.

Nochmal vielen Dank an alle, die bei der Lösung mitgemacht haben!

Gruß Georg