NoOneKnows

Okay, hier ein Beispiel. Sind 2 Konsolen-Programme. Mußt noch beachten, das in beide die System.Windows.Forms-DLL eingebunden wird. Auserdem mußte vielleicht noch die Pfade anpassen. AnyConsole.exe + UpdateConsole.exe müssen in einem Verzeichnis liegen. Den Pfad für die neue Version musst du entsprechend noch in beiden Programmen anpassen. Es würde sich empfehlen diese Info in eine XML-Config-Datei zu schreiben oder so. AnyConsole.exe using System; using System.IO; using System.Diagnostics; using System.Windows.Forms; namespace AnyConsole { class AnyConsole { private static string mNewVersionPath = Path.Combine(Path.GetDirectoryName(Application.ExecutablePath), @"..\Release\") + Path.GetFileName(Application.ExecutablePath); [STAThread] static void Main(string[] args) { if (UpdateAvailable()) { Process.Start(Path.GetDirectoryName(Application.ExecutablePath) + @"\Update.exe"); return; } Version version = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version; Console.WriteLine("Version {0}.{1}.{2}.{3}", version.Major, version.Minor, version.Build, version.Revision); Console.ReadLine(); } private static bool UpdateAvailable() { if (File.Exists(mNewVersionPath)) { FileInfo newVersion = new FileInfo(mNewVersionPath); FileInfo curVersion = new FileInfo(Application.ExecutablePath); if (newVersion.LastWriteTime > curVersion.LastWriteTime) { return true; } } return false; } } } UpdateConsole.exe using System; using System.IO; using System.Diagnostics; using System.Threading; using System.Windows.Forms; namespace Update { class UpdateConsole { [STAThread] static void Main(string[] args) { Thread.Sleep(500); UpdateApplication(); } private static void UpdateApplication() { int count = 0; string targetAppPath = Path.GetDirectoryName(Application.ExecutablePath) + "\\"; string targetApp = targetAppPath + @"AnyConsole.exe"; string newAppPath = Path.GetDirectoryName(Application.ExecutablePath) + @"\..\Release\"; while (count < 10) { count++; try { File.Delete(targetApp + ".bac"); } catch { } try { File.Move(targetApp, targetApp + ".bac"); break; } catch (Exception ex) { Console.WriteLine(ex.Message); } } if (count >= 10) { MessageBox.Show("Error occured"); return; } foreach (string filePath in Directory.GetFiles(newAppPath)) { File.Copy(filePath, targetAppPath + Path.GetFileName(filePath)); } Process.Start(targetApp); } } } Jetzt sollte das Prinzip allerdings klar sein

Ich hab sowas mal in einer anderen Programmiersprache gemacht, aber nicht in C#. Ist aber einfacher in C# Also im Hauptprogramm überprüft du am besten bevor irgendein Formular geladen wurde, ob eine neue Version des Progs im Freigabeverzeichnis vorliegt. Mit Hilfe von System.IO.FileInfo(filePath) (eine Instanz mußt du davon mit new erzeugen) kannst du an das Modifieziert-Datum kommen (LastWriteTime-Eigenschaft). Du vergleichst dann dieses Datum der aktuellen Exe-Datei (System.Windows.Forms.Application.ExecutablePath) mit dem der Executable aus dem Freigabeverzeichnis. Damit lässt sich feststellen, ob die neue Exe-Datei aktueller ist als die derzeitige. Sauberer ist der Vergleich über Versionsnummern, aber das ist glaub ich etwas komplizierter. Ist eine neue Version vorhanden, dann startest du über System.Diagnostics.Process.Start(path) das Update-Programm, daß sich im selben Pfad befinden sollte wie das Hauptproggi. Direkt danach beendet sich das Hauptprogramm über Application.Exit() selbst. Die erste Aktion des Update-Programm sollte mit System.Threading.Thread.Sleep(milliSeconds) eine kurze Wartepause sein, damit sich das Hauptproggi auch wirklich beendet hat. Da dies vielleicht immer noch nicht reicht, würde ich zuerst versuchen die Executable mit System.IO.File.Move(source, destination) zu verschieben/umzubenennen. Gibts eine Exception so warte wieder kurz mit Thread.Sleep() und versuche es erneut. Wenn es nach einigen Schleifendurchläufen nicht klappt ist irgendwas schief gelaufen. Ansonsten kannst du jetzt über System.IO.File.Copy(source, destination) die Exe-Datei aus der Freigabe kopieren. Wenn du nicht genau weißt, welche Dateien kopiert werden müssen, dann liste dir alle Dateien aus der Freigabe mit System.IO.Directory.GetFiles(path) auf und kopiere alle Dateien. Wenn es keinen Fehler gab, dann kannste nun die alte verschoben bzw. umbenannte Exe-Datei des Hauptprogramms über System.IO.File.Delete(path) löschen. Nun starte einfach das neue Programm mit Process.Start(). Danach kann sich das Update-Programm beenden. Soweit ein kurzer Abriss Du solltest den Benutzer natürlich vor dem Update informieren was passiert, damit er sich nicht wundert. Hoffe das hilf dir...

Du könntest eine Update-Funktion einbauen. Dazu muß das Programm immer lokal auf den Rechner des Benutzers gestartet werden. Du lieferst zum eigentlichen Programm ein Update-Programm mit. Das Hauptprogramm überprüft dann beim Start ob ein Update, sprich neue Version im Freigabeverzeichnis, vorhanden ist. Falls ja beendet es sich und startet das Update-Programm, welches wiederum die betreffenden Files lokal durch die neuen aus dem Freigabeverzeichnis ersetzt. Anschließend startet das Update-Programm die eigentliche Anwendung wieder und beendet sich. Ein simples Prinzip

Also bei mir funktionierts ohne Bugs. Hab die deutsche Version von Firefox 0.9.1 und just4fun mal Qute 2.1.2 installiert. Kann die Leisten ein und ausblenden ohne das irgendwelche Probs entstehen... Installier Firefox nochmal neu. Wichtig ist immer, das mans in ein neues Verzeichnis packt und nicht drüber installiert.

Schau mal hier: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&threadm=OjieaPdyDHA.2000%40TK2MSFTNGP11.phx.gbl&rnum=2&prev=/groups%3Fq%3Ddotnet%2Bctrl%2Balt%2Bdelete%26ie%3DUTF-8%26hl%3Dde%26btnG%3DGoogle-Suche

Hmm, hat dein Kollege denn keine Dokumentation angefertigt Denn damit hätte das nicht passieren sollen. Ist in meiner Firma auch so. Es gibt so gut wie keine Dokumentation und wenn man mal etwas anpassen soll, dann muß man in den Quellcode gucken und die Zusammenhänge mühselig herausfinden bzw. den Programmierer fragen. Dabei gibt es doch sogar in C# zB ein Dokumentations-Feature, aber wird kaum genutzt. Aber zurück zur Operatorüberladung, man sollte sie so verwenden das sie möglichst selbsterklärend ist. Es geht ja nicht darum, das Feature um jeden Preis zu nutzen, sondern es sinnvoll einzusetzen. 2 Objekte miteinander zu addieren, die komplexe Datenstrukturen beinhalten macht sicherlich kein Sinn Aber bei Klassen/Strukturen, die für sich einen atomaren Wert symbolisieren, wie beispielsweise DateTime oder TimeSpan macht das durchaus Sinn. Öhm, also weil du hier soviel von C++ schreibst: C++ und C# haben eingentlich nichts gemeinsam, außer die grundlegende Syntax C# ist im endeffekt genauso einfach wie VB, ich würd sogar sagen, das sich C# leichter von der Hand kodieren lässt. Einfaches Beispiel: [COLOR=Green]' VB.NET[/COLOR] [COLOR=Blue]Dim [/COLOR]hello [COLOR=Blue]As String [/COLOR]= "Hallo Welt!" [COLOR=Green]// C#[/COLOR] [COLOR=Blue]string [/COLOR]hello = "Hallo Welt!"; Das "Dim" und "As" in VB.NET sind überflüssig weil sie nichts aussagen. Außerdem find ichs sinnvoller den Variablentyp vor dem Namen anzugeben um sich das vor der Benennung bewußt zu machen. VB is eben mehr so an der Sprache orientiert. Es gibt dadurch eben zuviele Schlüßelwörter die unsinnig sind. Bei C/C++/C#/Java spart man sich diesen ganzen Schnickschnak. Wobei Java auch schon wieder anfängt überflüssige Schlüßelwörter wie extends oder implements zu verwenden. Das ist in C# auch eleganter gelöst. Ich würd jedenfalls empfehlen lieber gleich C# zu lernen, als VB.NET, da es eben mit VB6 auch nicht großartig viel gemein hat.

Tja, nun rate mal warum es dieses Zeug in VB.NET nicht gibt Is aber schon so wie du sagst, weder Operatorüberladung noch Pointer braucht man, daher hat mans auch in VB weggelassen. Es sind eben mehr nette Zusatzfeatures. MS hatte sich eben mehr auf C# konzentriert. VB.NET is aber wichtig, um die VB6 Programmierer mit ins .NET-Boot zu holen.

Kannst du eine Programmiersprache, kannst du sie alle Ja, ist im großen und ganzen nur ne Frage der Syntax. Ansonsten is C# noch etwas strenger als VB.NET was zum Beispiel typsicherheit angeht. Aber das kann man auch schnell lernen. Das andere ist eben, sich im .NET-Framework zurecht zu finden und damit umgehen zu können. Vor allem sollte man sich intensiv damit beschäftigen, was mit dem Framework alles möglich ist. Stichwörter sind zum Beispiel Remoting oder Serialisierung. Das sind Dinge mit denen kann man sich später unheimlich arbeit ersparen, wenn man weiß das es sie gibt. Bei uns seh ich halt, das Anwendungen zu umständlich programmiert worden sind, obwohl es hätte viel einfacher gehen können. Meiner Meinung reicht das Selbststudium aus, aber man sollte sich eben dabei auch mit allen Facetten des .NET-Frameworks auseinandersetzen und wenn man einfach auch nur mal gehört oder gesehen hat, das es Funktionalität XY im Framework bereits gibt. Kann echt viel Arbeit und Frust sparen

gratulation auch von mir an alle! hatte heut auch präsi und hab bestanden. da durchzufallen is auch schwierig. die prüfer waren auch super korrekt, von wegen die präsentation darf zwischen 10 und 15 minuten dauern auch die punktevergabe war großzügig. ihk hannover rockt halt...

ist garnicht so einfach, zumindest wenn die klammerausdrücke sehr kompliziert werden. ne schöne technik in dem zusammenhang ist syntax-bäume zu verwenden, aber ich glaub du hast davon wohl noch nix gehört, oder? man baut sich anhand der eingaben einen baum mit je zwei unterknoten pro hauptknoten auf. ein knoten ist entweder eine zahl, wenn es keine untergeordneten knoten besitzt, oder es entspricht einem rechenzeichen. je nachdem in welcher reihenfolge zahlen, rechenzeichen, klammer auf und klammer zu auftreten wird der baum konstruiert, heißt elemente werden zum beispiel unter- oder übergeordnet eingefügt. am schluß braucht der baum quasi nur noch durchgerechnet zu werden. ist zwar erstmal nicht so einfach, aber wenns einmal funktioniert, gehts dafür auch mit beliebig komplexen ausdrücken.

Tatsache, das Formular lässt sich noch mit Alt+F4 schließen. In der Hilfe steht allerdings unter Form.ControlBox-Eigenschaft etwas anderes: Aber dieser "Fehler" ist scheinbar bekannt.

http://www.aisto.com/roeder/dotnet/ Ich kann den .NET Relfector empfehlen. ist ein sehr schönes Tool um durch .NET-Bibliotheken oder Executables zu browsen. Zeigt allesmöglichen an, vom Delegaten über Klassen bis hin zu Strukturen. Er stellt auch alle private, protected und internal member dar, was ganz interssant ist, da man über Reflection solche Member ja auch ansteuern kann. Hat ansonsten Suchfunktionen, kann Call-Trees erstellen und sogar auch disassemblen und dekompilieren. Dadurch lässt sich auch leicht mal einen Blick hinter die .NET-System-Klassen werfen. Ist echt ein super Tool und wird auch noch stetig weiterentwickelt. Hoffentlich bleibts auch in Zukunft kostenlos

Hmm, dem Kunden kann das doch ziemlich gleich sein, in welcher Sprache das Programm entwickelt wird. Der Kunde stellt doch nur die Anforderung an das Programm und der Programmierer entscheidet doch welche Sprache, welches Datenbanksystem, welche Werkzeuge und was auch immer benutzt wird. Für den Kunden zählt doch eigentlich nur das Ziel, der Weg dorthin spielt für ihn keine Rolle, es sei denn er wollte den Quellcode haben oder so. Ist jedenfalls meine Sicht der Dinge, korrigiere mich wenn ich falsch liege Ansonsten bin ich auch der Meinung bei einem Neuanfang lieber C# zu lernen. C# und VB.NET unterscheiden sich schon in einigen Punkten, obwohl beide in MSIL kompilieren. Und C# ist meines erachtens leistungsfähiger als VB.NET. Beispiele sind Operatorüberladung oder das Verwenden von Pointern, was es beides in VB.NET defintiv nicht gibt.

Gibt auch ne Eigenschaft die nennt sich ControlBox oder so ähnlich. Mit ihr kannst du den Schließen-Button ausblenden. Damit dürfte auch Alt + F4 nicht mehr funktionieren.

Also soviel kann ich dir auch net dazu sagen. Hab nur gerade mal ein Statement mit knapp 90.000 Zeichen über ODBC auf einer Oracle-DB ausgeführt und das funktionierte. Soweit ich weiß gibt es über ODBC bei Oracle aber Probleme bei sehr langen Zeilen, sprich mehr als 2000 Zeichen. Dann stürzen die ausführenden Anwendung mehr oder weniger heftig ab.

Ne, ich glaub auch VB6 zu lernen ist fast verschwendete Zeit. Hab diese Sprache damals intensiv gelernt. Aber das war vor 6 Jahre als sie erschienen ist. Microsoft stellt den Support für VB6 in den nächsten Jahren auch endgültig ein. Im grundegenommen lernt man damit, wie schon gesagt wurde, eben eine tote Sprache. Zu jeder modernen Programmiersprache gehört heute nunmal, daß sie komplett Objektorientiert ist und VB6 ist davon weit entfernt. Auch VBA wird zwangsläufig zu einer Art VBA .NET. Lerne daher lieber VB .NET oder C#.

Ich sag nur, jede Sprache für ihren Zweck Naja, der Vergleich zwischen Delphi und VS .NET hat auf jeden Fall einen Haken: .NET-Programme sind bekannterweise als Executive noch nicht kompiliert. Werden Routinen nach dem Start das erste Mal aufgerufen geschiet die Kompilierung eben erst dynamisch. Das führt auf jeden Fall zur Zeitverlust bei .NET-Anwendungen. Aber schreib dann mal, wie ihr getestet habt und was bei rausgekommen ist... Würd mich auch mal interessieren...

Zumindest weiß man, das .NET Zukunft hat, da Microsoft diese auch noch weiter forcieren wird. Und wenn man größtenteils eh für Windows-Systeme entwickelt, warum soll man dann auf so etwas verzichten? Ich bin auch kein Microsoft-Fan, aber C# bzw. das .NET-Framework ist gut durchdacht und meines erachtens das beste, was bis jetzt in der Programmierung existiert, zumindest wenn man für Windows entwickelt. Mit wenig Quellcode lässt sich unheimlich viel erreichen. Da macht das Programmieren eben richtig spaß...

Das mit der Vererbung im Use-Case ist aber kein Geheimnis. Das kannst du gern im Internet nachlesen

Klar, Java ist von daher auch nicht so dolle. Aber man kann ja immer auch mit der Wahl der Programmiersprache entscheiden, ob einem nun plattformunabhängigkeit, geschwindigkeit, wartbarkeit oder was auch immer wichtiger ist. Würde es die eine Sprache geben, die alles kann und dazu auch noch kostenlos wäre, dann würde sich diese auch leicht durchsetzen. Aber so etwas gibt es nun mal net. Wenn man halbwegs platformunabhängig programmieren möchte und dabei auch die geschwindigkeit nicht leiden soll, dann muß man auf sowas wie ansi c zurückgreifen für das es für fast jede plattform einen compiler gibt. und jetzt mal ehrlich: wenn du mit deinem unternehmen eine monopolstellung unter den betriebssystemen hättest, würdest du dann software auf den markt bringen, die dieses monopol wieder gefährden würden? was microsoft macht ist in ihren augen ökonomisch gesehen einfach nur das richtige, nämlich .NET auf ihre betriebssysteme zu beschränken.

Tja... Wenn 2 Akteure auf einen Anwendungsfall zeigen, dann sind auch beide Akteure an diesem Anwendungsfall beteiligt. Das heißt, das ein Akteur allein einen solchen Fall nicht ausführen kann. Somit kann zum Beispiel die Anzeige nur erfolgen wenn Admin und Interessent daran mitwirken. Um das zu umgehen muß man mit Vererbung arbeiten. So haben wirs zumindest mal in der Schule gelernt

Soweit würd ich noch nicht denken. Was in 10 Jahren ist, sehen wir dann, wenns soweit ist Das es dann aber nur noch Windows und .NET geben soll wage ich stark zu bezweifeln. Delphi ist auch eine feste Größe und da Borland auch die Zeichen der Zeit erkannt hat und auf den .NET-Zug aufspringt, denke ich net, daß diese Sprache einfach untergeht zumal es eben auch viele Delphi-User gibt. So können diese weiter in Delphi programmieren und zusätzlich von .NET profitieren. Aber wo das mal alles enden wird kann eh niemand sagen. Ich weiß nur eins, als Entwickler muß man sich sowieso immer den Gegebenheiten anpassen. Also wenns irgendwann mal ein .IT mit C* gibt, dann wird eben wieder umgesattelt

Keine Ursache

@Code Poet: Ich kann dir da größtenteils nur Zustimmen. Im Endeffekt will MS seine Stellung weiter ausbauen. Aber aus Entwicklersicht gesehen ist .NET & Co ein deutlicher Fortschritt. Sowas hätte eigentlich schon viel früher kommen sollen. Und wenn MS .NET nur auf ihre Plattformen beschränkt ist das sicherlich auch ihre Sache. Das heißt wir können darüber schlecht meckern, das müssen wir in Kauf nehmen. .NET ist eben kein Java. Davon abgesehen gibt es trotzdem Bemühungen C# auf andere Plattformen portieren zu können (siehe Mono). Aber man sollte Microsoft trotzdem hoch anrechnen, daß sie Compiler usw. frei zur Verfügung stellen, so daß andere Unternehmen überhaupt IDEs und ähnliches für .NET entwerfen können. Ist sicherlich auch zur Promotion gut Aber letztendlich gibts aber aus Entwicklersicht nicht so viel zu meckern. Man hat immer die Wahl zwischen einer Vielzahl an Programmiersprachen und Betriebssystemen, daran ändert sich nichts. Wenn dir .NET bzw. die MS Politik nicht zusagt brauchst du auch nichts von denen zu benutzen. Aber um Windows kommt man nur schwerlich herum. Und von daher ist MS mit .NET ein guter Coup gelungen...

Okay, du kannst auch folgendes schreiben: Dim result As Boolean ... result = myScript.Run("Test", 2005) Dann steht im result eben das Ergebnis der Bedingung, also ob Wahr oder Falsch. Beim Debug.Print schreibt er das Ergebnis ins Direktfenster der Makro-IDE. Wenn du für 2005 eine kleinere Zahl einsetzt wirst du sehen, das es funzt...