Impersonacja w kodzie w .NET

Ostatnio dość długo szukałem sposobu aby zaimplementować model uprawnień dla aplikacji .NET umożliwiający jej dostęp do wielu lokalizacji sieciowych które mogą potrzebować różnych poświadczeń. Tradycyjne podejście (impersonacja) działa, ale można podać tylko jeden konkretny profil pod ... [Więcej]

AngularJS - generyczna obsługa błędów

W aplikacjach webowych nieodzownym stałym elementem jest obsługa błędów. Dla "normalnej" aplikacji (np. MVC) sprawa jest w miarę prosta, możemy wyjątki przechwycić po stronie serwera, umieścić w modelu (jako model errors) i później na widoku wrzućić w jakieś ValidationSummay. W przypadku aplikacji typu SPA (Single Page Application) sprawa robi się trochę bardziej skomplikowana ponieważ dysponujemy jedną stroną html której zawartość "podmieniamy". Oczywiście możemy przy każdym requeście do serwera sprawdzać kod odpowiedzi i wyświetlać jakiś stały element DIV z odpowiednim komunikatem ale jest to wielce niewygodne, a poza tym kopiowanie tej samej logiki obsługi błędu (nawet wydzielonej do osobnego modułu) nie jest dobrym rozwiązaniem architektonicznym. Jeżeli używamy angular-a jako framework javascriptowy możemy skorzystać z jednego z jego dobrodziejstw i przechwycić response jaki dostajemy ze standardowego modułu angular-resource. Angular-resource jest to moduł ułatwiający komunikację REST-ową z serwerem, możemy tam wysyłać zapytanie typu query (dla listy elementów), get (dla konkretnego elementu), update i delete. Przykład wykorzystania tego modułu: [Więcej]

EF - wywoływanie swojej logiki przy konkretnych getterach/setterach na entity

Dzisiaj natrafiłem na następujący problem: potrzebuję wyświetlać na ekranie daty dla użytkowników przekonwertowane na ich strefy czasowe. Każdy użytkownik ma zapisaną w bazie strefę czasową i ustawiam ją przy logowaniu (dla wygody trzymam w User.Identity). Daty w bazie danych są trzymane w formacie UTC. Teraz, chcę aby dla każdego użytkownika daty wyświetlały mu się w jego strefie czasowej. Nie chcę tego robić na poziomie kontrolerów (aplikacja jest w MVC) ponieważ logika tam jest już zakodowana i zmiana jej wymagałaby dużo czasu. Chcę, aby konwersję przeprowadziło za mnie automatycznie EF. Z tym że nie wszystkie property DateTime na encjach powinny być w ten sposób konwertowane - jedynie te które chcę. Po przeanalizowaniu wyników google znalazłem pewien pattern którym chcę się podzielić. W skrócie polega on na utworzeniu customowego atrybutu którym dekorujemy interesujące nas property na encji. Następnie, overridujemy zdarzenie OnMaterializing wywoływane przy utworzeniu obiektu encji i tam przez reflekcję odnajdujemy interesujące nas property i wykonujemy akcję. [Więcej]

Komunikacja pomiędzy procesami za pomocą MemoryMappedFile

Czasami zdarza się, że potrzebujemy wymienić jakieś proste informacje pomiędzy procesami a nie chcemy budować całej infrastruktury komunikacyjnej w stylu WCF, socketów itp. Na taką prostą sytuację wymagającą komunikacji interprocesowej ostatnio natrafiłem.Otóż mam sobie aplikację WPF-ową która działa w Tray-u. Okno główne odpala tylko po kliknięciu na Tray-a. Oczywiście chcemy, żeby w danej chwili uruchomiona była tylko jedna instancja takiej aplikacji, więc zrobiłem zabezpieczenie na Mutexie (działa to w ten sposób, że aplikacja próbuje utworzyć nowy obiekt typu Mutex, a w przypadku kiedy już taki istnieje to znaczy że mamy odpaloną inna instancję aplikacji i tę należy zamknąć). I działa to OK, tylko problem w tym że jeśli aplikacja wisi tylko w Tray-u i ktoś klika na ikonkę aplikacji to nic się nie dzieje (nie otwiera nowego okna ani nie pokazuje starego). A chcemy, żeby ten "drugi" proces nim zostanie zamknięty wymusił w jakiś sposób otwarcie głównego okienka należącego do "pierwszego" procesu. Prostym i niezwykle wydajnym rozwiązaniem jest użycie w tym przypadku MemoryMappedFile. Należy on do przestrzeni System.IO i pełni dwie funkcje: Zapewnia "obróbkę" w pamięci bardzo dużych plików Umożliwia dostęp do danego obszaru pamięci wielu procesom Nam chodzi oczywiście o to drugie zastosowanie. W moim przypadku rozwiązanie problemu polega na implementacji dwóch kroków: Ustawienie przez proces "zamykany" wartości w pamięci informującej o konieczności uruchomienia okna aplikacji Sprawdzanie przez główny proces wartości tej pamięci i w przypadku zmiany odpalenia okna [Więcej]

Komunikacja dwustronna (duplex) pomiędzy procesami za pomocą WCF

