Technologie im Alltag?

[Pixie]

Hallo,

wie sieht das eigentlich bei Euch aus, welche .NET-Technologien setzt Ihr im beruflichen Alltag hauptsächlich ein? WindowsForms, WPF?

Macht es heutzutage noch Sinn, ein vollkommen neues Projekt mit WindowsForms umzusetzen?

[Guybrush Threepwood]

Java und Flex

Ich würde sagen ja auf jeden Fall. Das kommt aber auf das Projekt drauf an. Jedes 08/15 bei dem die Gui keine so große Rolle spielt bzw. keine großartigen spielereien machen muss würde ich mit Windows Forms machen weil es imho schneller geht.

Das könnte allerdings auch einfach nur daran liegen das ich mit WPF noch nicht all zu viel gemacht habe, vielleicht ändert der Eindruck sich ja auch sobald Visual Studio dafür einen vernünftigen Designer mitbringt und man nicht unbedingt Expression Blend haben muss oder das ganze per Hand coden will.

[trollr]

2008/2010 hat doch einen halbwegs ordentlichen Designer.

[Guybrush Threepwood]

Also ich hab das so in Erinnerung das der für WPF nicht so dolle war lasse mich da aber gerne eines besseren belehren

[mepp]

Hauptsächlich Windows Forms sogar in meinem Fall. WPF gibts bei uns noch überhaupt nicht.

[.NETter]

Ich würde sagen dass man seine Entwicklungstechnik nach den Anforderungen aussuchen sollte und keine Technik von vornherein abschreibt. WinForms ist OK wenn man mal schnell eine GUI braucht, für größere Dinge die auch in 5 Jahren noch laufen und erweiterbar sein müssen würde ich eher die WPF nutzen. WinForms wird ja nun nicht mehr von Microsoft weiterentwickelt.

Ich arbeite gerade an einem Silverlight-Projekt, obwohl ich beim ersten Blick nicht begeistert war, möchte ich es jetzt nicht mehr missen.

[Pixie]

Ich kenne WinForms seit VisualStudio 2003. Wenn ich irgendetwas brauche, weiß ich, wo ich es finde und ich kann mich auf die wesentlichen Dinge konzentrieren. Bei WPF fehlt mir derzeit noch die Erfahrung und Praxis. Nun habe ich mich eine Weile mit ASP beschäftigt und was mir nach der ersten Einarbeitungszeit sehr gut gefallen hat, ist das DataBinding, das alle Controls mitbringen. Gefällt. Das hat nmW in Winforms nur das Datagridview. Insofern vielleicht bei datenlastigen Anwendungen auf jeden Fall WPF? Andererseits fehlen in WPF auch schlicht einige aus WinForms liebgewonnene Controls, das PropertyGrid zum Beispiel. Okay, könnte man selbst bauen, wenn man gerade zuviel Zeit hat. Könnte man sicherlich auch kaufen. Aber eigentlich wärs schön gewesen, man hätte alles zur Verfügung gehabt, was aus WinForms bekannt ist.

[Guybrush Threepwood]

Oder mal auf CodePlex - Open Source Project Hosting schauen da finden sich zahlreiche nützliche Bibliotheken

[SilentDemise]

ehrlich gesagt WPF als Technologie ist ne echte Einbahnstraße. Von daher ist es egal, ob man Windows Forms oder WPF macht. In Zukunft sind GUIs auf Windows Rechnern wohl ein XAML / HTML5 / Javascript Brei.

Ich nutze auch weiterhin Windows Forms, ich baue aber auch keine anspruchsvollen Oberflächen.

[Guybrush Threepwood]

Ich glaube du hast da etwas falsch verstanden. Windows 8 heißt nicht das da plötzlich alle Anwendungen eine HTML Oberfläche haben müssen.

Das ist afaik nur bei Metro Apps der Fall. Also all den Applikationen die auf dem neuen Metro Dashboard(?) angezeigt werden bzw. darauf arbeiten, was vermute ich mal Touch Bedinung verbessern soll.

Standard Anwendungen (die man dann über den normalen Desktop) bedient werden auch weiterhin so laufen bzw. programmiert werden wie bisher. Alles andere würde ja auch nicht wirklich Sinn machen und wäre ein riesen großer Rückschritt in der Softwareentwicklung.

