Die Frage ist nicht, ob Sie sollten, - in Bezug auf Features und zusätzliche Kompilierzeitprüfungen; Es ist fast selbstverständlich, aus dem Framework 1.1 in das Framework 2.0 zu gelangen. Die Frage ist, wie schnell sollten Sie portieren? Was müsste geändert werden?
Der erste Schritt wäre, Ihre Anwendung nach .NET 2.0 zu portieren. Der Grund dafür ist, dass es in .NET 2.0 viele Features gibt, die vorher nicht existierten und frühere Features veraltet waren. (In ASP.NET gab es eine Reihe von Funktionen, die in 2.0 nicht mehr unterstützt werden).
.NET 2.0 ermöglicht stärkere typsichere Typen, Nullable-Typen und Änderungen im Framework. 2.0 repräsentiert (was ich für richtig halte) die erste "echte" Version der .NET-Plattform. Es ist ein ernsthafter Konkurrent, und Sie werden feststellen, dass einige der Framework-Sachen, die Sie in 1.1 verwenden, in 2.0 modifiziert wurden.
Es ist nicht einfach, den Code weiterzuleiten und das Nutzen-Szenario zu erhalten. Wenn Sie die Vorteile wollen, müssen Sie etwas Code (vor allem Dinge, die Generics) neu schreiben; Aber selbst im größeren .NET-Framework gibt es so viele "Änderungen hinter den Kulissen", dass Sie es inkrementell portieren möchten: Machen Sie den Sprung nicht direkt von 1.1 - 3.5.
1.1 - 2.0
Es gibt eine Reihe von Änderungen zwischen .NET 2.0 und .NET 3.0. Es gab einen ganzen Paradigmenwechsel. (Obwohl es zugegebenermaßen eine freiwillige Schicht ist). Wikipedia hat eine ganze Sektion, aber ich werde (einige!) Änderungen vornehmen hier:
Änderungen am .NET-Framework
C # Änderungen :
Mehr zu kommen, offensichtlich. Nur der Sprung von 1.1 zu 2.0 ist einen ganzen Release-Zyklus wert.
.net 1.1 ist veraltet und wird nicht weiterentwickelt. Ich bin mir nicht sicher über Sicherheitsprobleme. aber im Allgemeinen ist es aufgegeben, und ab 2.0 Microsoft sorgt für die Rückwärtskompatibilität in neueren Versionen, die 1.1 nicht der Fall ist.
Wenn du also eine Chance hast, dich zu bewegen - bewege dich. Sie bekommen neue Sprachfeatures, Sie bekommen ein Framework, das ständig weiter und weiter aufgebaut wird. Sie erhalten Linq, wenn Sie es brauchen, Silverlight-Unterstützung, Generika natürlich, etc.
Ich habe kürzlich eine komplette Codebasis von .NET 1.1 nach .NET 2.0 konvertiert. Berücksichtigen Sie, dass es sich bei .NET 3.5 eigentlich nur um Erweiterungen für .NET 2.0 handelt, es handelt sich nicht um eine komplett neue Basis.
Der Unterschied ist in vielen Teilen sehr groß. Für mich war .NET 1.1 in keiner Weise "gezähmt" und erforderte eine Menge Code. Außerdem musste VS 7 gegen .NET 1.1 verwendet werden, daher waren ältere Tools erforderlich.
Für Web-Apps wurde eine andere Web-Konfiguration benötigt, da die .NET-Version dadurch noch unordentlicher wird. Gehen Sie nicht in die ".NET 3.5 hat neue Funktionen, daher muss ich dazu bewegen" Bewegung, weil Sie die Entscheidung basierend auf den Anforderungen treffen müssen, nicht auf mögliche Werkzeugverwendungen. Wie viele Autoren zu Recht betonen, besteht eine gute Chance, dass Sie nicht die Hälfte der Funktionen verwenden, die das gesamte Framework bilden.
Ich würde andererseits empfehlen, zumindest von .NET 1.1 nach .NET 2.0 zu wechseln.
Es gibt eine Reihe von zwingenden Gründen für ein Upgrade auf .NET 3.5. Wie andere jedoch darauf hingewiesen haben, ist 3.5 weitgehend (wenn nicht vollständig) nichts anderes als Erweiterungen zu 2.0; 2.0 bringt jedoch eine große Anzahl von Features auf den Tisch, die den Umzug wert sind. Das heißt, in meinen Gedanken, wenn Sie den Zug machen, scheint es ziemlich albern zu 2.0 zu bewegen und nicht nur zu 3.5 zu bewegen.
Erweiterungsmethoden allein sind außerordentlich nützlich . Ich benutze sie viel häufiger, als ich dachte. Außerdem basieren viele der neueren Funktionen in 3.5 auf ihnen. Generika vereinfachen einen großen Teil unserer Entwicklung erheblich; Und wenn Sie in C # programmieren, sind automatische Setter und Getter ein Segen. Lambda-Ausdrücke sind für mich noch relativ neu, daher kann ich nicht mit ihnen sprechen, aber ich verstehe, dass andere sie besonders nützlich finden.
WPF präsentiert eine völlig neue Art, Anwendungen zu schreiben, und ich habe sie benutzt. Es zeigt großes Versprechen; Leider scheint es nicht, die breite Annahme zu bekommen, die ich (persönlich) denke, dass es noch verdient. Hoffentlich ändert sich das mit der Zeit, aber das hängt davon ab, ob Microsoft selbst es aggressiver treibt.
Soweit das Framework selbst betroffen ist, finde ich, dass viele Funktionen verbessert oder bereitgestellt wurden, die vorher in 1.1 fehlten; Wenn es reift, scheint das Framewok in eine Richtung zu gehen, in der wir weniger Code für die Aufgaben schreiben müssen, die wir normalerweise ausführen (z. B. Verzeichnisdienste, FTP-Zugriff, Named Pipes usw.). Die Ecken und Kanten werden glatter.
Kurz gesagt: Die Umstellung auf 3.5 würde bedeuten, dass Ihre neueren Anwendungen mit weniger Code geschrieben werden könnten und vorhandene Anwendungen könnten so umgestaltet werden, dass weniger Code verwendet wird (nicht, dass ich dies nur für diesen Zweck empfehlen würde). 3.5 stellt Ihnen eine breite Palette von Produktivitätswerkzeugen zur Verfügung; Meine persönliche Meinung ist, dass diese Werkzeuge allein den Sprung wert sind.
Aber wie bei jeder geschäftlichen Entscheidung müssen Sie all dies gegen den Zustand Ihrer Projekte abwägen - und eventuelle Fehler, die beim Portieren der Codebasis auftreten könnten. Meine bisherige Erfahrung war, dass wir einige Schwierigkeiten hatten, aber nicht genug, um die gesamte Operation zum Stillstand zu bringen. Bei jeder Migration besteht jedoch immer die Möglichkeit, dass der Code nicht mehr funktioniert. das muss man sich merken.
Der größte Unterschied besteht darin, dass Sie zu der .NET 2.0-CLR wechseln (Dies ist dieselbe CLr, auf der die aktuelle .NET-Version ausgeführt wird).
Dies bedeutet, dass Sie eine Fülle von Bugfixes und Generics-Unterstützung auf CLR-Ebene haben. Der Rest der Änderungen sind nur Änderungen an den Basisklassenbibliotheken und neuen Sprachenfunktionen in den Compilern.
Ich denke, ein wirklich guter Grund ist das Provider-Framework, das in ASP.NET 2.0 und höher eingerichtet wurde. Die Möglichkeit, ob ein Benutzer angemeldet ist, oder eine Liste von Rollen, die ein Benutzer hat, ohne sich Gedanken über den zugrunde liegenden Mechanismus machen zu müssen, ist ein großer Vorteil.
Bearbeiten und fortfahren? Auch Generics und Nullable-Typen machen das Leben ein bisschen leichter!