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.
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.
@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".
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.
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.
