Migrowanie z programu .NET Framework 1.1, 2.0 i 3.5 do programu .NET Framework 4

System Windows nie obsługuje już programu .NET Framework 1.1 i 2.0. W związku z tym aplikacje przeznaczone dla starszych wersji programu .NET Framework nie będą działać bez jawnego instalowania programu .NET Framework 3.5. Zaleca się jednak uaktualnienie aplikacji do programu .NET Framework 4. W tym artykule omówiono kroki wymagane do uruchomienia aplikacji przeznaczonej dla starej wersji programu .NET Framework.

Przekieruj lub skompiluj ponownie

Istnieją dwa sposoby uzyskania aplikacji skompilowanej przy użyciu programu .NET Framework 1.1 do uruchomienia w systemie Windows 7 lub nowszym systemie operacyjnym Windows:

• Ponownie ukierunkować aplikację, aby działała w środowisku .NET Framework 4 i nowszych wersji.

  Retargeting wymaga dodania elementu <supportedRuntime> do pliku konfiguracji aplikacji, który umożliwia uruchamianie jej na platformie .NET Framework 4 i nowszych wersjach.

  Plik konfiguracji aplikacji jest plikiem XML, który znajduje się w tym samym katalogu i ma taką samą nazwę pliku jak aplikacja, ale z .config rozszerzeniem. Na przykład w przypadku aplikacji o nazwie MyExecutable.exeplik konfiguracji aplikacji nosi nazwę MyExecutable.exe.config.

  Taki plik konfiguracji ma następującą formę:

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

• Ponownie skompiluj aplikację za pomocą kompilatora, który jest przeznaczony dla programu .NET Framework 4 lub nowszej wersji. Jeśli pierwotnie użyto programu Visual Studio 2003 do opracowywania i kompilowania rozwiązania, możesz otworzyć rozwiązanie w programie Visual Studio 2010 (i ewentualnie nowszych wersjach) i użyć okna dialogowego Zgodność projektu , aby przekonwertować pliki rozwiązania i projektu z formatów używanych przez program Visual Studio 2003 do formatu microsoft Build Engine (MSBuild).

  Niezależnie od tego, czy wolisz ponowne kompilowanie, czy zmianę przeznaczenia aplikacji, musisz określić, czy Twoja aplikacja jest dotknięta jakimikolwiek zmianami wprowadzonymi w nowszych wersjach .NET Framework. Te zmiany mają dwa rodzaje:

• Zmiany powodujące niezgodność, które wystąpiły między programem .NET Framework 1.1 i nowszymi wersjami programu .NET Framework.

• Typy i składowe typu, które zostały oznaczone jako wycofane lub przestarzałe pomiędzy wersją .NET Framework 1.1 i późniejszymi wersjami .NET Framework.

Niezależnie od tego, czy retargetujesz aplikację, czy ponownie ją skompilujesz, przejrzyj zarówno zmiany powodujące niezgodność, jak i przestarzałe typy i elementy członkowskie dla każdej wersji programu .NET Framework wydanej po programie .NET Framework 1.1.

Zmiany przełomowe

W przypadku wystąpienia krytycznej zmiany, w zależności od jej rodzaju, obejście może być dostępne zarówno dla aplikacji przekształconych, jak i ponownie skompilowanych. W niektórych przypadkach można dodać element podrzędny do <elementu uruchomieniowego> pliku konfiguracji aplikacji w celu przywrócenia poprzedniego zachowania. Na przykład poniższy plik konfiguracji przywraca zachowanie sortowania i porównywania ciągów używane w programie .NET Framework 1.1 i może być używany z ponownie ukierunkowaną lub ponownie skompilowaną aplikacją.

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

Jednak w niektórych przypadkach może być konieczne zmodyfikowanie kodu źródłowego i ponowne skompilowania aplikacji.

Aby ocenić wpływ zmian, które mogą powodować niezgodności w aplikacji, należy przejrzeć następujące listy zmian:

• Istotne zmiany w dokumentach programu .NET Framework 2.0 w programie .NET Framework 2.0 z dodatkiem SP1, które mogą mieć wpływ na aplikację przeznaczoną dla programu .NET Framework 1.1.

• Dokument "Zmiany w .NET Framework 3.5 SP1" opisuje różnice między .NET Framework 3.5 a .NET Framework 3.5 SP1.

• Dokumentacja dotycząca zagadnień związanych z migracją z .NET Framework 3.5 SP1 do .NET Framework 4 opisuje zmiany między tymi wersjami.

Przestarzałe typy i członkowie

Wpływ przestarzałych typów i elementów członkowskich jest nieco inny w przypadku ponownie ukierunkowanych aplikacji i ponownie skompilowanych aplikacji. Użycie przestarzałych typów i elementów członkowskich nie wpłynie na ponownie docelową aplikację, chyba że przestarzały typ lub element członkowski został fizycznie usunięty z zestawu. Ponowne kompilowanie aplikacji, która używa przestarzałych typów lub elementów członkowskich, zwykle generuje ostrzeżenie kompilatora, a nie błąd kompilatora. Jednak w niektórych przypadkach generuje błąd kompilatora, a kod, który używa przestarzałego typu lub elementu członkowskiego, nie kompiluje się pomyślnie. W takim przypadku należy ponownie napisać kod źródłowy, który wywołuje przestarzały typ lub członek, zanim ponownie skompilujesz aplikację. Aby uzyskać więcej informacji o przestarzałych typach i członkach, sprawdź Co jest przestarzałe w bibliotece klas.

Aby dowiedzieć się, jaki wpływ miały typy i elementy członkowskie, które zostały oznaczone jako przestarzałe od wydania platformy .NET Framework 2.0 SP1, zobacz Co jest przestarzałe w bibliotece klas. Przejrzyj listy przestarzałych typów i elementów członkowskich dla programu .NET Framework 2.0 z dodatkiem SP1, .NET Framework 3.5 i .NET Framework 4.