Konfiguracja aplikacji .net core

Konfiguracja aplikacji bez ifowania w kodzie? Tak, wszystko dzięki dobrym i mądrym „chłopakom” z Microsoftu. Czytam o dotnet core oraz o tym jak można dobrze ustawić konfiguracje aplikacji od środowiska na którym zostanie uruchomione i chce się z wami podzielić tą wiedzą, uważam że pomoże ona wam (mi też) w lepszym i czytelniejszym przygotowywaniu  konfigurowaniu.

Poniżej kilka przykładów na to jak do tego tematu podejść. Continue reading

Co załadowane nie jest nie pisze się w rejestr

Mówili mi ludzie, czemu sam rejestrujesz zależności w autofacu, skoro można skorzystać z konwencji, sam wszystko rozpozna, wykryje co masz załadowane do pamięci i z tego rozkmini. Jak się domyślacie wpis ten wziął się stąd, że nie zawsze tak się dzieje.

Otóż tak stworzona rejestracja czasem powoduje problemy:

Problemy wygladają tak:

None of the constructors found with ‚Autofac.Core.Activators.Reflection.DefaultConstructorFinder’ on type ‚IsThereAnyNews.Mvc.Controllers.HomeController’ can be invoked with the available services and parameters: Cannot resolve parameter ‚IsThereAnyNews.DataAccess.IRssChannelsRepository rssRepository’ of constructor ‚Void .ctor(IsThereAnyNews.Services.IUserAuthentication, IsThereAnyNews.Services.ILoginService, IsThereAnyNews.Services.ISessionProvider, IsThereAnyNews.DataAccess.IRssChannelsRepository)’.

Brak zarejestrowanej implementacji klasy, ale jak to nie ma skoro napisałem wcześniej żeby się automagicznie samo się. Na szczęście na stackoverflow są mądrzy ludzi i w dziesięć minut mi to wytłumaczyli.

AppDomain.CurrentDomain.GetAssemblies() call. According to MSDN the method:
Gets the assemblies that have been loaded into the execution context of this application domain.

Czyli co jakiś czas (najczęściej po restarcie IIS), projekt z MVC się ładuje, ale nie załadował wszystkich referencji jeszcze, więc nie podczas rejestracji autofaca ten wykrył interfejsów oraz implementacji, przez to nie zrobił pełnej rejestracji.
I uwaga, po mojemu to tak, że jeśli nie ma interfejsów, to nie trzeba szukać do nich implementacji, a skoro ich (tych interfejsów) nie ma to nie ma też błędów czy ostrzeżeń. I dalej autofac się robił i rejestrował, teraz gdy generowane było żądanie http do kontrolera, ten przychodził do autofaca a ten naburmuszony mówił: „jaka implementacja? jaki interfejs? gdzie mi tu z łapami! dawaj domyślny konstruktor! Jak to? Nie masz?! Gleba i EXCEPTION!” – resztę historii już znacie, żółty ekran na prodzie – fak je.

Ale żeby nie płakać, to rozwiązanie jest takie proste:

Tutaj należy zwrócić uwagę na linię (@5) gdzie ładowane są referencje. Taki sposób pobierać ma listę wszystkich referencji, najwyraźniej nawet tych jeszcze nie załadowanych. A zatem, nawet jeśli moje *services czy *repositories nie będą załadowane, to będą widnieć na liście referencji, a ta zostanie przekazana do autofaca do skanowania i na pewno zostanie wczytana, co wreszcie spowoduje że nie będzie miauczeć że nie zna typa czy jego implementacji. Oddech i dziękuje.

Entity framework – obowiązkowa minimalna konfiguracja #dajsiepoznac

Lazy loading

Kiedy korzystamy z EF należy pamiętać o tym, aby zawsze wyłączyć leniwe ładowanie (lazy loading) w przeciwnym wypadku za każdym razem gdy będziemy sięgać po dane które leżą w innej tabeli niż ta, która została początkowo zaciągnięta z bazy danych EF zrobi to za nas. Brzmi fajnie, ale gdy pomyślicie że taka operacja może wykonać się w pętli, pomysł szybko przestaje być tak miły. N wykonań pętli N pojedynczych zapytań do bazy danych. Minusem wyłączenia lenia w EF jest to, że jeśli nie powiemy wcześniej EF że chcemy wykonać operację JOIN nie będziemy mieli dostępu do danych z innej tabeli.

Kod wygląda tak, pierwsze zapytanie bez, drugie z instrukcją JOIN

