1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

VC++ deployment

Dieses Thema im Forum ".NET Windows Forms" wurde erstellt von the incredible Leitman, 16. März 2012.

  1. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    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? o_O

    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? o_O
    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 ? o_O 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
  2. MCoder

    MCoder Premium-User

    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
  3. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    Hey MCoder,

    und erstmal Danke für deine Antwort :)

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


    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:
    Code (Text):
    1.  
    2. <dependency>
    3.     <dependentAssembly>
    4.         <assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus" version="1.0.6002.22509" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*"/>
    5.     </dependentAssembly>
    6. </dependency>
    Ebenso sollte das nun auch für die common Controls library gehen? (comctl32.dll)
    --- /EDIT


    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 o_O
    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)
    Zuletzt bearbeitet: 19. März 2012
  4. MCoder

    MCoder Premium-User

    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
  5. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    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


    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.
  6. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    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? o_O
    Gibt es eine Möglichkeit, herauszufinden, WARUM dieses Assembly eingebunden wird?

    mfg
    the incredible Leitman
  7. MCoder

    MCoder Premium-User

    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
  8. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    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?
  9. MCoder

    MCoder Premium-User

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

    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
  10. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    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::Diagnostics namespace verwende (wie Stopwatch oder Write).
    Kann das dazu führen, dass dewegen die Debug runtimes eingebunden werden?
  11. MCoder

    MCoder Premium-User

    Also, mit den Details der Manifest-Generierung habe ich mich noch nicht näher befasst. Da kann ich dir leider nix Genaues sagen.

    Dass der Diagnostics-Namespace die Debug-Librariers anzieht, denke ich nicht. Mit einem kleinen Testprogramm sollte sich das aber schnell prüfen lassen.

    Gruß
    MCoder
  12. the incredible Leitman

    the incredible Leitman Erfahrenes Mitglied

    Na gut,
    dann erstmal herzlichen Dank MCoder, für deine Hilfestellung :)

    Ich werde noch ein wenig mit unterschiedlichen Projectsettings testen,
    wenn ich etwas rausbekomme melde ich mich wieder und poste meine Errungenschaften ^.^

Diese Seite empfehlen