UserControl ale nie w dll

0

Witam, opis sytuacji
Mam swój komponent który dziedziczy po UserControl. Komponent stworzony w innym osobnym projekcie którego wynikiem jest biblioteka dll i zarejestrowana GAC. Dodałem sobie ten komponent do toolbox-a i wszystko fajnie działa tylko mam jeden problemik otóż jak kompiluje program który wykorzystuje ten komponent to w folderze wynikowym pojawia mi się program (.exe) oraz biblioteka (dll) z tym komponentem. Czy da się zrobić tak aby ta dll nie była dołączana do tego projektu, a dokładnie aby ktoś kto otrzyma ten programik nie mógł wykorzystać tego mojego komponentu instalując sobie go w VS.
Czy jest inny sposób aby nie korzystać z instalatora który wrzuci tą dll do folderów systemu?
Macie jakiś pomysł aby zabezpieczyć się przed ewentualnym podebraniem :) komponentu. Programik który napisałem muszę zaprezentować i dać żeby się nim pobawili ale nie chce aby podebrali mi komponentu ;)

Używam VS 2008 express

0

A nie możesz po prostu tej swojej UserControl wrzucić do projektu aplikacji?

0

Dzięki za odpowiedź
Rozumiem ze chcesz aby przenieść wszystkie źródła do projektu aplikacji?
No rozwiązanie niby dobre tylko doraźne moim zdaniem. Jaki jest sens wtedy pisania komponentów które możesz wykorzystywać w innych aplikacjach? Za każdym razem przenosić źródła?
Myślałem nad jakaś metodą autoryzacji aplikacji która chce skorzystać z komponentu ale to już chyba przerost formy, dlatego zapytałem tutaj.
Ma ktoś jakieś inne propozycje.

0

może coś w stylu messageboxa z komunikatem o korzystaniu z wersji trial komponentu przy starcie programu lub co jakiś czas..

3
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:)

0

Dzięki wszystkim za odpowiedzi a w szczególności dzięki quetzalcoatl
quetzalcoatl patrzyłem na ten sposób z licencją no ciekawe.
Jeśli chodzi o Reflector'a to jak w każdym języku i środowisku nie ma rzeczy niemożliwych do rozgryzienia, jest to tylko kwestia czasu i kasiory :)
Jeszcze raz dzięki za odpowiedzi

1 użytkowników online, w tym zalogowanych: 0, gości: 1