wie gehts mit .net weiter?
-
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.