Hallo, ich bin gerade dabei eine kleine Anwendung für einen Kunden zu schreiben und möchte diese bald übergeben. Wie gebe ich diese Anwendung am Besten an den Kunden weiter? Ich vermute mit dem Release-Ordner ist es nicht getan! Zusätzlich will ich vermeiden, dass dieser eventuell bestimmte Bibliotheken etc. nachinstallieren muss. Habe mir für dieses und natürlich auch für folgende Projekte das Buch "Visual C++ 2008 Kompendium" geholt, jedoch steht da nix zu meinem Problem drin. Danke.
Nun, Forms setzt auf .Net auf, die passende .Net-Runtime gehört also auch noch dazu. Es sollte eigentlich ein Installationsprogramm geben, das aus Deiner Anwendung und dem ganzen davon verwendeten Kram ein Paketchen (*.msi) schnürt, das Du Deinem Anwender zukommen lassen kannst. So etwas sollte bei den .Net-Varianten des Visual Studio enthalten sein.
Hallo Thomas, eigentlich passt das mit dem Ordner schon. Die EXE und alle selbst entwickelten DLLs in einem Ordner. Wichtig: Auf einem anderen Rechner, nicht dem Entwicklunsgrechner, antesten. Ein eigenes Installationsprogramm ist natürlich schön. Dieses legt die Ordner, Icons, Startverknüpfungen etc. an. Hier gibt es sehr gute freie Programme, z.B. Inno-Setup. Die passende .NET Runtime (2 / 3.5) ist auf den meisten Windows Rechnern schon installiert, bzw. kann vom Kunden selbst heruntergeladen werden. Es gibt genügend Programme die das Vorhandensein der passenden .NET Runtime voraussetzen. Ich stimme da nicht mit Rufus überein. Schon das hinzupacken der .NET2 Runtime erhöht die Installationsgrösse auf 22 MByte. Für .NET3.5 bei knapp 60 MByte, Multilanguage Version: um die 200 MByte! Weiterhin gibt es da noch Unterschiede 32- und 64 Bit die zu beachten sind. Da geht dann nicht: ich sende mal schnell eine Mail mit der neuesten Programmversion. Denkbar ist da noch, dass man den 2 Mbyte Web-Installer von MS reinpackt. Ist aber aufwendig und benötigt dann beim Kunden eine Internetverbindung. Peter
pewu schrieb: > Ich stimme da nicht mit Rufus überein. Schon das hinzupacken der .NET2 > Runtime erhöht die Installationsgrösse auf 22 MByte. Als Kunde würde ich es nicht akzeptieren, dass die Installation irgendwelche Fehler produziert, weil Teile fehlen, die ich dann per Hand aus dem Netz herunterladen und nachinstallieren muss. Zumindest auf der ersten Auslieferungs-CD sollte das Framework zumindestens separat mit dabei sein.
Sag doch erstmla in welcher Sprache du Programmier hast. Bist du sicher das C++ ist oder ist es c++.net bzw c#?
grastino (gastino unterwegs) schrieb: > Die passende .NET Runtime (2 / 3.5) ist auf den meisten Windows Rechnern > schon installiert, bzw. kann vom Kunden selbst heruntergeladen werden. > Es gibt genügend Programme die das Vorhandensein der passenden .NET > Runtime voraussetzen. Also ein solches Programm möchte ich als Kunde nicht vorgesetzt bekommen! Das hat ohne externe Abhängigkeiten installierbar zu sein!
pewu schrieb: > Ich stimme da nicht mit Rufus überein. Schon das hinzupacken der .NET2 > Runtime erhöht die Installationsgrösse auf 22 MByte. Warum wohl mache ich um das von mir gerne so genannte .Net-Geraffel einen so großen Bogen?
Erstmal danke für die Antworten. @pewu Die Software habe ich auf 3 anderen Rechnern getestet und sie lief bisher ohne Probleme an. @grastino Ich sehe es ähnlich wie du. Der Kunde bekommt von mir eine CD mit allen relevanten Updates (Framework etc.) und im Anschluss erfolgt die aktualisierung der eigentlichen Software per Mail. @Peter Ich programmiere in C++. Zumindest vermute ich es! Ich kenne zwar nicht wirklich den Unterschied zu C++.net, aber prinzipiell müsste es C++ sein.
Thomas W schrieb: > Ich programmiere in C++. Zumindest vermute ich es! Ich kenne zwar nicht > wirklich den Unterschied zu C++.net, aber prinzipiell müsste es C++ > sein. Wenn Du eine Forms-Anwendung programmierst, also eine, die auf dem .Net-Framework aufbaut, dann programmierst Du nicht in C++, sondern in einer C++-artigen Sprache namens "Managed C++" bzw. "C++/CLI". Ein deutliches Merkmal ist der ausschließlich in dieser Sprache existierende "Objektzeiger" ^ und die Verwendung von gcnew anstelle von new.
Achso! Da es sich um eine Windows Forms Anwendung handelt und ich wirklich des Öfteren mit gcnew zu tun habe, handelt es sich um "Managed C++" bzw. "C++/CLI". Danke für die Info^^.
Selbst ohne Forms/.NET braucht man für Visual Studio das Redistributable Package. Leider ist es nicht mehr so wie früher, dass ein für Windows geschriebenes Programm automatisch überall läuft! Wir schreiben unsere Programme mit Mingw/GCC und wxWidgets, da kommt am Ende noch ein echtes .EXE heraus, das keine speziellen DLLs und Runtime Packages braucht...
Wurde noch nicht erwähnt: http://nsis.sourceforge.net Damit kann man mit etwas Skriptkonfiguration ein Install-exe produzieren, wie es alle anderen auch haben. Man kann auch weitere Install-Programme zB. für das VS-Redistributable oder .net rausstarten.
Guten Morgen. Ich habe jetzt ein wenig mit dem "Inno Setup Compiler" rumgespielt (ähm ich meinte natürlich experimentiert^^) und ich muss sagen, ein wirklich schönes Tool. Habe jetzt eine kleine Setup.exe erstellt und vcredist_x64/vcredist_x86 und den Webinstaller von Netframe 3.5 integriert. Je nach bedarf kann der Kunde, falls die Anwendung nicht laufen sollte, die benötigte Software nachinstallieren. Die .exe ist im Moment etwa 7 MB groß, was in meinen Augen noch erträglich ist.
Rufus t. Firefly schrieb: > pewu schrieb: >> Ich stimme da nicht mit Rufus überein. Schon das hinzupacken der .NET2 >> Runtime erhöht die Installationsgrösse auf 22 MByte. > > Warum wohl mache ich um das von mir gerne so genannte .Net-Geraffel > einen so großen Bogen? Wegen 22 MByte? So groß ist das tägliche Adobe Update ;-). Es gibt sicherlich viele Gründe, .NET nicht einzusetzen. Aber die Größe der Kompilate ist meiner Meinung nach nicht einer der Hauptgründe.
Zumindest bei C# Projekten geht: Build -> Publish und fertig. Das spuckt nen simplen Installer aus, der auch falls notwendig den .Net-Framework -Installer herunterlädt. Vielleicht gibts da bei C++/CLI Projekten ja auch? Je nach Visual Studio Edition kann man auch Setup-Projekte anlegen (man hat mehrere "Setup and Deployment"-Projekttypen zur Verfügung)
Danke für die Tipps^^!
Jetzt aber eine weitere Frage. Der Kunde kann beim Installieren einen
eigenen Installationspfad wählen. In diesem hinterlegt meine Software
eine ".rtf", welche ich für eine Notsicherung beim Absturz etc.
benötige.
Denn Installationspfad kann ich mit
"LoadFile(Path::GetFullPath(".\\SystemIni.rtf")"
auslesen. Das Problem ist nur, sobald der Kunde meine SW über das
Startmenü startet, wird diese ".rtf" nicht gefunden, da er in "Dokumente
und Einstellungen\xxx\SystemIni.rtf" sucht.
Kennt ihr hierfür eine Lösung? Bzw. gibt es eine Möglichkeit den Wert
einer Variable (int) andereweitig zuspeichern, damit diese nach dem
Neustart der SW wieder zur Verfügung steht?
Thomas W schrieb: > Denn Installationspfad kann ich mit > "LoadFile(Path::GetFullPath(".\\SystemIni.rtf")" > auslesen. Das Problem ist nur, sobald der Kunde meine SW über das > Startmenü startet, wird diese ".rtf" nicht gefunden, da er in "Dokumente > und Einstellungen\xxx\SystemIni.rtf" sucht. > > Kennt ihr hierfür eine Lösung? Bzw. gibt es eine Möglichkeit den Wert > einer Variable (int) andereweitig zuspeichern, damit diese nach dem > Neustart der SW wieder zur Verfügung steht? eventuell liegt es an den Rechten. man sollte Daten nicht im Programmordner speichern. Es gibt die Möglichkeit der Registry oder die Umgebungsvariable "APPDATA" dort kannst du denn für deine Anwendung ein Path anlegen und dort die Datei speichern.
Angehängte Dateien:
-
Firefox.gif
17 KB
@Thomas Das Problem dürfte daran liegen, dass im Startmenü in der Verknüpfung zu Deinem Programm das Feld "Ausführen in" nicht gesetzt ist. Gruß Markus
Unter neueren Windows-Versionen darf eine Anwendung nicht in das Programme-Verzeichnis schreiben, Deine "Notsicherungsdatei" musst Du also an anderer Stelle unterbringen. Wenn sie benutzerspezifische Daten enthält, gehört sie in den Profilpfad des jeweiligen Benutzers, wenn nicht, dann gehört sie in den "All Users"-Pfad. Diese Pfade sind mit Environmentvariablen auffindbar, und je nach Windows-Version sehr unterschiedlich gesetzt: XP ALLUSERSPROFILE=C:\Dokumente und Einstellungen\All Users APPDATA=C:\Dokumente und Einstellungen\Benutzerkontoname\Anwendungsdaten Windows 7 ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\Benutzerkontoname\AppData\Roaming Wie auch immer, lege unterhalb des Pfades ein Verzeichnis für Deine Anwendung an (das Du sinnvollerweise nach der Anwendung benennen solltest) und pack Deine Datei da 'rein. Den Pfad bestimmst Du mit der Win32-API-Funktion "GetEnvironmentVariable".
1 | DWORD WINAPI GetEnvironmentVariable( |
2 | __in_opt LPCTSTR lpName, |
3 | __out_opt LPTSTR lpBuffer, |
4 | __in DWORD nSize // maximal 32767! |
5 | ); |
Rufus t. Firefly schrieb: > Den Pfad bestimmst Du mit der Win32-API-Funktion > "GetEnvironmentVariable". zum glück geht das ein wenig schöner in .net string p = GetEnvironmentVariable("APPDATA");
Naja, die Win32-API ist halt dafür ausgelegt, aus C heraus aufgerufen werden zu können. Da lässt sich so etwas nicht sinnvoll anders erledigen. Die .Net-Runtime ist auch nur ein Wrapper drumherum, der schlussendlich die Win32-API-Funktion aufruft.
Environment.GetFolderPath() oder Application.UserAppDataPath gäbe es da auch noch. Datei-Operationen, etc. suchen nach Dateien ohne vollständige Pfadangabe immer im "Current Directory", welches nicht immer mit dem Verzeichnis der exe übereinstimmen muss (kann auch während das Programm läuft z.B. durch FileDialog-Dinger geändert werden!) -> Vermeide relative Dateipfade Über Application.ExecutablePath kommt man an den Pfad zu deiner .exe Mittels Path.GetDirectoryName() kann man dann das Verzeichnis kriegen. Dann noch deine .rtf dranhängen und du hast nen absoluten Pfad.
bluppdidupp schrieb: > Über Application.ExecutablePath kommt man an den Pfad zu deiner .exe > Mittels Path.GetDirectoryName() kann man dann das Verzeichnis kriegen. > Dann noch deine .rtf dranhängen und du hast nen absoluten Pfad. Das geht zwar, aber genau da gehört so eine Datei nicht hin.
Zumindest wenn ich nur lesend drauf zugreife sehe ich da kein Problem?
Dann natürlich nicht. Es ging aber um so etwas hier: > In diesem hinterlegt meine Software eine ".rtf", welche ich > für eine Notsicherung beim Absturz etc. benötige. Das impliziert einen Schreibzugriff - verboten.
Ah, da hab ich wohl zu schnell überflogen ;D
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.