Ich habe eine Reihe von .NET-Komponenten, die vor langer Zeit entwickelt wurden (1.1). Ich möchte sie weiterhin für 1.1 für alle Clients bereitstellen, die diese Version benötigen, aber auch Versionen - in einigen Fällen den gleichen Code, in einigen Fällen mit Verbesserungen - für .NET 2 und .NET 3 (.5) anbieten. In jedem späteren Fall möchte ich möglicherweise Vorteile von neueren Features der Plattform für bestimmte Komponenten nutzen.
Ich suche nach Anleitung, was die beste Praxis in dieser Situation ist.
Wenn ich nicht versuche, irgendwelche Änderungen an einer Komponente vorzunehmen, dann stelle ich mir vor, dass ich sie trotzdem als 1.1 und später bereitstellen könnte. Bibliotheken / Anwendungen könnten einfach die 1.1 Assemblies konsumieren. Ich vermute, dass es immer noch gute Gründe geben könnte, Assemblies bereitzustellen, die mit späteren Versionen von .NET erstellt wurden - z. Leistung - aber mein Verständnis ist, dass ich nur die 1.1 liefern könnte. Ist das korrekt?
Wenn ich den Großteil des Codes einer Komponente mit 1.1 arbeiten lassen möchte, aber auch Features für spätere .NET-Versionen hinzufügen möchte, was ist der beste Ansatz?
Auch jeder Hinweis, was mit der Unterzeichnung der Versammlung zu tun ist, wird sehr geschätzt.
Vielen Dank im Voraus
In meiner ziemlich harten Meinung ist es weit hinter dem Ende, .NET 1.1 nicht mehr zu unterstützen. Der einzige gute Grund, warum ich immer noch .NET 1.1 verwenden kann, ist, wenn Sie immer noch Hardware unterstützen müssen, die .NET 2.0 nicht unterstützt - und zu diesem späten Zeitpunkt bin ich mir nicht sicher, ob wir das einen guten Grund nennen können / p>
Abgesehen von der Hardware-Unterstützung habe ich in der Tat keine vernünftigen Gründe für einen Computer gehört, der nicht auf .NET 3.5 SP1 aktualisiert wird. Soweit es .NET 2.0-Anwendungen betrifft, ist .NET 3.5 SP1 nur .NET 2.0 SP2. Sie müssen sich fragen, warum jemand nicht ein Service Pack implementieren möchte, das schon seit fast einem Jahr existiert.
Der ganze Rest von .NET 3.0 und .NET 3.5 sind nur zusätzliche Assemblys, die keinen Einfluss auf Code haben können, der sie nicht verwendet.
Ich wollte also meinen Wunsch, alle meine Kunden gegen die fortgesetzten Kosten der Unterstützung von .NET 1.1 zu bedienen, ausbalancieren. Vielleicht werden Sie es weiterhin unterstützen, aber zusätzliche Kosten für Support und ein Los mehr für neue Funktionen verlangen. Gleiches gilt in geringerem Maße für .NET 2.0.
Noch ein wilderer Gedanke: Unterstützen wir die .NET 1.1-Unternehmen nicht, indem wir sie weiter unterstützen, als ob es keine zusätzlichen Kosten gäbe? Machen wir ihnen wirklich einen Gefallen, indem wir ihnen helfen, ihre Köpfe im Sand zu halten? Selbst wenn sie zu beschäftigt sind, um es zu sehen, kann es nicht lange dauern, bis ein Startup mit ihnen konkurriert und viele ihrer Geschäfte gewinnt, nicht weil sie eine bessere Firma sind, sondern weil sie WCF und ASP.NET MVC und AJAX und all die coolen Features, von denen die .NET 1.1-Leute nur träumen können.
Ich pflege ein Projekt für .NET 2.0, .NET 3.0, .NET 3.5 CF 2.0, CF 3.5, Mono 2.x und Silverlight 2.0 - ich mache das meiste mit einer Kombination aus Projektdateien (Build) und #if Direktiven, um die Menge an doppeltem Code zu minimieren / zu lokalisieren.
Meistens gebe ich die gleichen DLLs aus - obwohl ich einige 3.5-spezifische DLLs erstellt habe, um Dinge wie Erweiterungsmethoden abzudecken.
Eine wichtige Aufgabe ist es, das einzurichten, damit Sie sie alle schnell erstellen / testen können - zum Beispiel habe ich eine einzige "build.bat", die prüft, ob sie in allen von ihnen kompiliert wird (ist es wirklich leicht, illegale Syntax einzuführen).
Für 1.1 stelle ich mir vor, dass Sie MSBee verwenden könnten, aber Sie könnten ein "csc" benötigen - aber es gibt einige grundlegende Änderungen (wie zB keine Generika), es könnte also eine Größenordnung schwerer sein ...
Das scheint die Art von Sache zu sein, die ziemlich schnell unordentlich werden könnte. Entweder werden Sie mehrere Streams der gleichen Codebase verwalten, die auf verschiedene Frameworks abzielen (in diesem Fall sollten Sie definitiv Zweige in Ihrem SCM berücksichtigen), oder Sie werden Funktionen in Klassen zerlegen, die diskrete Aufgaben für verschiedene Frameworks ausführen .
Ich denke, es wird hauptsächlich darauf ankommen, wie Sie erwarten, dass die Codebasis in Zukunft wächst. Wenn Sie begrenzte Änderungen an den ersetzten Versionen erwarten, würde ich einfach fortfahren und mit den meisten neuen Funktionen in die neueste Generation von .NET verzweigen, um die neuen Sprachfunktionen zu nutzen. Die meisten deiner neuen Funktionen sind in 3.0 und 3.5 angekommen, also würde ich es vorziehen, die Kunden nach Möglichkeit zu ihnen zu bewegen; Sie bekommen die neue Sprache und Sie können Ihre Aufmerksamkeit darauf konzentrieren, hauptsächlich auf einen Rahmen zu bauen.