[C#] Jak stworzyć własne walidatory w C# i sprawdzić poprawność .dll?

Mam takie małe pytanko, potrzebuję informacji na temat stworzenia własnych walidatorów, a dokładnie chodzi mi tylko o wiedzę teoretyczną (choć praktyczna też by mi się przydała). Nie bardzo w sumie ogarniam na czym polegają te walidatory, poczytałam w necie co nie co na ten temat, ale chyba potrzebuję aby ktoś mi to w sumie przedstawił "łopatologicznie". Podjęłam się próby napisania klasy w C# która "powinna" walidować dokument, ale w sumie nie wiem czy to robi... wiem że chyba powinno się wyedytować plik .config w edytorze Enterprise Library, ale też nie wiem jak to do końca zrobić... W skrócie - co z czym sie je aby działało, czy można sprawdzić w jakiś sposób poprawność tworzonej .dll? Byłabym wdzięczna za jakieś łatwe przedstawienie mi tego... lub może posiadacie jakieś przykłady, które pomogą mi to zrozumieć...

Aplikacje typu WinForms czy ASP.NET??
Co rozumiesz przez pojęcie "walidator"?? Podaj jakiegoś linka gdzie o tym czytałaś...

Co masz przez to na myśli?? DLLka albo się skompiluje, albo nie jak się skompiluje - jest poprawna, jak nie - to nie jest

Czytałam o walidatorach na http://msdn.microsoft.com/en-us/library/ff664694(v=PandP.50).aspx
Chciałam stworzyć walidator dedykowany (a na stronce przedstawione są walidatory standardowe) jako ClassLibrary i wrzucić do katalogu z aplikacją WinForms, problem który też istnieje polega na tym, że chce stworzyć dodatkową funkcjonalność do programu księgowego (co wiąże się z tym że sama go nie pisałam ;P) polegającą na poprawnym zatwierdzeniu dokumentu. Nie wiem w sumie czy dobrze rozumiem całe to pojecie walidatorów i tego co chce zrobić, jedynie co wiem to na pewno da rade to jakoś zrobić i chciałam się podjąć takiej próby, tylko czy dobrze się do tego zabieram...

Co do kompilacji .dll jedynie co, to chyba można wykonać bilda, który albo się wykona albo nie... ale nie pokaże mi za pomocą "breakpointów" co się w niej dzieje, wiec pewnie pozostaje mi jedynie tworzyć taką .dll na podstawie prób i błędów, myślałam, że może można śledzić kod takiej .dll tak samo jak przy tworzeniu własnych aplikacji winForms czy asp... prawdę mówiąc nigdy nie tworzyłam własnych .dll więc może stąd wynika moja niewiedza

A, o takie coś chodzi... Ambitne podejście do tematu
Niestety, w tej kwestii nie pomogę, bo pierwszy raz widzę coś takiego na oczy.

Ja do swoich projektów na potrzeby walidacji danych wprowadzanych przez użytkownika do kontrolek opracowałem własną klasę - zwykła klasa z kilkoma publicznymi metodami, do których przekazuję jako parametry: kontrolkę, error providera (z którego zwykle korzystam do sygnalizacji że coś jest nie tak) oraz ewentualne zakresy walidacji. Np. taka metoda sprawdza mi, czy w kontrolce jest liczba typu integer z wybranego zakresu od... od...:

Cała logika jest zaszyta w metodzie - sama sprawdza typ kontrolki, wypakowuje z niej wartość, za pomocą TryParse sprawdza poprawność typu, a potem resztę wg założeń, np. zakres. Jeżeli coś pójdzie nie tak - ustawia stosowny komunikat error providera i zwraca false.

Podobnych metod mam kilka, do najczęściej spotykanej walidacji (string o określonej długości, prawidłowa liczba z przecinkiem, data, zakres dat od... do...) - i przed zatwierdzeniem dokumentu wywołuję metodę, która wykorzystując wspomnianą klasę sprawdza, czy poszczególne kontrolki zawierają prawidłowe typy danych. Jeżeli tak - puszcza dalej, jeżeli nie - każe poprawić źle wprowadzone dane. Jak potrzebuję jakąś niestandardową walidację (np. czy liczba A jest wielokrotnością liczby B), po prostu dopisuję kolejną metodę. Myślę że za jakiś czas nazbieram tych metod tyle, że da się to przekompilować na dll'kę i załączać ją do nowych projektów, póki co to po prostu osobna klasa.

Ad. 2. Kod dll'ki też można śledzić podczas tworzenia, tylko musisz utworzyć sobie np. dodatkową formę, która będzie wywoływała funkcje z tej dll'ki po kliknięciu przycisku. Najprościej chyba wstawić ją do tego samego projektu co tworzona dll'ka (oczywiście projekt musi być wtedy typu Windows Application albo Console Application), i tak naprawdę tworzysz zwykłą klasę, nie dll'kę. Jak już wszystko gra i jest gotowa - usuwasz formę i wszystkie inne niepotrzebne referencje, zmieniasz typ projektu na ClassLibrary i kompilujesz do czystej dll'ki.

Drugi sposób, to w danym Solution utworzyć dwa projekty:
- pierwszy typu ClassLibrary z dll'ką,
- drugi typu WinForms lub Console Application do testowania.
W tym drugim projekcie musisz dodać referencję do projektu dll'ki (zakładka Projects przy dodawaniu referencji), podobnie jak dodajesz referencje do zewnętrznych bibliotek. Projekt z formą lub konsolą musisz ustawić jako startowy, ewentualnie pogrzebać z opcjami w Properties dla Solution (w drzewku masz tam Startup Project) tak, żeby po wciśnięciu F5 uruchamiało formę / konsolę. VS jest na tyle sprytny, że jak ustawisz brakepointa w projekcie dll'ki, to przechwyci go, nawet jeśli został on wywołany z innego projektu.

A, i zarówno dll'ka jak i forma/konsola testowa, najlepiej żeby miały ustawiony tryb Debug. Potem, jak już kompilujesz finalnie dll'kę, możesz zmienić jej tryb na Release.

Dzięki, co prawda okazało się, że to co chciałam zrobić jest możliwe jedynie przez rozszerzenie serwisu a nie za pomocą walidatora, ale przynajmniej dowiedziałam się o co w tym chodzi

Dwa słowa celem uzupełnienia odpowiedzi kolegi wyżej :> do walidacji można też użyć wyrażeń regularnych - przestrzeń nazw:

W ASP.NET MVC mamy do jeszcze do dyspozycji przestrzeń nazw

Tak jak pisałam wcześniej musiałam to rozwiązać przez rozszerzenie serwisu. Dzięki za pomoc