Versiecompatibiliteit
Compatibiliteit met eerdere versies betekent dat een app die is ontwikkeld voor een bepaalde versie van een platform, wordt uitgevoerd op latere versies van dat platform. .NET Framework probeert compatibiliteit met eerdere versies te maximaliseren: broncode die is geschreven voor één versie van .NET Framework moet worden gecompileerd op latere versies van .NET Framework en binaire bestanden die worden uitgevoerd op één versie van .NET Framework, moeten zich identiek gedragen op latere versies van .NET Framework.
Versiecompatibiliteit voor apps
Standaard wordt een app uitgevoerd op de versie van .NET Framework waarvoor deze is gebouwd. Als die versie niet aanwezig is en het app-configuratiebestand geen ondersteunde versies definieert, kan er een initialisatiefout van .NET Framework optreden. In dit geval mislukt de poging om de app uit te voeren.
Als u de specifieke versies wilt definiëren waarop uw app wordt uitgevoerd, voegt u een of meer <ondersteundeRuntime-elementen> toe aan het configuratiebestand van uw app. Elk <supportedRuntime> element bevat een ondersteunde versie van de runtime, waarbij eerst de meest voorkeursversie en de laatste versie van de minst voorkeur worden opgegeven.
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v4.0" />
</startup>
</configuration>
Zie Instructies voor meer informatie : Een app configureren ter ondersteuning van .NET Framework 4 of 4.x.
Versiecompatibiliteit voor onderdelen
Een app kan de versie van .NET Framework beheren waarop deze wordt uitgevoerd, maar een onderdeel kan dat niet. Onderdelen en klassebibliotheken worden geladen in de context van een bepaalde app. Daarom worden ze automatisch uitgevoerd op de versie van .NET Framework waarop de app wordt uitgevoerd.
Vanwege deze beperking zijn compatibiliteitsgaranties vooral belangrijk voor onderdelen. Vanaf .NET Framework 4 kunt u opgeven in welke mate een onderdeel naar verwachting compatibel blijft voor meerdere versies door het System.Runtime.Versioning.ComponentGuaranteesAttribute kenmerk op dat onderdeel toe te passen. Hulpprogramma's kunnen dit kenmerk gebruiken om mogelijke schendingen van de compatibiliteitsgarantie in toekomstige versies van een onderdeel te detecteren.
Compatibiliteit met eerdere versies
.NET Framework 4.5 en nieuwere versies zijn compatibel met eerdere versies van .NET Framework. Met andere woorden, apps en onderdelen die zijn gebouwd met eerdere versies, werken zonder wijzigingen in .NET Framework 4.5 en nieuwere versies. Apps worden echter standaard uitgevoerd op de versie van de common language runtime waarvoor ze zijn ontwikkeld, dus u moet mogelijk een configuratiebestand opgeven om uw app in te schakelen voor uitvoering op de .NET Framework 4.5- of latere versies. Zie de sectie Versiecompatibiliteit voor apps eerder in dit artikel voor meer informatie.
In de praktijk kan deze compatibiliteit worden verbroken door schijnbaar inconsistente wijzigingen in het .NET Framework en wijzigingen in programmeertechnieken. Prestatieverbeteringen in .NET Framework 4.5 kunnen bijvoorbeeld een racevoorwaarde blootstellen die niet is opgetreden in eerdere versies. Op dezelfde manier is het gebruik van een in code vastgelegd pad naar .NET Framework-assembly's, het uitvoeren van een gelijkheidsvergelijking met een bepaalde versie van .NET Framework, en het ophalen van de waarde van een privéveld met behulp van reflectie zijn niet achterwaarts compatibele procedures. Bovendien bevat elke versie van .NET Framework bugfixes en beveiligingsgerelateerde wijzigingen die van invloed kunnen zijn op de compatibiliteit van sommige apps en onderdelen.
Als uw app of onderdeel niet werkt zoals verwacht in .NET Framework 4.5 of een latere versie, gebruikt u de volgende controlelijsten:
Als uw app is ontwikkeld om te worden uitgevoerd op elke versie van .NET Framework vanaf .NET Framework 4.0, raadpleegt u Toepassingscompatibiliteit voor het genereren van lijsten met wijzigingen tussen uw doelversie van .NET Framework en de versie waarop uw app wordt uitgevoerd.
Als u een .NET Framework 3.5-app hebt, raadpleegt u ook migratieproblemen met .NET Framework 4.
Als u een .NET Framework 2.0-app hebt, raadpleegt u ook Wijzigingen in .NET Framework 3.5 SP1.
Als u een .NET Framework 1.1-app hebt, raadpleegt u ook Wijzigingen in .NET Framework 2.0.
Als u bestaande broncode opnieuw comcompileert om uit te voeren op .NET Framework 4.5 of de puntreleases, of als u een nieuwe versie van een app of onderdeel ontwikkelt dat is gericht op .NET Framework 4.5 of de puntreleases van een bestaande broncodebasis, controleert u wat verouderd is in de klassebibliotheek voor verouderde typen en leden. en pas de beschreven tijdelijke oplossing toe. (Eerder gecompileerde code blijft actief op typen en leden die als verouderd zijn gemarkeerd.)
Als u vaststelt dat een wijziging in .NET Framework 4.5 uw app heeft verbroken, controleert u het runtime-Instellingen schema en met name het <element AppContextSwitchOverrides> om te bepalen of u een runtime-instelling in het configuratiebestand van uw app kunt gebruiken om het vorige gedrag te herstellen.
Als u een probleem tegenkomt dat niet wordt gedocumenteerd, opent u een probleem op de site ontwikkelaarscommunity voor .NET of opent u een probleem in de GitHub-opslagplaats van Microsoft/dotnet.
Naast elkaar uitvoeren
Als u geen geschikte tijdelijke oplossing voor uw probleem kunt vinden, moet u er rekening mee houden dat .NET Framework 4.5 (of een van de puntreleases) naast versie 1.1, 2.0 en 3.5 wordt uitgevoerd en een in-place update is die versie 4 vervangt. Voor apps die gericht zijn op versie 1.1, 2.0 en 3.5, kunt u de juiste versie van .NET Framework installeren op de doelcomputer om de app in de beste omgeving uit te voeren. Zie Side-by-Side Execution (Naast elkaar uitvoeren) voor meer informatie over de uitvoering naast elkaar.