[SilentDemise]

WPF taucht als Technologie nicht mehr auf den Microsoft Roadmaps auf. XAML bleibt als Technologie erhalten, WPF wird über kurz oder lang aussterben. Es wird wie immer bei Microsoft sein, sie werden die Technologie noch die nächsten 500 Jahre mitschleifen. Aber die Strategie geht in eine andere Richtung.

[Guybrush Threepwood]

Alles was ich bisher dazu gelesen habe deutet auf etwas anders hin, eine offizielle Aussage von MS habe ich dazu allerdings nocht nicht gesehen.

XAML ist ein Teil von WPF und es macht wenig Sinn nur diesen beizubehalten und den ganzen Rest der super funktioniert und wo viel Arbeit reingesteckt wurde wegzuschmeißen um einfach mal so was anderes einzuführen

[.NETter]

Ich kenne WinForms seit VisualStudio 2003. Wenn ich irgendetwas brauche, weiß ich, wo ich es finde und ich kann mich auf die wesentlichen Dinge konzentrieren. Bei WPF fehlt mir derzeit noch die Erfahrung und Praxis. Nun habe ich mich eine Weile mit ASP beschäftigt und was mir nach der ersten Einarbeitungszeit sehr gut gefallen hat, ist das DataBinding, das alle Controls mitbringen. Gefällt. Das hat nmW in Winforms nur das Datagridview. Insofern vielleicht bei datenlastigen Anwendungen auf jeden Fall WPF? Andererseits fehlen in WPF auch schlicht einige aus WinForms liebgewonnene Controls, das PropertyGrid zum Beispiel. Okay, könnte man selbst bauen, wenn man gerade zuviel Zeit hat. Könnte man sicherlich auch kaufen. Aber eigentlich wärs schön gewesen, man hätte alles zur Verfügung gehabt, was aus WinForms bekannt ist.

Alle WindwwsFroms-Controls kannst du auch in der WPF über einen WindowsFormsHost nutzen. Ich mach das z.B. für das ReportViewer-Control. Das gibt es in der WPF auch nicht. In der WPF ist alles auf Bindung ausgelegt... Mal nach MVVM googeln...

[Pixie]

Alle WindwwsFroms-Controls kannst du auch in der WPF über einen WindowsFormsHost nutzen.

Jaaaa, schooooon... aber: Dann kann ich ja gleich WinForms nehmen

Ich hatte auch einmal den umgekehrten Fal ausprobiert - WPF ist bei den Möglichkeiten der Darstellung etwas flexibler und ich hatte eine WPF-Lösung für ein privates Projekt gefunden, wo mich eine Sache schon länger gestört hatte. Alles neu mit WPF bauen, wollte ich natürlich auch nicht und habe das WPF-control über einen WPFHost eingebunden...klappte auch wunderbar... hatte nur leider immer an anderer Stelle einen Darstelungsfehler. Aber irgendwas ist ja immer :eek

[biu]

Wir setzen hauptsächlich noch Windows Forms ein, eben weil wir uns dort auskennen. Ist aber ein nerviges Thema zum Glück gibt es da andere Firmen die sich huaptsächlich damit beschäftigen (Infragistics und Co) :-)

Allerdings gucken wir uns seit einer Weile schon WPF genauer an, doch gibt es da noch einige Dinge die uns stören.

Zum Beispiel der Unterschied zwischen Prism und CAB

In Zukunft werden wir auch umsteigen, aber wann können wir nicht genau sagen.

[a3quit4s]

XAML ist ein Teil von WPF

XAML ist meiner Meinung nach einfach nur eine Deklarationssprache fuer GUI Elemente, dass WPF oben draufsitzt spielt eine eher untergeordnete Rolle.

[HJST1979]

Hallo

da ich .NET- Programmierung leider nur im privaten Bereich mache (also nicht auf Arbeit) habe ich lange Zeit auf WinForms gesetzt auch aus Unwissen heraus. Nun habe ich mich ein bisserl damit beschäftigt und das Konzept m.E. verstanden.

Ich persönlich würde zum jetzigen Zeitpunkt nichts mehr mit WinForms machen sondern sofort auf WPF gehen.

