Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Anmärkning
Den här artikeln är specifik för .NET Framework. Det gäller inte för nyare implementeringar av .NET, inklusive .NET 6 och senare versioner.
Sida vid sida-körning är möjligheten att köra flera versioner av ett program eller en komponent på samma dator. Du kan ha flera versioner av den gemensamma språkkörningen och flera versioner av program och komponenter som använder en version av körningen på samma dator samtidigt.
Följande bild visar flera program som använder två olika versioner av körningen på samma dator. Program A, B och C använder runtime version 1.0, medan program D använder körningsversion 1.1.
.NET Framework består av den gemensamma språkkörningen och en samling sammansättningar som innehåller API-typerna. Runtime- och .NET Framework-sammansättningarna versionshanteras separat. Version 4.0 av runtime-miljön är faktiskt version 4.0.319, medan version 1.0 av .NET Framework assemblies är version 1.0.3300.0.
Följande bild visar flera program som använder två olika versioner av en komponent på samma dator. Program A och B använder version 1.0 av komponenten medan Application C använder version 2.0 av samma komponent.
Med körning sida vid sida får du mer kontroll över vilka versioner av en komponent som ett program ansluter sig till och mer kontroll över vilken version av runtime-miljön som ett program använder.
Fördelar med genomförande sida vid sida
Före Windows XP och .NET Framework uppstod DLL-konflikter eftersom program inte kunde skilja mellan inkompatibla versioner av samma kod. Typinformationen i en DLL var endast bunden till ett filnamn. Ett program hade inget sätt att veta om typerna i en DLL var samma typer som programmet skapades med. Därför kan en ny version av en komponent skriva över en äldre version och bryta program.
Sida vid sida-körning och .NET Framework tillhandahåller följande funktioner för att eliminera DLL-konflikter:
Starka namngivna sammansättningar.
Sida vid sida-körning använder starka namngivna sammansättningar för att binda typinformation till en specifik version av en sammansättning. Detta förhindrar att ett program eller en komponent binds till en ogiltig version av en sammansättning. Med starka namngivna sammansättningar kan även flera versioner av en fil finnas på samma dator och användas av program. Mer information finns iStrong-Named Sammansättningar.
Versionsmedveten kodlagring.
.NET Framework tillhandahåller versionsmedveten kodlagring i den globala sammansättningscacheminnet. Den globala samlingscachen är en datoromfattande kodcache som finns på alla datorer med .NET-plattformen installerad. Den lagrar sammansättningar baserat på information om version, kultur och utgivare och stöder flera versioner av komponenter och program. Mer information finns i Global Assembly Cache.
Isolering.
Med hjälp av .NET Framework kan du skapa program och komponenter som körs isolerat. Isolering är en viktig komponent i körningen sida vid sida. Det handlar om att vara medveten om de resurser du använder och dela resurser med förtroende mellan flera versioner av ett program eller en komponent. Isolering omfattar även lagring av filer på ett versionsspecifikt sätt. Mer information om isolering finns i Riktlinjer för att skapa komponenter för körning sida vid sida.
Versionskompatibilitet
Version 1.0 och 1.1 av .NET Framework är utformade för att vara kompatibla med varandra. Ett program som skapats med .NET Framework version 1.0 ska köras på version 1.1 och ett program som skapats med .NET Framework version 1.1 ska köras på version 1.0. Observera dock att API-funktioner som lagts till i version 1.1 av .NET Framework inte fungerar med version 1.0 av .NET Framework. Program som skapats med version 2.0 körs endast på version 2.0. Version 2.0-program körs inte på version 1.1 eller tidigare.
Versioner av .NET Framework behandlas som en enda enhet som består av körningen och dess associerade .NET Framework-sammansättningar (ett begrepp som kallas sammansättningssammanslagning). Du kan omdirigera sammansättningsbindningen till andra versioner av .NET Framework-sammansättningarna, men att åsidosätta standardsammansättningsbindningen kan vara riskabelt och måste testas noggrant före distributionen.
Hitta versionsinformation för Runtime
Information om vilken körningsversion ett program eller en komponent kompilerades med och vilka versioner av körningsmiljön som programmet måste köra lagras på två platser. När ett program eller en komponent kompileras lagras information om den körningsversion som används för att kompilera den i den hanterade körbara filen. Information om de körningsversioner som programmet eller komponenten kräver lagras i programkonfigurationsfilen.
Körningsversionsinformation i det hanterade programmet
Den portabla körbara filen (PE) för varje hanterat program och komponent innehåller information om den version av körmiljön den är byggd med. Den gemensamma språkkomponenten använder den här informationen för att fastställa den mest sannolika versionen av runtime som programmet behöver använda.
Körningsversionsinformation i programkonfigurationsfilen
Förutom informationen i PE-filhuvudet kan ett program distribueras med en programkonfigurationsfil som innehåller information om körningsversion. Programkonfigurationsfilen är en XML-baserad fil som skapas av programutvecklaren och som levereras med ett program. RequiredRuntime-elementet<> i startavsnittet<>, om det finns i den här filen, anger vilka versioner av körningen och vilka versioner av en komponent som programmet stöder. Du kan också använda den här filen vid testning för att testa ett programs kompatibilitet med olika versioner av körningen.
Ohanterad kod, inklusive COM- och COM+-program, kan ha programkonfigurationsfiler som körningen använder för att interagera med hanterad kod. Programkonfigurationsfilen påverkar all hanterad kod som du aktiverar via COM. Filen kan ange vilka körningsversioner den stöder samt assembly-omdirigeringar. Som standard använder COM-interop-program som anropar hanterad kod den senaste versionen av runtime-miljön som är installerad på din dator.
Mer information om programkonfigurationsfilerna finns i Konfigurera appar.
Avgöra vilken version av runtime-miljön som ska laddas
Den gemensamma språk-körtiden använder följande information för att avgöra vilken version av körtiden som ska läsas in för en applikation:
De runtime-versioner som är tillgängliga.
De tillgängliga körningsversionerna som en applikation stöder.
Körningsversioner som stöds
Körningen använder programkonfigurationsfilen och det portabla körbara filhuvudet (PE) för att avgöra vilken version av körningen som ett program stöder. Om det inte finns någon programkonfigurationsfil läser körningen in den körningsversion som anges i programmets PE-filhuvud, om den versionen är tillgänglig.
Om det finns en programkonfigurationsfil avgör körningsmiljön vilken körningsversion som ska läsas in baserat på resultatet av följande process:
Körningen undersöker <supportedRuntime>-elementet i programkonfigurationsfilen. Om en eller flera av de körningsversioner som stöds som anges i elementetruntime<> som stöds finns läser körningsmiljön in den körningsversion som anges av det första <körtidselementet> som stöds. Om den här versionen inte är tillgänglig undersöker runtime nästa <supportedRuntime-element> och försöker läsa in den angivna runtime-versionen. Om den här körningsversionen inte är tillgänglig granskas efterföljande <körningselement> som stöds. Om ingen av de körningsversioner som stöds är tillgängliga misslyckas körningsmiljön med att läsa in en körningsversion och visar ett meddelande till användaren (se steg 3).
Körningen läser PE-filhuvudet för programmets körbara fil. Om körningsversionen som anges av PE-filhuvudet är tillgänglig läser körningsmiljön in den versionen. Om den angivna körningsversionen inte är tillgänglig, söker körmiljön efter en körningsversion som Microsoft bestämmer är kompatibel med körningsversionen i PE-huvudet. Om den versionen inte hittas fortsätter processen till steg 3.
Körtidsmiljön visar ett meddelande om att körtidsversionen som stöds av programmet inte är tillgänglig. Körningen läses inte in.
Anmärkning
Du kan ignorera visningen av det här meddelandet med värdet NoGuiFromShim under registernyckeln HKLM\Software\Microsoft\. NETFramework eller med hjälp av miljövariabeln COMPLUS_NoGuiFromShim. Du kan till exempel ignorera meddelandet för program som vanligtvis inte interagerar med användaren, till exempel obevakade installationer eller Windows-tjänster. När meddelandevisningen undertrycks skriver körmiljön ett meddelande till händelseloggen. Ange registervärdet NoGuiFromShim till 1 för att ignorera det här meddelandet för alla program på en dator. Alternativt anger du COMPLUS_NoGuiFromShim miljövariabeln till 1 för att utelämna meddelandet för program som körs i en viss användarkontext.
Anmärkning
När en körningsversion har lästs in kan omdirigeringar för sammansättningsbindningar ange att en annan version av en enskild .NET Framework-sammansättning ska läsas in. Dessa bindningsomdirigeringar påverkar endast den specifika sammansättning som omdirigeras.
Delvis kvalificerade assemblynamn och sida vid sida körning
Eftersom de är en potentiell källa till problem sida vid sida kan delvis kvalificerade sammansättningsreferenser endast användas för att binda till sammansättningar i en programkatalog. Undvik delvis kvalificerade sammansättningsreferenser i koden.
För att minimera delvis kvalificerade sammansättningsreferenser i kod kan du använda elementet <qualifyAssembly> i en programkonfigurationsfil för att fullständigt kvalificera delvis kvalificerade sammansättningsreferenser som förekommer i kod. Använd elementet <qualifyAssembly> om du bara vill ange fält som inte har angetts i den partiella referensen. Sammansättningsidentiteten som anges i attributet fullName måste innehålla all information som behövs för att fullständigt kvalificera sammansättningsnamnet: sammansättningsnamn, offentlig nyckel, kultur och version.
I följande exempel visas ett inlägg i konfigurationsfilen för att fullständigt kvalificera en sammansättning kallad myAssembly.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="myAssembly"
fullName="myAssembly,
version=1.0.0.0,
publicKeyToken=...,
culture=neutral"/>
</assemblyBinding>
När en instruktion för att läsa in en sammansättning refererar till myAssembly leder dessa konfigurationsfilinställningar till att körningen automatiskt översätter den delvis kvalificerade myAssembly-referensen till en fullständigt kvalificerad referens. Till exempel blir Assembly.Load("myAssembly") Assembly.Load("myAssembly, version=1.0.0.0, publicKeyToken=..., culture=neutral").
Anmärkning
Du kan använda metoden LoadWithPartialName för att kringgå den vanliga språkkörningsbegränsningen som förhindrar att delvis refererade sammansättningar läses in från den globala sammansättningscachen. Den här metoden bör endast användas i fjärrscenarier eftersom den enkelt kan orsaka problem vid parallell körning.
Relaterade ämnen
| Titel | Beskrivning |
|---|---|
| Så här aktiverar och inaktiverar du automatisk omdirigering av bindning | Beskriver hur du binder ett program till en viss version av en sammansättning. |
| Konfigurera omdirigering av sammansättningsbindning | Förklarar hur du omdirigerar sammansättningsbindningsreferenser till en specifik version av .NET Framework-sammansättningarna. |
| In-Process sida vid sida-körning | Förklarar hur man kan använda sida-vid-sida aktivering av runtime-värd i-process för att köra flera versioner av CLR i en enda process. |
| sammansättningar i .NET | Ger en konceptuell översikt över sammansättningar. |
| Programdomäner | Ger en konceptuell översikt över programdomäner. |