Application File nach Source Code

Mitdenken!!! Woher soll das Tool wissen, wie der Code mal ausgesehen 
hat?

Sollte VB2010 nicht .net sein? Da könnte schon noch was wieder zu holen 
sein wenn es nicht durch einen Obfuscator gelaufen ist: 
http://code-bude.net/2012/02/28/kostenlose-dotnet-decompiler-dienet-reflector-alternativen/

Ein kleiner Tipp für's nächste Mal: Das sinnvollste Backup, welches ich 
je implementiert habe, ist Teil eines jeden meiner Makefiles. Nach jedem 
(!) erfolgreichen Compilerlauf macht es ein einfaches Delta-Backup. 
Unter Unix genügen dafür find, cpio und bzip2 bzw. gzip. Die 
gepackten Daten gehen mit einem Zeitstempel in eine dediziertes 
Verzeichnis. Durch eine geeignete Verzeichnisstruktur und geeignete 
Filter lässt sich erreichen, dass nur manuell erstellte Dateien 
gesichert werden. Ein solches Backup ist kaum größer als ein paar 
Dutzend Kilobyte, benötigt nur Bruchteile von Sekunden und hat mir schon 
so manche Kopfschmerzen erspart, denn es passiert immer wieder, dass man 
mal etwas versehentlich löscht oder eine experimentelle Version wieder 
haben möchte, die es nicht bis ins Repository geschafft hat. Ab und an 
kann man auch ein Full-Backup manuell anstoßen. Lege das 
Backup-Verzeichnis auf eine separate Festplatte, einen USB-Stick oder 
eine SD-Karte und Du bist auch gegen Plattenausfälle gewappnet. Der 
heute in jedem Rechner vorhandene SD-Slot ist dafür bestens geeignet, 
darin kann die Karte auch bei einem Notebook ständig stecken, ohne dass 
sie stört. Kauf Dir zwei, drei oder vier Karten, die Du einmal die Woche 
wechselst und Du hast eine schon fast professionelles Backup Lösung. 
Wenn Du willst, kannst Du die Daten ab und zu auf CD archivieren, auch 
bei intensiver Programmierung ergibt das bei geschickter Filterung nur 
alle paar Wochen eine CD. Für dieses Mal nützt Dir das zwar nichts mehr, 
aber der nächste Datenverlust kommt bestimmt und dann gilt wie immer: 
Ein Backup ist kein Backup!

Man kann et auch übertreiben...

123 schrieb:
> Nein - du kannst einen Disassembler versuchen aber da kommt nichts
> gescheites dabei heraus.

Da Dieter schrieb:
> Mitdenken!!! Woher soll das Tool wissen, wie der Code mal ausgesehen
> hat?

Rolf Magnus schrieb:
> Genauso kann man aus
> einem fertigen Programm nicht wieder den Quellcode machen.

Alles falsch :-)
Oben wurde es ja schon einmal erwähnt: du kannst die .NET Assembly 
mühelos wieder in Quellcode zurückwandeln. Schau mal bei Google, da gibt 
es sicherlich massig Anleitungen zu dem Thema.
Ein paar Dinge gehen natürlich verloren (z.B. Quellcode-Kommentare), 
aber das wirst du wohl in Kauf nehmen müssen.

foobar schrieb:
> Dafür kann man viel besser ein VCS wie z.B. git oder mercurial benutzen.

Dass man das kann steht außer Zweifel, dass es auch sinnvoll ist 
keineswegs. Ein VCS ist kein Backup-Tool. Wenn Du nach jedem 
Compilerlauf ein Update ins VCS machst dürfte es bald zugemüllt sein mit 
Dingen die es weder wert sind, dort zu landen, noch von denen ich das 
möchte. Code der compiliert muss ja noch lange nicht fehlerfrei sein und 
ich möchte nicht jeden dummen Tippfehler im VCS wiederfinden. Ebenso 
wenig möchte ich bei jedem make einen Kommentar für das VCS schreiben. 
Ins VCS kommen bei mir nur Dinge, die getestet sind oder wenigstens eine 
halbwegs in sich geschlossene und beschreibbare Einheit bilden. 
Abgesehen davon muss ja auch das VCS irgendwie gesichert werden, bei 
Deiner vorgeschlagenen Nutzung entsprechend häufig. Dass das einfacher 
und effizienter zu machen ist als ein kleines Skript im Makefile wage 
ich mal zu bezweifeln.

A. H. schrieb:
> Wenn Du nach jedem
> Compilerlauf ein Update ins VCS machst dürfte es bald zugemüllt sein mit
> Dingen die es weder wert sind, dort zu landen, noch von denen ich das
> möchte.

Die goldene Regel des VCS lautet: Check in early, check in often.

A. H. schrieb:
> Ins VCS kommen bei mir nur Dinge, die getestet sind oder wenigstens eine
> halbwegs in sich geschlossene und beschreibbare Einheit bilden.

Dafür gibt's Tags.

.NET Reflector wäre der passende Suchbegriff bei Google. Dann kannst du 
den Quellcode aus dem Assembly auslesen.

Boris P. schrieb:
> Die goldene Regel des VCS lautet: Check in early, check in often.

Sure, but often doesn't mean always, and early doesn’t mean straight 
away.

Ein VCS ist ja auch so etwas wie ein Protokoll des Entwicklungsprozesses 
und ich glaube nicht dass man dem, der das einmal liest, einen Gefallen 
tut, wenn man jede Menge Versionen protokolliert, die vielleicht nur 
existieren, weil jemand mal ein Vorzeichen oder ein Semikolon falsch 
gesetzt hat. Etwas mehr Substanz sollte schon dahinter sein, sonst 
erzeugt man nur unnötiges Rauschen und das Repository liest sich eines 
Tages wie der Abspann eines Monty Python Films: „Dem Elch im Hintergrund 
von Szene 37 das Maul wischte...“