VC++ deployment

[the incredible Leitman]

Hallo zusammen

Ich hab ein Problem damit, wie man "richtig" eine .exe, geschrieben in VC++, .net 2.0 auf einem Zielrechner deployed -.-

Zur Vorgeschichte:
Soweit ich weiß, MÜSSEN Anwendung welche in VC++ geschrieben wurden ein manifest beinhalten... dieses kann entweder embeded sein,
oder aber der .exe beiliegen.

Des Weiteren muss natürlich die c++ runtime auf dem Zielrechner vorhanden sein.
Hierbei stellt sich mir schon die Frage: MUSS zwingend dieselbe Version vorhanden sein?
Was passiert, wenn stattdessen eine niedrigere minor auf dem Zielsystem liegt?
Was bei einer höheren?

Da ich mich bei dem Deployment nicht darauf verlassen kann, dass der User Administrationsrechte hat, verwende ich die Methode aus der MSDN (glaub "XCopy" wurde die genannt?) bei der man die benötigten .dlls einfach mitliefert.


so weit, so gut, bis daher bin ich gut raus ^^

Nun beginnt das Ganze aber, für mich unverständlich zu werden

Wie sieht das "allgemein" mit .net aus? Ich habe .net in der Version 2.0 (mit Updates) installiert und verwende Funktionalitäten davon.
Heißt das nun, ich muss auf dem Rechner .net 2.0 installiert haben? Oder sind genau das die genannten .dlls a'la msvcr80, msvcp80, msvcm80 ?


Da ich nun bereits einige Zeit daran hänge, habe ich schon den in VS mitgelieferten "Dependency walker" verwendet um zu sehen, welche Bibliotheken ich eigentlich ausliefern muss.
Hierbei sehe ich aber, dass in einer release kompilierten Anwendung die msvcp80D.dll geladen wird / werden soll?
Gibt es eine Möglichkeit, herauszufinden, WARUM meine Applikation diese debug Bibliothek laden möchte?


Des weiteren, würde mich intressieren, wie das Ganze mit den "nicht .net" spezifischen dlls aussieht.
So lade ich unter WinXP ganz normal die gdiplus.dll, welche ich zum zeichnen verwende,
in der neuesten Version auf meinem Entwicklungsrechner.
Kann ich die ebenfalls mitgeben?
Oder wie verhält sich das Programm, wenn ich es z.B. unter Win2000 ohne gdiplus auführen möchte?

Das Problem ist nämlich, wenn ich es unter Server 2003 starte (mit dependency walker) schlägt das Laden der gdiplus.dll fehl ? Obwohl diese auf dem System (halt in einer anderen Version als bei mir) vorhanden ist (im WinSxS Ordner).

Ebenso hierzu kommt die common control dll (die ich angeblich verwenden soll,
um "schönere" visuelle Elemente zu bekommen)


Wäre wundervoll, wenn mich jemand hier aufklären könnte
mfg
the incredible Leitman

 

[MCoder]

Hallo,

zunächst stellt sich die Frage, was für eine VC++ - Anwendung du überhaupt erstellst. Was meinst du damit, dass du Funktionalitäten aus .NET2.0 verwendest? Hast du ein CLR-Projekt (z.B. Windows-Forms-Anwendung) erstellt?

Die von dir genannten DLLs sind die C++ - Laufzeitbibliotheken von VC++; .NET liegt im Windows-Verzeichnis unter Microsoft.NET. Die Installation ist etwas komplexer, als ein paar DLLs zu kopieren.

Für die Installation auf dem Zielrechner gibt es von Mirosoft Redistributables für alle möglichen Situationen (.NET, MFC, C++, GDI++) zum Download. Da musst du einfach mal suchen.

Eine Release-kompilierte Anwendung sollte keine Debug-DLLs anziehen. Hast du mal das Projekt bereinigt und dann vollständig neu erstellt?

Gruß
MCoder

 

[the incredible Leitman]

Hey MCoder,

und erstmal Danke für deine Antwort

zunächst stellt sich die Frage, was für eine VC++ - Anwendung du überhaupt erstellst. ... Hast du ein CLR-Projekt (z.B. Windows-Forms-Anwendung) erstellt?

Ja, genau das
Die Anwendung ist eine Windows-Forms Anwendung, geschrieben in VC++, compiliert in clr in .net 2.0

Die von dir genannten DLLs sind die C++ - Laufzeitbibliotheken von VC++; .NET liegt im Windows-Verzeichnis unter Microsoft.NET. Die Installation ist etwas komplexer, als ein paar DLLs zu kopieren.

Das habe ich mir schon gedacht :-/
Aber, wie bekomme ich mit, wenn zB auf dem Zielrechner die .net Version nicht vorhanden ist?
Würde dann eine entsprechende Fehlermeldung kommen a'la "bitte installieren sie dotnet!" ?
Nehme ich mal nicht an xD

Was die Microsoft Redistributables angeht, werde ich mal suchen, was GDI+ angeht,
die dlls für vc++ kann ich einfach mitliefern, das habe ich schon hinbekommen.

EDIT:
okay, ich habe eine redistributable dll für gdi+ gefunden

Nun frage ich mich, wie ich diese korrekt in die Anwendung einbinde?
Prinzipiell würde ich es, da vc++ Anwendungen sowieso ein Manifest brauchen, in dieses einbinden?
Also:

<dependency> 
    <dependentAssembly> 
        <assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus" version="1.0.6002.22509" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*"/>
    </dependentAssembly> 
