wie gehts mit .net weiter?
-
chrische5 schrieb:
Gibts die Beta frei verfügbar als iso? Habt ihr schon Erfahrungen damit?
Beides ja.
-
Hallo
Lass mich oder uns doch mal an deinen Erfahrungen teilhaben.
chrische
-
Wenn man ein fettes Projekt buildet, reagiert die IDE immer noch schlecht währenddessen und danach für 20sec gar nicht mehr. Ich sehe auch sonst nichts, was sich gebessert haben könnte.
-
Optimizer schrieb:
Wenn man ein fettes Projekt buildet, reagiert die IDE immer noch schlecht währenddessen und danach für 20sec gar nicht mehr.
Wie meinst Du das? Strg+Break unterbricht den Build-Vorgang auf Wunsch jederzeit. Überhaupt kein Problem. Die IDE reagiert also nicht schlechter als normale Compiler auch. Kompilieren dauert eben so seine Zeit.
-
chrische5 schrieb:
Lass mich oder uns doch mal an deinen Erfahrungen teilhaben.
Mir ging es beim testen darum zu erfahren wie gut WPF integriert ist. Noch bin ich nicht zufrieden, denn in den Eigenschaften gibt es noch keinen Zugriff auf Events. Apropos, sind die vielleicht nun woanders, weiss das jemand?
-
titan86 schrieb:
ich persönlich denke, dass Wpf ein Programm nicht wirklich besser macht(im Sinne von Funktionalität)
Das ist ein sehr guter Gedanke. Viele Leute verwenden Technologien nur weil sie grad "in" sind und einen cool vorkommen. Dabei ists eigentlich wie beim handwerken, nur mit den richtigen Werkzeugen kommt man effektiv an sein Ziel.
WPF ist an sich was richtig tolles, aber primär nur wenn man eh vorhat eine komplexe GUI zu schreiben. Will man was einfaches kommt man ohne WPF genauso gut zum Ziel.
Wobei ich mittlerweile selbst einfache GUIs mit WPF schreiben würde, alleine wegen dem Databinding, Styles und XAML welche es einfach leicht machen selbst komplexeste GUIs schnell zu schreiben.
Und die .Net Runtimes sind abwärtskompatibel. Wenn man z.B. nur die 2er drauf hat, laufen da auch 1.1er Programme wenn der Entwickler nicht gerade ein Manifest zulegt was die Ausführung unter 1.1 erzwingt. Genauso gilt das für kommende Versionen. 3.0 ist technisch nur nen 2.0 mit zusätzlichen Klassenbibliotheken und 3.5 sind dann wieder neue Bibliotheken, ob sich was an der Runtime ändert weiß ich nicht, glaub ich aber weniger da es ja auch für 2.0 die Linq Preview z.b. gibt.
-
Zwergli schrieb:
Und die .Net Runtimes sind abwärtskompatibel. Wenn man z.B. nur die 2er drauf hat, laufen da auch 1.1er Programme wenn der Entwickler nicht gerade ein Manifest zulegt was die Ausführung unter 1.1 erzwingt.
Da wär ich mir nicht ganz so sicher. Mir fällt da grad ein Wert im Bereich Remoting ein, der unter 1.1 default auf false steht, unter 2.0 auf true. Remtoing-Code der daher unter 1.1 einwandtfrei geht läuft erstmal unter 2.0 deswegen nicht.
Ich weis jetzt ehrlich gesagt nicht ob das Einfluß auf fertig kompilierte Programme hat, aber spätestens wenn man den Sourcecode dann unter 2.0 kompilieren will muß man ihn erstmal umschreiben.
Ähnliches Beispiel, wenn auch nicht direkt Framework bedingt sind z.B. Dienst-Setups die unter XP einwandfrei installieren, unter Vista aber mit einer kryptischen Fehlermeldung abbrechen. Auch hier wurde ein Defaultwert, der unter XP immer false ist für Vista auf true gesetzt... (Ok, die tatsächliche Änderung unter Vista ist weitreichender von wegen UAC und so)
Für mich als Entwickler bedeutet das, das Code der unter der aktuellen Framework Version läuft unter einer neuen Version u.U. überarbeitet, oder im schlimmsten Fall komplett neu geschrieben werden muß. Und unter dem Aspekt das ich meinen Sourcecode ja auch weiter verwenden möchte kann man schon behaupten das die Framework Versionen nicht wirklich kompatibel sind.
-
Hallo
Man kann doch einfach beide Installtionen 1.1 und 2.0 parallel drauf haben.
chrische
-
Konrad Rudolph schrieb:
Optimizer schrieb:
Wenn man ein fettes Projekt buildet, reagiert die IDE immer noch schlecht währenddessen und danach für 20sec gar nicht mehr.
Wie meinst Du das? Strg+Break unterbricht den Build-Vorgang auf Wunsch jederzeit. Überhaupt kein Problem. Die IDE reagiert also nicht schlechter als normale Compiler auch. Kompilieren dauert eben so seine Zeit.
Vielleicht hast du es noch nicht versucht, benutze mal irgendwelchen IDE-Features (außer den Build abzubrechen) währenddessen. Zum Beispiel klick den ersten Compilerfehler an und versuch ihn zu richten. Du tippst, nach 2 Sekunden stehen dann erst alle Zeichen da wenn die IDE mal wieder kurz reagiert, ... so kann kein Mensch arbeiten. Wenn eine IDE 40+ Threads aufmacht erwarte ich mir irgendwie, dass die IDE im Hintergrund builden kann und nicht das GUI einfriert.
-
Optimizer schrieb:
Vielleicht hast du es noch nicht versucht, benutze mal irgendwelchen IDE-Features (außer den Build abzubrechen) währenddessen. Zum Beispiel klick den ersten Compilerfehler an und versuch ihn zu richten. Du tippst, nach 2 Sekunden stehen dann erst alle Zeichen da wenn die IDE mal wieder kurz reagiert, ... so kann kein Mensch arbeiten.
So soll man ja auch gar nict arbeiten; erst Buildvorgang unterbrechen, *dann* weiterarbeiten. Zugegeben, das *könnte* die IDE selbst machen aber mich hat's noch nie gestört.
-
Zwergli schrieb:
Und die .Net Runtimes sind abwärtskompatibel. Wenn man z.B. nur die 2er drauf hat, laufen da auch 1.1er Programme wenn der Entwickler nicht gerade ein Manifest zulegt was die Ausführung unter 1.1 erzwingt.
Glaubt MS doch nicht jeden quatsch... .NET ist nicht abwärtskomplatibel. Änderungen im Verhalten einer Funktion kann man oft noch mit "bugfix" umschreiben, obwohl auch das eigentlich schon bedeutet das die Abwärtskompatibilität verlohren geht (kann ja Leute geben die sich darauf verlassen das die Funktion buggy ist).
Dabei bleibt es aber nicht: es gab auch X Änderungen in den APIs und sobald das passiert ist man einfach nicht mehr abwärtskompatibel, egal wie MS das sieht.
Wirf mal nen blick in die 2 links die weiter vorne gepostet habe. Zufälliger Auszug:Short Description:
MarshalByRef should be removed from System.Uri signature
Affected APIs System.Uri Severity Low Compat Switch Available No--------------------------------------------------------------------------------
Description System.Uri mistakenly derived from MarshalByRefObj in V1 and V1.1. This has been the cause of significant customer pushback based on security issues associated with the fact that this type is supposed to be immutable and performance issues both in terms of URI construction time and run-time behavior.
--------------------------------------------------------------------------------
User Scenario Scenario(s): User code that is remoting a URI instance by reference.
--------------------------------------------------------------------------------
Work Around No workaround for URI construction time. This particular issue has a broad impact because System.Uri is the required way in LAPI to manipulate/parse a URI. The security issue and the run-time behavior can be mitigated by using a string instead of a URI. These two issues are more of a rare case but are still a concern because of the security risk.
Und jetzt erzähl mir mal was ein 1.1 programm, welches sich auf das MarshalByRefObj verlässt, auf 2.0 machen soll wenn es plötzlich nicht mer da ist?
-
Abwärtskompatibel ist .NET nur bedingt, das ist fakt. Schon bei einfachen Konstrukten gibt es Probleme - ich denke da an VB.NET. Und dann gibt es sehr viele Methoden die als "lieber nicht mehr nutzen" gekennzeichnet sind und das sollte man wörtlich nehmen, denn meistens funktionieren die auch nicht mehr.
Quellcode ändern während des Debuggens ist 'ne wichtige Sache! Wer zum Geier will sich wegen einer Miniänderung denn gleich nochmal durch das ganze Programm hangeln?? OK, kann man mit testunits umgehen, aber die nutzt man auch nicht immer. Das da bei der Beta noch nicht richtig funktioniert sollte man (noch) verzeihen, es ist immerhin erst die erste Beta! Beim Release - so hoffe ich - werden die Performanceprobleme der IDE weitgehenst behoben sein.
-
Konrad Rudolph schrieb:
Optimizer schrieb:
Vielleicht hast du es noch nicht versucht, benutze mal irgendwelchen IDE-Features (außer den Build abzubrechen) währenddessen. Zum Beispiel klick den ersten Compilerfehler an und versuch ihn zu richten. Du tippst, nach 2 Sekunden stehen dann erst alle Zeichen da wenn die IDE mal wieder kurz reagiert, ... so kann kein Mensch arbeiten.
So soll man ja auch gar nict arbeiten; erst Buildvorgang unterbrechen, *dann* weiterarbeiten. Zugegeben, das *könnte* die IDE selbst machen aber mich hat's noch nie gestört.
Solche Aussagen kann ich einfach nicht nachvollziehen. Es ist nicht akzeptabel, dass ein GUI einfriert für ein paar Minuten oder ein paar Minuten lang fast einfriert. "so soll man nicht arbeiten", mhm. So kann man nicht arbeiten und das ist scheiße.
Und nach Abschluss oder Abbruch muss man auch ne halbe Minute warten und kann gar nichts machen, ja so sollte man wirklich nicht arbeiten.