Biblioteki łączone dynamicznie (DLL)

Biblioteki łączone dynamiczne, czy też po prostu biblioteki klas każdy z nas raczej zna. Są to pliki, z którymi stykamy się na co dzień podczas pracy z systemem Windows. Jednak jakie jest ich zastosowanie? Jak je tworzyć i jak ich używać? Dzisiaj przybliżę trochę ten temat 😉

Czym właściwie są pliki *.dll?

Pliki dll można nazwać swoistymi kontenerami dla kodu/zasobów. Trzeba jednak  zaznaczyć, że nie są one samodzielnymi aplikacjami. Co to oznacza? Kodu w nich zawartego nie da się wykonać inaczej, jak poprzez wywołanie go w standardowej aplikacji *.exe. Idea tych plików jest taka, że właściwie każda aplikacja może z nich korzystać w tym samym czasie. Bibliotekę wystarczy załadować z poziomu naszej aplikacji i zacząć z niej korzystać. Tylko tyle i aż tyle. Rodzi to wiele możliwości. Od używania jednego pliku *.dll przez dziesiątki aplikacji, po możliwość tworzenia w ten sposób pluginów dla naszych programów. Prawda, że brzmi ciekawie?

Jak stworzyć własny plik dll przy użyciu Visual Studio?

Jest to banalnie proste… Wystarczy stworzyć nowy projekt typu Class Library.

a

Po jego utworzeniu przywita nas puste rozwiązanie z jedną klasą nazwaną po prostu Class1:

Oto i nasza biblioteka klas. Możemy dodawać tu dowolną ilość klas, odwoływać się do innych plików dll – po prostu tworzyć kod. Do wszelkich zawartych tutaj klas/metod/właściwości będziemy mieli dostęp z poziomu naszej aplikacji. Oczywiście pod warunkiem, że będą one publiczne 😉

Dobrze… Czas chyba na jakiś przykład. Dodajmy do tej klasy jakąś metodę i właściwość:

Całość skompilujmy. Po otrzymaniu wynikowego pliku dll możemy stworzyć drugi projekt. Tym razem będzie to projekt typu Console Application.

Używanie plików dll w projektach

Dostać się do wnętrza naszego pliku dll możemy na dwa sposoby. Pierwszym jest dodanie własnego pliku do projektu jako referencji:

aa

aa

aa

Po wykonaniu tej operacji możemy już spokojnie korzystać z dobrodziejstw, jakie udostępniają nam klasy zawarte w naszym pliku 😉

Zanim jednak wywołamy jakiekolwiek instrukcje z naszej dll’ki, warto sprawdzić czy istnieje. W przeciwnym wypadku aplikacja się po prostu wysypie. Jednak to jest raczej do przewidzenia.

Drugim sposobem na załadowanie i używanie plików dll jest ładowanie ich bezpośrednio z poziomu kodu. Jedyne czego będziemy do tego zadania potrzebowali to znajomość lokalizacji takowej dll’ki. To otwiera wiele możliwości. Między innymi możliwość pisania w ten sposób pluginów do aplikacji. Poprzedni sposób to uniemożliwia – żeby dołączyć jakiś plugin musielibyśmy przekompilowywać cały program. Kompletnie bez sensu 😉 Przejdźmy, więc do rzeczy:

Powyższy kod ładuje tą samą bibliotekę tylko i wyłącznie na podstawie jej lokalizacji. Środowisko nie wie jakie metody można z tej biblioteki wywołać, nie wie jakiego są typu i jak się nazywają. Tutaj wchodzimy my – musimy wiedzieć co konkretnie chcemy wywołać. Dodam jeszcze, że do załadowania pliku dll, wymagana jest ścieżka bezwzględna.

Ładowanie bibliotek pochodzących z „cudzego komputera”

Próbując załadować plik dll pochodzący z źródła innego niż twój komputer możesz napotkać na problem z wyjątkiem:

System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

Jak go rozwiązać? Wystarczy wejść we właściwości pliku dll, który chcemy załadować i wybrać „odblokuj”

a

Jednak jest to rozwiązanie dosyć… niewygodne. Szczególnie jeżeli z aplikacji ma korzystać większa ilość mniej świadomych użytkowników. Co zatem zrobić? Zauważyłem, że problem występuje tylko w przypadku przenoszenia pliku dll pomiędzy komputerami, kiedy ten nie jest spakowany lub jest spakowany do archiwum zip i zostanie wypakowany poprzez windowsowe narzędzie. W przypadku rozpakowania pliku przez inne oprogramowanie (7zip, WinRAR) problem nie występuje. Jaki z tego wniosek? Rozpowszechniać program z dll’kami w archiwum rar/7z – ich nie da się rozpakować windowsowym narzędziem. Problem, więc sam się rozwiązuje. Oczywiście można zrobić też najzwyklejszy w świecie instalator.

Z postaw to byłoby chyba na tyle. Jak zwykle zachęcam do zadawania pytań i zgłaszania uwag w komentarzach 🙂

859 total views, 1 views today

2 przemyślenia nt. „Biblioteki łączone dynamicznie (DLL)

    • Interfejsy… Faktycznie, znakomicie się tu sprawdzą. Tak to jest, jak się czegoś praktycznie nigdy nie używa – zupełnie o nich zapomniałem.

      Niemniej masz rację, to będzie świetne rozwiązanie 😉

Możliwość komentowania jest wyłączona.