chemik napisał(a)
a dokładnie aby ktoś kto otrzyma ten programik nie mógł wykorzystać tego mojego komponentu instalując sobie go w VS
W wielkim skrócie, "nie da się".
Dokładnie, przynamniej da się albo niełatwo, albo niecałkiem.
W "prostym podejściu", nie ważne czy wciśniesz ten komponent do DLL, czy do głównego EXE, ktoś kto położy ręce na tym pliku, będzie w stanie ten plik podpiąć poprzez "add reference" do swojego projektu. w tym momencie, jeśli skonfiguruje sobie Toolbox odpowiednio, komponent pojawi mu się w Designerze.
Komponent NIE pojawi się w Designerze, jeśli ... nie będzie komponentem, czyli jesli nie będzie subclass'ą typu UserControl, Control, Form, Component itp. Po skonczeniu swojej kontrolki, mozesz ja rozbic na czesci, wystawic fabryke ktora bedzie ja budowac, i korzystac z fabryki.. upierdliwe, szkoda zachodu, strasznie utrudni Ci to pracę, ale w Designerze sie nie pojawi. Jednak i fabryka, i kawałki składowe kontorlki i tak beda dostępne dla kogos kto sobie owo "add reference" zrobi.
Mozesz probowac "twardo" ukryc komponent/jegokawałki/fabryke poprzez zwykłe "internal" zamiast "public", albo wpuścić je "niżej", jako innerclass, z "private/protected". Ktoś kto sobie zrobi "add reference" nie bedzie mial prostego dostepu do takich klas. To ci jednak utrudni pracę i, o ile dobrze pamiętam, jeśli źle to wykonasz, to ogóle może uniemożliwić funkcjonowanie kontrolki. Jeżeli wykonasz to dobrze, i wszystko będzie działać, to ktoś i tak może to wyciągnać poprzez Reflection, jeśli będzie wiedział gdzie szukać.
Możesz ukrywac elementy class/method/property rowniez "miękko" na bezczelnego poprzez:
- DesignerSerializationVisibilityAttribtue
- EditorBrowsableAttribute
- DesignTimeVisibleAttribute
- Browsable/Bindable/..
one pozwalają określać, ktore rzeczy mają byc widoczne np. w podpowiedziach Intellisense, a ktore maja byc ukryte. Z Browsable/Bindable nalezy uwazac, gdyz ono steruje duza iloscia mechanizmów we Forms'ach. Mimo iż dana rzecz będzie ukryta, I TAK bedzie mozna z niej korzystac. Kod jej uzywajacy bedzie sie kompilowal wprost. po prostu beda niewidoczne, ale beda normalne. Noob je przegapi.
.Net Forms ma pewne mechanizmy licencjonowania, spotkasz je najszybciej chyba bawiąc się darmówkami pakietu kontrolek DevExpress.. one na pewno z niego korzystaly kiedys, nie wiem jak teraz. Łatwo to poznac, bo z DLLkami/EXEkami dostajesz wtedy plik(i) .LICX i bez tego one po prostu odmowią wspolpracy (tzn. np. dadzą się add-reference do projektu, ale potem przy uruchomieniu programu zaprotestują). Testy licencji i odmawianie wspolpracy musisz generalnie sam w kodzie umiescic, ale jest to dosc szablonowy kod, później kodzik testu wstrzeliwujesz w N wybranych miejsc w swoim kodzie. Początek historyjki o LICX'ach znajdziesz tu http://blogs.msdn.com/b/jnak/archive/2006/07/24/670621.aspx Mozliwe ze w .Net4 jest juz cos nowszego w tym temacie, nie wiem..
itp itd.. to przyklady, lista nie jest wyczerpana.
Jesli w koncu na zabezpieczenie wymyslisz jakis sensowny sposob, albo poskladasz kilka roznych mechanizmow utrudniajacych lub u-upierdliwiajacych i naprzykrzajacych sie, ale Twoja aplikacja bedzie sobie z komponentu w jakis sposob swobodnie korzystac, osoba ktora nie moze sie do tego czegos dostac w koncu sie wnerwi i włączy Reflector'a, skopiuje Twoj kod stworzenia/użycia/(..) tegoz komponentu do swojego projektu i tyle widzieli zabezpieczenia. Kod mozna "unieczytelniac" za pomoca narzedzi typu Dotfuscator, Reflector wtedy albo calkiem "odpadnie", albo pokaze trudne do zrozumienia smieci. Niestety, albo na szczescie, zalezy od czyjej strony patrzec, jesli sie znajdzie bardzo kumaty i uparty czlowiek, to jesli Twoj program dziala, to on jednak i tak da rade sie do tego komponentu dostac. Im bardziej jest on "komponentowy", tym latwiej. Niemniej, im wiecej metod ochrony polaczysz, tym wiecej odsiejesz ludzi bedacych w stanie to zrobic:)