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

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.

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.

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 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).

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

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.