BUG? im Quellcode werden auf einmal Befehle verstümmelt

[Patrick Sack]

Hi,
<br>
<br>(ASPX, C#)
<br>mitten in der Programmierung werden auf einmal willkürliche Einrückungen vorgenommen und ganz nebenbei bei Befehlen und Variablen ein paar Zeichen abgeschnitten und schon sitzt man im größten Code Chaos das man sich nur vorstellen kann.
<br>
<br>Wie kann ich dem .Net Studio absolut verbieten auch nur im geringsten irgendwas im Code zu ändern (eine Solche Opötion habe ich leider nicht gefunden). Auf den ganzen (...) mit automatisch Einrücken und so verzichte ich gerne wenn mein Code nur endlich mal so bleibt wie ich Ihn zuletzt zurückgelassen habe.
<br>
<br>Mehr infos:
<br>http://www.entwickler-forum.de\webx?11@@.ee8c6bc
<br>
<br>Danke für die Hilfe.
<br>
<br>mfg
<br>PS

[Andreas Kosch]

Hallo,

mit ASP.NET-Anwendungen habe ich bisher (mit Ausnahme der Web Services) weniger zu tun, daher kann ich keine eigenen Erfahrungen beisteuern. Ich würde zuerst untersuchen, ob dieser Effekt beim Editieren der Microsoft Beispielanwendungen <i>Duwamish 7.0 CS</i> oder <i>FMStocks7</i> (aus <i>C:\Programme\Microsoft Visual Studio .NET\Enterprise Samples</i>) ebenfalls auftritt

[Patrick Sack]

Vielen Dank.
<br>
<br>Werde ich mal testen, aber gibt es nicht doch irgend wo eine Option, damit so wenig wie nur möglich, durch .Net, an dem Code geändert wird? (Klar, die Objekte muß er ja auch im Code eintragen, aber das soll es dann auch bitte schon an Änderungen gewesen sein.)
<br>
<br>mfg
<br>P

[Patrick Sack]

Vielen Dank.
<br>
<br>Werde ich mal testen, aber gibt es nicht doch irgend wo eine Option, damit so wenig wie nur möglich, durch .Net, an dem Code geändert wird? (Klar, die Objekte muß er ja auch im Code eintragen, aber das soll es dann auch bitte schon an Änderungen gewesen sein.)
<br>
<br>>im Gegensatz zu Delphi (und dem alten VB) gibt es keine separate <br>>Formular-Datei (.DFM) für die Konfiguration der Komponenten und <br>>Controls, die IDE verwaltet in einer Windows Form-Anwendung alles in
<br>>der gleichen Sourcecode-Datei. Daher sieht MS speziell <br>>gekennzeichnete Regionen vor (siehe automatisch eingefügte <br>>Kommentare im Sourcecode), von denen man die Finger lassen sollte.
<br>>Immer dann, wenn man in diesem Teil eigene Erweiterungen/Anpassen
<br>>vornehmen darf, ist eine entsprechende Kommentarzeile zu finden. <br>>Hält man sich nicht an diese Regel, kann es durchaus passieren, dass
<br>>die automatische Synchronisation (Source <--> IDE) ausser Tritt <br>>gerät. Alles das, was Visual Studio .NET visuell anzeigt (Formular,
<br>>Component Tray, Properties Window usw.) muss vorher aus dem <br>>Sourcecode ausgelesen und entsprechend umgesetzt werden können.
<br>>
<br>>Ich würde an Deiner Stelle zuerst prüfen, ob dieser Effekt beim <br>>Editieren der umfangreichen MS-Beispielanwendungen ebenfalls <br>>auftritt:
<br>>- Duwamish 7.0 CS (ASP.NET)
<br>>- FMStocks7 (ASP.NET)
<br>>- Donkey.NET (Windows Form 3D-Spiel)
<br>
<br>Ob jemand schon vor mir in dem Projekt Daten in den besagten Bereichen geändert hat weiß ich nicht. Ich habe auf jeden fall schon Objekt Definitionen von Hand gelöcht, da diese im Code standen, die Objekte jedoch im Entwurf nicht unter diesem Namen erschienen. Das trat oft dann auf, wenn ich Komponenten umbenannt habe.
<br>
<br>>dass die automatische Synchronisation (Source <--> IDE) ausser Tritt gerät.
<br>
<br>Kann es vieleicht sein, das hier bei edr Synchronisation Timing Probleme auftreten können?
<br>
<br>Ich bin von Delphi gewohnt schnell ein paar Tasten (Strg+s (speichern) und Strg+F9 (Kompilieren)) zu drücken, um dann zu warten bis ich die Applikation starten kann. Ähnlich arbeite ich auch mit .Net d.h. Strg+Shift+s (speichern) und dann schnell auf neuesrtellen klicken, um bloß keine Zeit zu verlieren. Dabei ist mir schon mal aufgefallen, das .Net anscheinend mit dem Neusretellen beginnt, noch bevor alle Dateien gespeichert sind.
<br>
<br>Danke für die Info.
<br>
<br>mfg
<br>P

[Andreas Kosch]

Hallo Patrick,

&gt;...Timing Probleme auftreten können?

ob diese Vermutung zutrifft, könnten praktische Versuche zeigen. MS wird innerhalb von VS.NET intensiv auf Threads zugreifen, wenn hier die Synchronisation nicht korrekt ist, hast Du einen weiteren Bug gefunden :-)

