Visual Studio .NET - Dumme Melung beim kompelieren von WIN32-Anwendungen



  • Wer schonmal versucht hat unmanaged C++-Code mit Visual Studio .net zu kompelieren wird das Problem kennen. Immer wenn man versucht zu kompelieren, erscheint eine Meldung dass native WIN32-Anwendungen veraltet seien und ob man trotzdem kompelieren möchte. Weiss jemand ob man diesen Schwachsinn irgendwie deaktivieren kann? Vielleicht durch das Ändern eines Registry-Eintrages?



  • schrankwand schrieb:

    Wer schonmal versucht hat unmanaged C++-Code mit Visual Studio .net zu kompilieren wird das Problem kennen. Immer wenn man versucht zu kompilieren, erscheint eine Meldung dass native WIN32-Anwendungen veraltet seien und ob man trotzdem kompilieren möchte. Weiß jemand**,** ob man diesen Schwachsinn irgendwie deaktivieren kann? Vielleicht durch das Ändern eines Registry-Eintrages?

    Kann es sein, dass du das mit dieser Meldung verwechselst?

    ---------------------------
    Microsoft Development Environment
    ---------------------------
    Die folgenden Projektkonfigurationen sind veraltet:
    
        managedklops - Release Win32
    
    Möchten Sie sie erstellen?
    ---------------------------
    Ja   Nein   Abbrechen   Hilfe   
    ---------------------------
    

    Das erscheint wenn man auf "Ausführen" klickt, aber der Code nicht aktuell ist und somit vorher kompiliert werden müsste. Falls du das nicht meinst, so hab ich noch nie von der Meldung gehört 😉



  • Und genau diese Meldung meine ich. Also weiss jemand wie man die deaktivieren kann?



  • Hm... hab ich noch nix gesehen. unter "Projects & Solutions" kannst du nur einstellen, was gespeicehrt wird, und ob alles gebaut wird.

    Die Meldsung betrifft übrigens alle Projekte - und ich baues immer mit F7-F5 (VC6 keyboard layout)



  • 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 tragen

    Vielleicht 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älerei

    Finde 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.


Anmelden zum Antworten