P.S. Ich habe kein Expression Blend sondern nutze ausschließlich die Expressversioenn von Microsoft

Gruß Hans-Jörg

[Guybrush Threepwood]

Ich hab gestern nochmal kurz nen Blick in VS 2010 Express geworfen und der WPF Designer klappt ja wirklich vernünftig.

Hatte das irgendwie falsch in Erinnerung, evtl noch von der ersten Version wo man im Visual Studio Designer gar nichts machen konnte, kann aber auch bei Silverlight gewesen sein:old

[spix]

WPF taucht als Technologie nicht mehr auf den Microsoft Roadmaps auf.

Genau anders rum - WinForms steht nicht mehr auf der Roadmap.

btw:

Bis vor kurzem arbeitete ich mit C++ ua mit WinForms. Bin grad am switchen zu C# und WPF.

[SilentDemise]

WinForms ist schon ewig runter. Neu ist, das auch WPF seit der Build Conference nicht mehr zu finden ist.

[Thelvan]

WinForms für Sachen die auf den Servern laufen und Daten hin und her schaufeln, exportieren, importieren etc. und größtenteils automatisch laufen.

WPF für Sachen, wo viele Benutzer mitarbeiten, für spezielle Programme wenn erforderlich auch Silverlight

[Sacaldur]

das Binden von Komponenten(-propertys) an andere Propertys ist nicht die einzige mögliche Verwendungsart

man kann ebenfalls an einen Container eine Liste von Objekten bilden, aus denen mit Hilfe eines Templates Komponenten generiert werden, sobald neue Objekte der Liste hinzugefügt werden

man kann das Aussehen eines jeden Elements nach eigenen Belieben definieren

dazu gehört nicht nur das typische Beispiel eines runden Buttons, sondern auch beispielsweise ein Umfärben oder Verkleinern beim Anklicken

Animationen sind sehr einfach zu integrieren

auf Arbeit habe ich bisher nur 2x WPF eingesetzt (für den Microsoft Surface) und ansonsten kein Windows Forms (meist eher Java + Swing)

in meiner Freizeit habe ich eher mit Windows Forms zu tun, da ich mich an einem Projekt beteilige, bei dem ein Programm bereits mit Windows Forms implementiert wurde

Edit:

WinForms für Sachen die auf den Servern laufen und Daten hin und her schaufeln, exportieren, importieren etc. und größtenteils automatisch laufen.

wofür benötigt man auf einem Server eine grafische Oberfläche (wenn etwas automatisiert ablaufen soll)?

aber vielleicht denke ich so, da ich eher mit UNIX(/Solaris)-Servern zu tun habe...

für Windows 8 wurde WPF mit C++ implementiert, also denke ich nicht, dass es fallen gelassen wird

nicht nur "klassische" Desktopanwendungen, sondern auch Metro-Anwendungen können mit WPF entwickelt werden (HTML, CSS und Javascript sind nicht die einzige Möglichkeit)

Bearbeitet 20. Januar 2012 von Sacaldur

[SeToY]

für Windows 8 wurde WPF mit C++ implementiert

Darunter kann ich mir nichts vorstellen - wie meinst du das?

Hast du da evtl. einen Artikel zu?

sondern auch Metro-Anwendungen können mit WPF entwickelt werden (HTML, CSS und Javascript sind nicht die einzige Möglichkeit)

Dazu evtl. auch einen Artikel vorhanden?

Zum Thema "WPF droppen":

The future of WPF, Silverlight, and HTML5 - Are they dead?

[Sacaldur]

damit ich nicht zu lange mit einer Rückmeldung auf mich warten lasse:

beim 2. Punkt habe ich wohl WPF und XAML durcheinander gebracht

ein Artikel auf Heise Developer befasst sich sehr ausführlich mit den Änderungen im .NET-Framework

zu dem ersten Punkt:

auch da kann es sein, dass ich WPF selbst mit dem "XAML-Interpreter" verwechselt habe, allerdings bin ich mir da nicht sicher (und um ehrlich zu sein war ich das auch beim schreiben des 1. Beitrags nicht wirklich... =/ )

ich bin mir sicher, davon auf Heise gelesen zu haben

sollte ich den Artikel wiederfinden, werde ich ihn hier posten