</dependency>

Ebenso sollte das nun auch für die common Controls library gehen? (comctl32.dll)
--- /EDIT

Eine Release-kompilierte Anwendung sollte keine Debug-DLLs anziehen. Hast du mal das Projekt bereinigt und dann vollständig neu erstellt?

Ja, das sehe ich auch so, deswegen möchte ich auch die Debug Anforderung rausbekommen.
Leider weiß ich nicht, WARUM meine Anwendung diese laden möchte
Kann man das irgendwie über die Projekteinstellungen oder so nachvollziehen?

Das komplette Projekt neu aufsetzen gestaltet sich ein wenig anstrengend,
wenn du damit meinst, ein neues Aufsetzen und danach die ganzen files und Einstellungen übernehmen?
Das komplette "Ding" ist über 2Gig groß und beinhaltes über 800 Files (fast 6 Jahre Entwicklungszeit)

 

[MCoder]

Das Projekt neu aufsetzen meinte ich nicht. Du hast ja bei "Erstellen" (wenn du im Projektmappen-Explorer ganz oben stehst) auch Funktionen wie "Projektmappe bereinigen" und "Projektmappe neu erstellen". Vielleicht hilft das ja schon.

Ich glaube mich zu erinnern, dass bei einer CLR-Anwendung schon eine entsprechende Meldung bei einem fehlenden .NET-Framework erscheint.

Mit einer .NET2.0-Redistributable-Installation solltest du eigentlich auch ein passendes GDI+ mit auf den PC bekommen, weil .NET das ja auch braucht.

Gruß
MCoder

 

[the incredible Leitman]

Das Projekt neu aufsetzen meinte ich nicht. Du hast ja bei "Erstellen" (wenn du im Projektmappen-Explorer ganz oben stehst) auch Funktionen wie "Projektmappe bereinigen" und "Projektmappe neu erstellen". Vielleicht hilft das ja schon.

Ahhh... okay, ich nehme an du meinst im englischen VS die Punkte "clean solution" und "rebuild solution" ?
hm... klingt nach einer Idee... ich habe öfters seltsame Situationen, die sich aber beheben lassen, wenn ich das komplette Projekt erneut komplett durchkompiliere.
Werde das mal machen... dauert ungefähr eine Stunde, melde ich mich dann wieder xD

Ich glaube mich zu erinnern, dass bei einer CLR-Anwendung schon eine entsprechende Meldung bei einem fehlenden .NET-Framework erscheint.
Mit einer .NET2.0-Redistributable-Installation solltest du eigentlich auch ein passendes GDI+ mit auf den PC bekommen, weil .NET das ja auch braucht.

okay super, das wäre fein.
Denn von einem .net2.0 framework gehen wir mindestens aus, also das muss auf dem Zielrechner vorhanden sein, was bedeutet dass mindestens ein gdi+ auf dem Zielrechner existiert.

 

[the incredible Leitman]

Sry, hat nun doch etwas länger gedauert xD

Jedenfalls ich habe jetzt das komplette Projekt (mit einigen abgeänderten Einstellungen in den projektsettings) nochmal durchkompiliert.
Zumindest habe ich jetzt ein ordentliches .manifest und kann auf dem Zielrechner ohne Probleme starten (party) ^.^
Dabei wird nun die mitgegebene vc++ runtime, sowie gdiplus geladen


Was ich jedoch immer noch nicht verstehe, warum benötigt meine im release kompilierte Anwendung die debug runtimes?
Gibt es eine Möglichkeit, herauszufinden, WARUM dieses Assembly eingebunden wird?

mfg
the incredible Leitman

 

[MCoder]

Benutzt das Programm noch irgendwelche externen Komponenten, also DLLs oder statischen Libs? Wenn ja, liegt vermutlich irgendeines dieser Teile als Debug-Version vor.

Gruß
MCoder

 

[the incredible Leitman]

Danke nochmal MCoder, dass du dir soviel Zeit nimmst

Nunja, ich verwende externe dlls,
zum einen einige von Component One (die da wären C1Pdf, C1FlexGrid, C1Command),
das Excel Api (Interop.Excel.1.5 und MSORUNLib.1.0)
und die Standard Referenzen wie System, System.Configuration, System.Xml, System.Drawing usw...

Ansonsten binde ich externe dlls von ACE, TAO ein,
die aber alle in Release kompiliert wurden.

Aber soweit ich informiert bin werden Debug libraries mit dem Abschluss %d.dll benannt?

 

[MCoder]

Bei Third-Party-Komponenten sehe ich weniger das Problem, aber vielleicht erstellt ihr ja auch Komponenten aus eigenen Projekten ?

Aber soweit ich informiert bin werden Debug libraries mit dem Abschluss %d.dll benannt?

Was auch hoffentlich jeder weiß, der solche Teile in den Umlauf bringt

Es kann ja nicht schaden, alle Komponenten mal mit dem Dependency Walker zu checken. Ansonsten habe ich jetzt auch keine weiteren Ideen.

Gruß
MCoder

 

[the incredible Leitman]

hm... vielleicht könnte ich dir noch ein wenig deiner Zeit stehlen (blush)

Weißt du eventuell, WIE die automatische .manifest Generierung bei VS2005 Vc++ Projekten zustande kommt?

Ich habe gesehen, dass ich stellenweise Komponenten aus dem System:iagnostics namespace verwende (wie Stopwatch oder Write).
Kann das dazu führen, dass dewegen die Debug runtimes eingebunden werden?