Aby omówić przedstawioną w temacie kwestię opiszę krótko projekt który obecnie realizuję. Otóż jest to prosty system do automatycznej aktualizacji aplikacji. Przez weba można załadować paczkę instalacyjną, natomiast po stronie klienta działa usługa Windows Service mająca za zadanie ściągać tę paczkę i ją zainstalować. Stworzyłem również proste GUI w postaci aplikacji WPF-owej dla klienta, które komunikuje się z usługą po WCFie za pomocą named-pipes. Początkowo zamierzałem wszystkie wywołania zrobić synchronicznie i tak też zacząłem implementację: ściąganie listy aktualizacji i zarządzanie konfiguracją jest zrealizowane przez synchroniczne wywołania realizowane przez specjalnie tworzony do tego BackgroundWorker (żeby nie blokować głównego wątku GUI). Niestety, takie podejście nie sprawdza się w następnym zadaniu które chciałem wykonać, a mianowicie chciałem żeby usługa na bieżąco informowała GUI o postępie wykonywanych zadań. Czyli, żeby na GUI ładnie wyświetlała się lista aktualizacji a przy nich stan: "oczekująca", "w trakcie instalacji" itp. W takim podejściu model synchroniczny "wysiada", bo żeby komunikacja była płynna należałoby co kilkaset milisekund odpytywać usługę o to co się dzieje (tworząc za każdym razem oczywiście osobny wątek do obsługi!) co oczywiście wydajnościowo "nie wydoliłoby". Jednym sensownym rozwiązaniem jest asynchroniczna komunikacja dwustronna - klient zgłasza się, że chce otrzymywać informację od usługi a usługa bezpośrednio komunikuje się z nim tylko w momencie kiedy ma coś ciekawego do powiedzenia. Taka komunikacja jest możliwa w WCF-ie przy zastosowaniu trybu "duplex" i dodatkowo musi być odpowiedni binding (named pipes albo net-tcp). Aby cosik takiego zrealizować należy uskutecznić kilka kroków [Więcej]

Brak możliwości zmiany trybu budowania (Debug/Release) w VS 2010

Dzisiaj tworząc nowy projekt w VS 2010 zauważyłem, że opcja służąca do zmiany konfiguracji budowania (Debug/Release + docelowa architektura) jest nieaktywna. Dodatkowo, w menu Build "znikła" mi opcja ConfigurationManager służąca do zarządzania konfiguracjami buildów. Co ciekawe, w innym proje... [Więcej]

Problemy z WCF i diagnozowanie za pomocą MS Service Trace Viewer

Usługi WCF są generalnie fajne w użyciu ale mają tę wadę, że jak coś nie działa to często nie wiadomo o co chodzi. Niekiedy komunikaty o błędach potrafią być mało tego że niezbyt pomocne to jeszcze wprowadzać w błąd. Na tego typu komunikat natrafiłem dzisiaj, podczas próby wywołania mojej usługi. Podczas próby wywołanie tejże poleciał taki oto błąd: An error occurred while receiving the HTTP response to http://xx.xx.x.xx:8200/Services/WCFClient.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.] [Więcej]

WatiN i okna dialogowe

Kontyunuując wątek testów automatycznych (rozpoczęty 2 posty temu) muszę stwierdzić, że największym problemem jaki napotkałem podczas implementacji testów była obsługa wyskakujących okienek dialogowych. Oczywiście wzorzec polegający na wrzucaniu na strony mnóstwa Pop-Upów jest już delikatnie mówiąc przestarzały ale wciąż może się zdarzyć. Przykładem takiego zdarzenia jest nasz system, którego logika oparta jest w uproszczeniu na stronie na której znajduję się gromada kontrolek (jedna pod drugą). Obsługa takiej kontrolki polega na kliknięciu przycisku, który wyświetla okienko dialogowe na którym osadzona jest kolejna strona z formularzem. Po jego wypełnieniu okienko jest zamykane a uzupełnione parametry są przekazywane do strony wywołującej. Wymagane jest więc jak widać odpowiednie obsłużenie wyskakującej strony poprzez "dobranie się" do iframe na którym jest osadzona. Poza tym innym często spotykanym rodzajem okienek są Confirm. Są to okienka potwierdzające wykonanie danej czynności ("Czy na pewno chcesz usunąć ten plik?") z możliwymi akcjami "tak/nie". Jest to trochę inny obiekt Javascriptowy niż "normalne" okno i wymaga całkiem innej obsługi. Z innych rodzajów okien można jeszcze wymienić np. Alert ale powiedzmy że jego użycie jest na tyle rzadkie że nie będziemy się nim zajmować. Podsumowując, mamy problem z 2 typami okien: zwykłe okienka z osadzoną treścią oraz okienka typu Confirm. WatiN radzi sobie zarówno z jednymi jak i drugimi. [Więcej]

WatiN - nie zamykanie przeglądarki po każdym teście

W poprzednim poście napisałem, że ostatecznie jako rozwiązanie do testów automatycznych Web w naszym systemie wybrałem WaiN. Zacząłem więc pisać testy i od razu uwidocznił się pierwszy problem. Otóż standardowy wzorzec zakłada odpalenie przeglądarki, zrobienie testu i jej zamknięcie czyli: using (var browser = new IE("http://perszewski.pl")) { // Rób test } W przypadku większej ilości testów każdorazowe odpalanie IE i jego zamykanie zaczyna znacząco wydłużać czas testów. Pasowało więc wymyśleć sposób na to, żeby przeglądarkę odpalić przy pierwszym teście a zamknąć po ostatnim. Rozwiązanie udało się opracować a zacząłem od stworzenia klasy statycznej, która będzie trzymała referencję do mojej przeglądarki: [Więcej]