&gt;..Ob jemand schon vor mir in dem Projekt Daten ... geändert hat ...

Wenn das Problem nur in diesem einem Projekt auftritt (aber nicht in neu angelegten Projekten), scheint irgend etwas nicht mehr in der von VS.NET erwarteten Struktur vorzuliegen

[Patrick Sack]

Hallo Andreas,
<br>
<br>(Angaben ohne Gewähr)
<br>es hat den anschein, das es mit Timing Problemen zusammen hängt.
Wenn man grundsätzlich vor jedem Wechsel der Seite in die Codeansicht, oder umgekehrt, oder bei dem Wechsel auf eine andere Seite speichert und den speicher Prozeß in aller Ruhe abwartet, so treten die Fehler nicht mehr auf (bis jetzt zumindest nicht mehr).
<br>
<br>Resümee:
<br>Ganz langsam arbeiten und es scheint zu funktionieren.
<br>
<br>mfg
<br>P

[Patrick Sack]

Hallo,
<br>
<br>die traurige Geschichte geht weiter:
<br>
<br>Diesmal habe ich VS.Net geöffnet und in der Startmaske das zuletzt geöffnete Projekt angeklickt zum öffnen.
<br>
<br>Nun wärend des Öffnens habe ich ein wenig im Windows Dateiexplorer herumgestöbert (nur in ein paar Verzeichnisse geschaut). Danach wieder zurück zu VS.Net und ... was soll ich sagen es hagelte Buildfehler und im Bereich "#region Web Form Designer generated code" waren wieder deklarationen zerstört.
<br>
<br>Aber jetzt kommts erst:
<br>Bisher habe ich ja lediglich Projekt öffnen gesagt, aber die besagte Code Datei war mit einem Sternchen versehen. Das heißt VS.Net öffnet nicht nur einfach eine Datei, sondern führt auch gleich irgendwelche nicht authorisierte Schreiboperationen aus.
<br><b>Sehr fatal.</b>
<br>Aber es geht ja noch weiter:
Erst jetzt bin ich nach "#region Web Form Designer generated code" gegangen und habe eben feststellen müssen, das Deklarationen zerstört wurden. Wenn überhaupt, dann hätte erst jetzt die Datei ein Sternchen für "editiert" bekommen dürfen, da ich die Region aufgekpappt habe.
<br>Und nun kommts:
<br>Um alles nicht schlimmer zu machen drücke ich schnell das große X von VS.Net. Die obligatorische Frage ob ich die "Änderungen" abspeichern möchte beantworte ich mit "Nein", denn ich möchte gar keine Änderungen abspeichern.
<br>Nachdem VS.Net geschlossen wurde öffne ich es erneut und und muß mit Schrecken festellen, daß die Code-Datei an der selben Position wieder geöffnet wird, an der ich sie zuvor mittels "nicht speichern" verlassen habe.
<br>VS.Net speichert somit doch noch irgendwo (in der SLN Datei) irgendwas obwohl man explizit "nicht speichern" ausgewählt hat.
<br>
<br>Vieleicht ein wenig pedantisch von mir sich darüber aufzuregen, aber ich möchte nicht wissen was sonst noch alles ohne mein Wissen gegen meinen "freien" Willen ausgeführt wird.
<br>
<br>In diesem Sinne
<br>mfg
<br>PS
<br>
<br>P.S.: Resultat: Ich kam leider nicht um hin ein Bakup einzuspielen. Zum Glück sichere ich (notgedrungen) .NET Projekt nach jeder Änderung

[Andreas Kosch]

Hallo Patrick,

&gt;..das Deklarationen zerstört wurden...

ist das Patch Q324199 <i>VS70_QFEM_Q324199_EnCsCtDeFrItJaKoSp.exe</i> schon eingespielt (siehe <i>Help | About Microsoft Development Environment</i>)

[Patrick Sack]

Hallo Andreas,
<br>
<br>vielen Dank für den Tipp.
Ich werde das mal testen und wenn es funktioniert/nicht funktioniert noch mal melden. Da dieser Fehle immer sporadisch auftreten wird es wohl was dauern ehe ich Entwarnung geben kann.
<br>
<br>mfg
<br>P