Detta tillvägagångssätt tillåter utvecklare att bara tillhandahålla den publika nyckeln till kompilatorn(erna) och stänga av den detaljerade nyckelkontrollen under testning. När varje sammansättning är fullständigt testad kan en betrodd administratör med åtkomst till den privata nyckeln signera dem alla. Vanligtvis skulle detta göras som en del av utvecklingsorganisationens releasecykel. För mer information om kommandona al.exe och sn.exe, se online-SDK:n på msdn.microsoft.com eller tinyurl.com
Om du är en administratör som hanterar användningen av .NET-applikationer kommer du förmodligen inte att göra så mycket signering eller kontroll av signaturer – för IT-proffsen sköts sådana lågnivåsaker i stort sett av utvecklaren . Men för att kunna använda Global Assembly-cachen måste alla sammanställningar du hanterar ha starka namn, så det är viktigt att förstå grunderna i hur allt detta fungerar.
För att illustrera detta kommer jag att visa dig en enkel klientapplikation som anropar en extern, starkt namngiven DLL. Här är klientprogrammet:
använder System;
klient i offentlig klass
{
public static void Main()
{Console.WriteLine(“In Maths Client”);
Maths m = new Maths ();
lång rl = 2;
lång r2 = 2;
lång r = m. Add(rl, r2);
Console.WriteLine (”2 + 2 = {0}”, r.ToString() );
}
}
Denna applikation anropar en externt definierad klass som heter Maths för att utföra enkel addition. När du kompilerar det här programmet refererar du till sammansättningen som innehåller den här klassen, och kompilatorn gör resten.
Den externa klassen, som vid körning finns i en separat DLL, ser ut så här:
använder System;
använder System.Reflection;
[assembly:AssemblyVersion(“1.1.1.100”)]
[assembly:AssemblyCulture(“”)]
offentlig klass matematik
{
offentlig lång Lägg till (långt a, långt b)
{
Console.WriteLine(“In Strongly Named Maths2.dll”);
returnera a + b;
}
}
Som du kan se specificerar den externa klassen sitt versionsnummer och kultur med hjälp av attribut, plus nyckelfilen som ska användas som en del av kompileringsprocessen. För att kompilera dessa två kodbitar med hjälp av de inbyggda kompilatorerna och sedan köra klientapplikationen, skulle kommandona se ut ungefär så här:
C:PCPro>csc /t:library maths2.cs
C:PCPro>csc /r:maths2.dll client.cs
C:PCPro>klient
I Maths Client
I Strongly Named Maths2.dll
2 + 2 = 4
C:PCPro>
Den starkt namngivna sammansättningen i det här fallet finns i samma mapp som den körbara klienten. Den enklaste metoden för att distribuera denna applikation och dess stödjande DLL skulle vara att placera dem båda i sin egen separata mapp, oberoende av andra applikationer med samma namn. För att se det starka namnet som skapats av kompileringen av maths2.sll, använd ILDASM för att se sammansättningens manifest, där du kan se det starka namnet, den offentliga nyckeln och versionsnumren för denna sammansättning. Om du skulle använda ILDASM för att undersöka manifestet av client.exe, skulle du se en extern referens för maths.dll, och denna referens skulle inkludera den offentliga nyckeln och versionsnumret.
Global Assembly Cache
När du installerar .NET Framework på en PC skapar installationsprogrammet en maskinomfattande sammansättningscache som kallas Global Assembly Cache (GAC). Du kan använda GAC för att lagra sammansättningar som används av flera applikationer, och ett nyckelkrav för varje sammansättning du vill placera i GAC är att den måste ha ett starkt namn.
