Visual Studio .NET - Dumme Melung beim kompelieren von WIN32-Anwendungen
-
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.
-
Oh du alter Nekromant, der Thread is gut 6 Jahre alt.
