Freigeben über

Migrieren von .NET Framework 1.1, 2.0 und 3.5 zu .NET Framework 4

Windows unterstützt .NET Framework 1.1 und 2.0 nicht mehr. Daher werden Anwendungen, die auf ältere .NET Framework-Versionen abzielen, nicht ausgeführt, ohne .NET Framework 3.5 explizit zu installieren. Es wird jedoch empfohlen, die App auf .NET Framework 4 zu aktualisieren. In diesem Artikel werden die Schritte erläutert, die zum Ausführen einer Anwendung erforderlich sind, die auf eine alte Version von .NET Framework ausgerichtet ist.

Neuausrichtung oder Neukompilierung

Es gibt zwei Möglichkeiten zum Abrufen einer Anwendung, die mit .NET Framework 1.1 kompiliert wurde, um unter Windows 7 oder einem höheren Windows-Betriebssystem auszuführen:

  • Ändern Sie das Ziel der Anwendung, damit sie unter .NET Framework 4 und späteren Versionen läuft.

    Für retargeting müssen Sie der Konfigurationsdatei der Anwendung ein <unterstütztesRuntime-Element> hinzufügen, mit dem es unter .NET Framework 4 und höheren Versionen ausgeführt werden kann.

    Die Konfigurationsdatei für eine App ist eine XML-Datei, die sich im selben Verzeichnis befindet und denselben Dateinamen wie die App hat, aber mit einer .config Erweiterung. Zum Beispiel wird die Konfigurationsdatei für eine App namens MyExecutable.exe als MyExecutable.exe.config benannt.

    Eine solche Konfigurationsdatei hat folgende Form:

    <configuration>
   <startup>
      <supportedRuntime version="v4.0"/>
   </startup>
</configuration>

  • Kompilieren Sie die Anwendung mit einem Compiler, der auf .NET Framework 4 oder eine höhere Version ausgerichtet ist. Wenn Sie Visual Studio 2003 ursprünglich zum Entwickeln und Kompilieren Ihrer Lösung verwendet haben, können Sie die Projektmappe in Visual Studio 2010 (und möglicherweise auch späteren Versionen) öffnen und das Dialogfeld " Projektkompatibilität " verwenden, um die Projektmappen- und Projektdateien aus den von Visual Studio 2003 verwendeten Formaten in das MsBuild-Format (Microsoft Build Engine) zu konvertieren.

    Unabhängig davon, ob Sie Ihre Anwendung neu kompilieren oder auf ein neues Ziel ausrichten möchten, müssen Sie bestimmen, ob Ihre Anwendung von Änderungen betroffen ist, die in späteren Versionen des .NET Framework eingeführt wurden. Diese Änderungen sind von zwei Arten:

  • Breaking Changes zwischen .NET Framework 1.1 und höheren Versionen von .NET Framework, die die Lauffähigkeit der Anwendung beeinträchtigen.

  • Typen und Typmember, die zwischen .NET Framework 1.1 und höheren Versionen von .NET Framework als veraltet markiert wurden.

Überprüfen Sie beim Zuweisen einer neuen Zielversion und auch beim Neukompilieren Ihrer Anwendung sowohl die Breaking Changes als auch die veralteten Typen und Member für jede Version von .NET Framework, die nach .NET Framework 1.1 veröffentlicht wurde.

Bahnbrechende Änderungen

Bei einer Änderung, die die Lauffähigkeit der Anwendung beeinträchtigt, ist ggf. eine Problemumgehung sowohl für Anwendungen mit neuer Zielversion als auch für neu kompilierte Anwendungen verfügbar. In einigen Fällen können Sie dem <Laufzeitelement> der Konfigurationsdatei Ihrer Anwendung ein untergeordnetes Element hinzufügen, um das vorherige Verhalten wiederherzustellen. Die folgende Konfigurationsdatei stellt z. B. das in .NET Framework 1.1 verwendete Zeichenfolgensortierungs- und Vergleichsverhalten wieder her und kann entweder mit einer retargetierten oder einer neu kompilierten Anwendung verwendet werden.

<configuration>
   <runtime>
      <CompatSortNLSVersion enabled="4096"/>
   </runtime>
</configuration>

In einigen Fällen müssen Sie den Quellcode jedoch möglicherweise ändern und die Anwendung neu kompilieren.

Um die Auswirkungen möglicher einschneidender Änderungen auf Ihre Anwendung zu bewerten, müssen Sie die folgenden Listen der Änderungen überprüfen.

Veraltete Typen und Mitglieder

Die Auswirkungen veralteter Typen und Member unterscheiden sich bei retargetierten Anwendungen und neu kompilierten Anwendungen etwas. Die Verwendung veralteter Typen und Member wirkt sich nicht auf eine Anwendung mit neuer Zielversion aus, sofern der veraltete Typ oder Member nicht physisch aus seiner Assembly entfernt wurde. Durch das Erneute Kompilieren einer Anwendung, die veraltete Typen oder Member verwendet, wird in der Regel eine Compilerwarnung anstelle eines Compilerfehlers erzeugt. In einigen Fällen erzeugt sie jedoch einen Compilerfehler, und Code, der den veralteten Typ oder member verwendet, wird nicht erfolgreich kompiliert. In diesem Fall müssen Sie den Quellcode neu schreiben, der den veralteten Typ oder member aufruft, bevor Sie die Anwendung neu kompilieren. Weitere Informationen zu veralteten Typen und Membern finden Sie unter Was ist veraltet in der Klassenbibliothek.

Nähere Informationen zur Bewertung der Auswirkungen von Typen und Membern, die seit dem Release von .NET Framework 2.0 SP1 veraltet sind, finden Sie unter Veraltete Elemente in der Klassenbibliothek. Überprüfen Sie die Listen veralteter Typen und Member für .NET Framework 2.0 SP1, .NET Framework 3.5 und .NET Framework 4.