Linia (@22) wyłącza lazy loading. Linia (@12) wyciąga z bazy tylko osoby, jesli pole Properties będzie nullem. Linia (@13) wyciąga z bazy osoby oraz wykonuje operację JOIN, lista cech w osobie zostanie wypełniona pasującymi wartościami. Ostrzeżenie: ponieważ w przykładzie wywołanie jest jedno pod drugim, gdy postawi się breakpoint po obu (@14), referencja osoby zostanie zaktualizowana. Może się więc okazać, że w przypadku p1 oraz p2 pola properties będą już ustawione. Zalecam w przypadku samodzielnego sprawdzania przykładu, postawić breakpoint odpowiednio w liniach @12 oraz @13 i podejrzenie wartości property.

Logowanie

Często pojawia sie problem logowania zapytań które generuje EF, zawsze szukałem, paczek, rozwiązań czy gotowych bibliotek. Aż pewnego pięknego razu na SO znalazłem odpowiedź, która wygląda tak jak w linii 21. Najprościej jak się da, dopinam się do wewnętrznego logera oraz wypisuje na Debug.Trace informacje o zapytaniach, wyglądają one tak:

Widać tam wywołania dwóch zapytań (@12i @13) prosty oraz ten z JOIN, widoczny jest czas potrzeby na wykonywanie operacji jak i informacje o rozpoczęciu i zakończeniu połączenia. Wszystko co potrzeba aby sprawdzić czy zapytanie zostało wygenerowane w akceptowalny przez nas sposób – me gusta!

Tajne wpisy w app.config #dajsiepoznac

Jeśli nie chcesz mojej zguby…

Jeśli nie chcesz swojej zguby, nie wrzucaj do repozytorium sekretów swojej aplikacji. Można to osiągnąć w kilku prostych krokach, wystarczy że stworzysz w VS osobny plik z konfiguracją np. „secrets.config„, który może wyglądać tak:

Następnie zaciągniesz go w głównym web.configu w taki sposób:

W VS należy mieć go dodanego do projektu, właściwości ustawione powinny być na content i no-copy, tak samo jak w przypadku web.config. Od teraz zawartość secrets będzie wstrzykiwany do web.config podczas uruchomienia.
Jeszcze tylko w gicie warto dodać go do ignorowanych plików i można spokojnie wrzucać kod na serwer bez potrzeby pamiętania, aby zawsze odznaczyć secrets.config z listy plików.

Natomiast warto pamiętać, aby po każdej zmianie zrobić sobie backup. Tak aby nie stracić go przez przypadek.

Bardzo prost logi w asp mvc

Nigdy nie ciągnęło mnie do logowania. Zawsze miałem problem z określeniem poziomu na jaki zasługiwała dana informacja, a może ostrzeżenie. Czy to błąd, czy to już krytyczny błąd. Jak mam to dobrze zalogować. Czemu te okrutne logi tak strasznie mieszają mi się w aplikacje, wtedy jeszcze nie znałem podejścia AO.
Pisanie własnego logera też nigdy nie sprawiało mi przyjemności, zawsze czułem że robię coś nie tak. Jak już poznałem nloga czy log4net i próbowałem go zaprząc do aplikacji, to konfiguracja jednego i drugiego też zawsze szła po gruzie. Summa summarum życie szło powoli, a z logów nie korzystałem i nadal nie najczęściej nie korzystam (czasem żałuje). W projektach dziedziczonych logowanie już jest i wszystko jest już ustawione i postanowione i tak ma być – a że wszyscy referują do logera, to też jest „spoko”. Ale nie o tym miałem pisać. Często się zdarza, że mi tego brakuje i wtedy albo na chwilę dodaje logowanie, a potem usuwam, a potem jak znowu potrzebuje to usuwam, albo zostawiam bo może kiedyś mi się przyda i strasznie mnie to wkurza. Dlatego gdy odkryłem tracing musiałem się tym podzielić. Otóż taram taram – ( dla części z was oczywista oczywistość), w asp.net mvc jest wbudowane proste tracowanie, które spełnia moje podstawowe wymagania i włącza się to niebotycznie prosto.

Wystarczy tyle, żeby móc przejść na stronę myWebApp/trace.axd i móc oglądać szczegóły request’ów, które otrzymuje aplikacja. Jest tam więcej przełączników, które można poznać na internecie, np. na msdn.
Oto co dostajemy za darmoszke:

Faking hel – i to praktycznie za darmo?! Oczywiście możemy dorzucać trochę swojego logowania jeśli trzeba robi się to przez taką linikę kodu:
HttpContext.Trace.Write(„Category”, „Text to log”);
Dodatkowe wpisy znajdą się w sekcji TraceInformation. Dla mnie bóstwo. Włączyć, dodać kilka linijek w kodzie na szybko, sprawdzić i wywalić.
Podobną funkcjonalność można uzyskać przy pomocy Glimpse – też wypas. Jeszcze inna opcja to F12 developers tools w każdej przeglądarce, ale tam nie dostaniemy informacji o stanie serwera. No i tyle, krótko i na temat.