Visual Studio .NET - Dumme Melung beim kompelieren von WIN32-Anwendungen
-
schrankwand schrieb:
Weiss jemand ob man diesen Schwachsinn irgendwie deaktivieren kann?
Nicht alles, dessen Sinn du nicht begreifst, ist deswegen gleich Schwachsinn.
-
Man muß aber mal sagen - die VC7 IDE ist auch nach längerem Hinsehen Schwachsinn.
-
peterchen schrieb:
Man muß aber mal sagen - die VC7 IDE ist auch nach längerem Hinsehen Schwachsinn.
Visual Studio .NET 2003 ist die beste IDE, die ich kennne. Nach meiner Erfahrung kommen Klagen eigentlich hauptsächlich von denen, die versuchen, die IDE auf ihre gewohnte Arbeitsweise mit VS6 umzubiegen.
-
VC7 ist ne schöne generische, anpaßbare IDE.
Das Problem ist aber:
- im Gegensatz zu VC6 (
) ist es out of the box 'ne Quälerei
- Anpassungen lassen sich nur mit Mühe von einem Rechner auf einen anderen tragenVielleicht werd' ich einfach nur älter, aber selbst nach einem mittleren Projekt ist VS7 einfach schwerfällig.
Ich hab kein Problem, ein paar Keyboard-Shortcuts umzulernen (ich wechsle seit Jahren zwischen deutschen und Englischen IDE's). Aber an zu vielen Stellen sind die Shortcuts nicht mehr offensichtlich, und/oder man muß zur Maus greifen. Zwei Clicks statt einem. Platzbedarf ist enorm gestiegen, Features sind weggefallen (z.B. separate Konfig während Debug)die versuchen, die IDE auf ihre gewohnte Arbeitsweise mit VS6 umzubiegen
vielleicht war VC6 einfach bessere für den Job?
-
peterchen schrieb:
- im Gegensatz zu VC6 (
) ist es out of the box 'ne QuälereiFinde ich überhaupt nicht. Sicher, dass du nicht nur Umgewöhnungsschwierigkeiten hast?
- Anpassungen lassen sich nur mit Mühe von einem Rechner auf einen anderen tragen
Welche Anpassungen?
Vielleicht werd' ich einfach nur älter, aber selbst nach einem mittleren Projekt ist VS7 einfach schwerfällig.
Kann ich nicht bestätigen.
Aber an zu vielen Stellen sind die Shortcuts nicht mehr offensichtlich, und/oder man muß zur Maus greifen.
Was sind "offensichtliche" Shortcuts? Und es geht auch immer noch alle ohne Maus.
Platzbedarf ist enorm gestiegen,
Das kann ich allerdings bestätigen.
Features sind weggefallen (z.B. separate Konfig während Debug)
Was meinst du mit "separater Konfig"?
vielleicht war VC6 einfach bessere für den Job?
Ich vermute eher, du hast massive Umgewöhnungsschwierigkeiten.
-
EDIT: Huch
-
@Peterchen: Schön, dass ich nicht alleine zu "unflexibel" für VC2003 bin.
Ich bleibe bei der Autorenversion vom 6er (zum Arbeiten) und nehme das andere ausschließlich zum Kompilieren der Release.
-
Welche Anpassungen?
Makros, Toolbar/Pane-Layout, Editor-Einstellungen, zusätzliche Shortcuts usw.
Was sind "offensichtliche" Shortcuts?
z.B. Hilfe-System:
VC6: ALT-N / ALT-S / ALT-C (so wie's auf den Tabs draufsteht)
VC7: jeweils Ctrl-Alt-Shift-irgendwas,Was meinst du mit "separater Konfig"?
Toolbar-Layout etc. währedn Debug-Session wird separat gespeichert und für neue Debug-Session wiederhergestellt.
Ich arbeite sehr tastaturlastig, deswegen hab' ich mich extra gezwungen, ein Projekt unter VC7 zu erstellen. Trotzdem reicht's noch nicht. Es gibt nur wenige Ecken, an denen ich wirklich "aufschreie". In meinen Augen ist eine gute UI eine, die man nicht bemerkt, und in den meisten Fällen bin ich halt damit beschäftigt, die Oberfläche zu Bedienen, statt meinen Scheiß zu machen.
Das geht sicherlich weg, wenn ich nur noch mit VC7 arbeite - aber dazu habe ich im Moment keine Gelegenheit, und das erschwert es schon.[edit]Und ich seh schon meinen Kollegen dreimal am Tag anrufen "was hab' ich denn jetzt gemacht?"[/edit]
-
Also für .net-Anwendungen ist Visual Studio .net eigentlich ziemlich genial. Für native WIN32-Anwendungen ist Visual Studio .net hingegen so ziemlich die größte scheisse die es gibt, aber das war ja schließlich auch genau so von Microsoft beabsichtet.
MFK schrieb:
schrankwand schrieb:
Weiss jemand ob man diesen Schwachsinn irgendwie deaktivieren kann?
Nicht alles, dessen Sinn du nicht begreifst, ist deswegen gleich Schwachsinn.
Du bist also genau wie Microsoft der Ansicht das unmanaged C++ veraltet ist?
-
schrankwand schrieb:
Für native WIN32-Anwendungen ist Visual Studio .net hingegen so ziemlich die größte scheisse die es gibt, aber das war ja schließlich auch genau so von Microsoft beabsichtet.
Deswegen haben sie schließlich auch den native-Compiler so stark verbessert, stimmts?
schrankwand schrieb:
Du bist also genau wie Microsoft der Ansicht das unmanaged C++ veraltet ist?
Nein. Ich bezweifle auch, dass Microsoft dieser Ansicht ist. Ich benutze VS.NET praktisch ausschließlich für unmanaged C++. Und ich bekomme regelmäßig Zustände, wenn ich zu VS6 zurück muss. Breakpoints in nachgeladenen DLLs?
Das Feature, das du als Schwachsinn bezeichnest, hat seinen Sinn. Gelegentlich will ich ein Programm ausführen, ohne dass wegen verändertem Code neu gebaut wird. Das Feature hat auch nichts mit dem Thema VS6/VS.NET zu tun, weil es in beiden existiert.
-
@peterchen: Ich bin deiner Meinung auch ich nutze VC7 nur um libs für diesen Compiler zu erstellen, ansonsten arbeite ich mit VC6 (zumal ich eh hauptsächlich mit der mfc42.dll kompilieren muss). Ich hab mir unter der 6er ein paar Makros auf bestimmte Tasten gelegt und musste feststellen, das einige jetzt gar nicht mehr angeboten werden. Z.B. auf Rollen (braucht keiner) hatte ich eins, dass mir eine Trennlinie einfüge. Ok, das sind Kleinigkeiten, aber igendwie ist die IDE gegenüber der VC6 träger und man sucht länger, bis man was gefunden hat.
Natürlich gibt es auch ein paar Nettigkeiten (Klammern hervorheben, andockbarer Suchendlg) aber das erste große Projekt mit VC7 (dann wohl VC8) wird eine echte Umgewöhnung.
-
MFK schrieb:
Deswegen haben sie schließlich auch den native-Compiler so stark verbessert, stimmts?
Interessant, hast du vielleicht einen Link dazu? Ich les nähmlich eigentlich immer nur das Microsoft mit .net, unmanaged Code ablösen will.
MFK schrieb:
schrankwand schrieb:
Du bist also genau wie Microsoft der Ansicht das unmanaged C++ veraltet ist?
Nein. Ich bezweifle auch, dass Microsoft dieser Ansicht ist. Ich benutze VS.NET praktisch ausschließlich für unmanaged C++.
...
Das Feature, das du als Schwachsinn bezeichnest, hat seinen Sinn. Gelegentlich will ich ein Programm ausführen, ohne dass wegen verändertem Code neu gebaut wird.
Dann les dir bitte mal genau die Meldung durch? Da wird nicht gefragt ob man nur neu starten will oder ob das Projekt vorher erst neu kompeliert werden soll, sondern da wird mehr oder weniger davon abgeraten zu kompelieren, da diese Konfiguration veraltet sei. Und diese Meldung kommt ausschliesslich bei nativen Anwendungen!
-
drück erst auf kompilieren und dann auf ausführen. dann kommt die meldung nicht.
-
schrankwand schrieb:
Da wird nicht gefragt ob man nur neu starten will oder ob das Projekt vorher erst neu kompeliert werden soll, sondern da wird mehr oder weniger davon abgeraten zu kompelieren, da diese Konfiguration veraltet sei.
Poste doch bitte mal den genauen Wortlaut dieser Meldung. Vielleicht reden wir ja aneinander vorbei.
-
masterofx32, hat die Meldung mal am Anfang des Threads gepostet.
masterofx32 schrieb:
--------------------------- Microsoft Development Environment --------------------------- Die folgenden Projektkonfigurationen sind veraltet: managedklops - Release Win32 Möchten Sie sie erstellen? --------------------------- Ja Nein Abbrechen Hilfe ---------------------------
-
Diese Meldung bedeutet einfach nur, dass mindestens ein der Quellcodedateien ein neueres Änderungsdatum hat als die zu erstellenden Datei. Sprich: Du hast den Quellcode geändert.
Wenn du jetzt ausführen willst, muss die IDE wissen, ob du mit der (veralteten) Exe arbeiten, oder die Exe aus dem geänderten Quellcode neu erstellen willst, und dann die neue Exe starten.Und genau das fragt sie dich, wie auch schon in VC6, und vermutlich auch in den Versionen davor.
Wie du da herausliest, dass einem vom Kompilieren abgeraten wird, ist mir völlig schleierhaft. Dass diese Meldung bei .NET-Anwendungen nicht erscheint, liegt daran, dass VS.NET dabei offenbar ungefragt neu erstellt.
-
MFK schrieb:
Wenn du jetzt ausführen willst, muss die IDE wissen, ob du mit der (veralteten) Exe arbeiten, oder die Exe aus dem geänderten Quellcode neu erstellen willst, und dann die neue Exe starten.
...
Wie du da herausliest, dass einem vom Kompilieren abgeraten wird, ist mir völlig schleierhaft.
Achso, dann hab ich das "veraltet" vollkommen falsch interpretiert, bitte um Entschuldigung.
MFK schrieb:
Dass diese Meldung bei .NET-Anwendungen nicht erscheint, liegt daran, dass VS.NET dabei offenbar ungefragt neu erstellt.
Das ist mir klar und so finde ich es auch wesentlich praktischer.
Nichts desto trotz stört mich dieses Feature und mich würde freuen wenn mir jemand sagen könnte wie man es deaktivieren kann. Danke.
-
es regt mich richtig auf wie hier in dem post um den heissen brei herumgeredet wird. die frage war klar gestellt und es würde mich echt freuen wenn sie dem entsprechend beantwortet werden könnte. Die meldung nervt nämlich in der tat das kann ich bestätigen (und google auch). Dass das feature nicht sinnlos ist is uns ja allen klar, aber features sind halt erweiterungen die man NICHT IMMER braucht. In .NET gehts ja auch in einem schritt, warum also nicht für w32 anwendungen?
-
stoefln schrieb:
es regt mich richtig auf wie hier in dem post um den heissen brei herumgeredet wird. die frage war klar gestellt und es würde mich echt freuen wenn sie dem entsprechend beantwortet werden könnte. Die meldung nervt nämlich in der tat das kann ich bestätigen (und google auch). Dass das feature nicht sinnlos ist is uns ja allen klar, aber features sind halt erweiterungen die man NICHT IMMER braucht. In .NET gehts ja auch in einem schritt, warum also nicht für w32 anwendungen?
Zuerst einmal geht es ja nicht darum das Win32 "veraltet" ist, sondern dass sich Dein Projekt geändert hat und somit die EXE älter als Dein Source ist.
Mir ist aber keine Einstellung bekannt, wo man dies deaktivieren kann...Aber es stimmt schon, es nervt... ich drücke immer vorher Ctrl-Shift-B, dann kommt diese Meldung nie
-
Hatte die Meldung auch ständig bekommen. Egal ob ich unmittelbar davor nochmal kompiliert hatte. Wenn ich die Meldung bestätigte, wurde immer die gleiche Datei neu kompiliert bevor die Anwendung startete.
Daraufhin habe ich mir das Datum der letzten Änderung an der Datei angeschaut. Das Datum lag in der Zukunft.
Durch Zeittests hatte ich vorher das Datum in die Zukunft gesetzt und vor dem Zurückdrehen die Datei editiert.
Als ich nun die Datei nochmal mit aktuellem Datum editiert hab, kam die Meldung nicht mehr.