Programując pod Sharepointa czy inne tego typu badziewie musimy podpisywać nasze assemblies i wrzucać je do GACa. Już dwa razy mnie to "ugryzło" i straciłem w sumie dobre kilka godzin na diagnostykę poniższego scenariusza: 1) piszę testy do funkcjonalności zawartej w podpisanej dllce 2) koduję implementację w tejże dllce 3) uruchamiam testy 4) dostaję wyjątek TypeLoadException czy coś innego w ten deseń mówiącego, że w testowanej dllce nie ma kodu który... przecież tam jest bo dopiero co go napisałem!
Dziś stanąłem przed zadaniem skopiowania konkretnej biblioteki DLL z Global Assembly Cache (czyli de facto z folderu C:\Windows\Assembly). Była mi ona potrzebna do uruchomienia pewnej aplikacji na innym komputerze, a niestety ta wersja pliku nie była łatwo dostępna w żaden inny sposób.
Większość programistów podczas nauki programowania na platformie .NET omija temat silnych nazw i podpisywania assembly – nic dziwnego, kwestie te nie są najistotniejsze na etapie eksperymentowania z .NETem. W komercyjnych, profesjonalnych albo bardziej zaawansowanych projektach kwestie te zyskują na znaczeniu. W tym wpisie zajmę się tematyką związaną z Global Assembly Cache, podpisywaniem podzespołów (polska nazwa assembly) i silnymi nazwami.Po co podpisywać assembly? Zasadnicza odpowiedź na to pytanie ...
Rozwiązanie problemu pojawiającego się gdy często kopiowane są biblioteki *.dll do katalogu $:\Windows\assembly (inaczej GAC)