R# – Fajny feature

Dziś znalazłem fajną rzecz dostępną w R#. Być może jest to coś oczywistego, o czym wszyscy (korzystający z tego dodatku) wiedzieli, a może nie. Piszę, bo już wielokrotnie w przeszłości okazywało się, iż rzeczy najprostsze są najmniej oczywiste.

Po zaznaczeniu tej opcji w ustawieniach, na dole w status barze VS pojawia nam się znacznik ile pamięci nasze VS nasz R# zużywa.

Powie ktoś – nic takiego. Racja. Jednak najlepsze pojawia się, gdy klikniemy na tą wartość prawym przyciskiem myszy i wybierzemy Collect Garbage.

 
Zostanie wtedy zwolniona pamięć nieużywana przez VS R#. Dla mnie bomba. Szczególnie przydatne w dużych projektach, gdzie komunikat przy buildzie EndOfMemoryException nie jest aż tak niespodziewany.

Nowości w starym, dobrym ASP.NET

Z racji pojawienia się nowego VS 2010 postanowiłem pobawić się nim i zobaczyć zobaczyć co oferuje nam stare, dobre ASP.NET w wersji 4.0.

Wywalmy tabelki

ASP.NET ma wiele dobrych i użytecznych kontrolek, które znacząco przyśpieszają proces tworzenia nowych serwisów opartych na tej technologii. Mankamentem ich, w poprzednich wersjach było to, że nawet jeśli dawały możliwość wstawienia swojego, ładnego kodu HTML w środku to opakowywały to wszystko na zewnątrz piękną tabelką <table></table>.

W nowej wersji ASP.NET możemy kontrolować to czy tabelka zostanie renderowana czy też nie. Pojawiła się nowa właściwość RenderOutputTable, która to kontroluje. Dzięki takiemu podejściu (a nie np. wywaleniu ich bez możliwości kontroli), możemy stopniowo używać to w naszym kodzie, tak aby wyeliminować tabelki zachowując nadal poprawne renderowanie się w innych miejscach.

Automatyczna zamiana tokenów HTML

Kolejną zmianą jaka została wprowadzona to, możliwość automatycznego zamieniania tagów HTML a ich bezpieczne odpowiedniki. Jeśli czasem używasz <%= %> do wyprowadzania informacji na stronie musisz pamiętać, iż stwarza to potencjalne niebezpieczeństwo, iż wyprowadzisz coś co może zostać zinterpretowane jako poprawny kod HTML. Aby tego uniknąć, użyj notacji <%: %> ( dwukropek zamiast znaku równości) a wszelki tekst zostanie odpowiednio zamieniony przed wyprowadzeniem na ekran.

Te nieszczęsne i długie IDki

Długie i czasem trudno przewidywalne ID elementów to był problem w poprzednich wersjach ASP.NET. Powodowało to utrudnienia w pisaniu kodu JS, który by do tych elementów mógł się odwołać.
W ASP.NET 4 wprowadzono mechanizm kontrolki tego jak ID są generowane. Mamy dostępne 4 tryby: Inherit, AutoID, Predictable oraz Static. Więcej do poczytania na MSDN - ClientIDMode Enumeration.

 

Podsumowanie

Fajnie, że ASP.NET ewoluuje. Na pewno jest więcej zmian w nim, niż tylko te powyższe. Widać jednak po tych wyżej opisanych, iż idą w stronę tego, aby aplikacji napisane w ASP.NET nadal były pisane szybko i aby kod HTML, który uzyskujemy był satysfakcjonujący. Nie zawsze potrzeba mieć 100% kontrolkę nad tym jaki kod jest generowany.

Podzielony web.config - przypadek użycia

Już jakiś czas temu pisałem o możliwości użycia configu podzielonego na wiele plików. Dziś pokaże jeden z przypadków użycia tej funkcjonalności.

Często zdarza się tak, że podczas rozwoju aplikacji używamy naszej lokalnej bazy danych. Czasem jednak chcemy aby inne osoby zobaczyły postęp prac. Aplikacja wrzucona na serwer zapewne będzie miała inny connection string niż ten lokalny. Oczywiście możemy mieć oba connection stringi w pliku web.config i je komentować odpowiednio, ale ponieważ trzeba o tym pamiętać staje się to trochę niewygodne.

Tak więc staremu rozwiązaniu mówimy nie.

Jak to można zrobić ładniej? Możemy wykorzystać fakt, iż web.config umożliwia nam wydzielenie pewnych fragmentów do osobnych plików.
W głównym web.configu, umieśćmy tylko sekcję connectionStrings i dodajmy odwołanie do pliku zewnętrznego.

<connectionStrings configSource="connectionStrings.config">

No i oczywiście utworzyć go. W środku dodajemy nasz lokalny connectionStrings.config.

<?xml version="1.0"?>

<connectionStrings>

  <add name="ApplicationServices"

      connectionString="Server=.\SQLExpress;Database=;Trusted_Connection=True;"

      providerName="System.Data.SqlClient"/> 

</connectionStrings>

Pozostaje nam jeszcze wyłącczyć ten plik z projektu, aby nie był kopiowany na serwer przy Deploy'u. Oczywiście na serwerze tworzymy taki sam plik z connection stringiem wskazującym na bazę danych na serwerze. I działa.

W ASP.NET 4.0 zmieni podejście do tego wprowadzając transformacje, które będziemy mogli wykonywać na web.configu. Do tego czasu pozostaje nam powyższa metoda lub ... no właśnie. Być może jest jakiś inny, lepszy sposób na osiągnięcie tego samego o którym nie wiem? Zapewne jest. Jeśli go znasz napisz w komentarzu...

Pasja - to co wyróżnia

Choć dawno już nie pisałem nic technicznego, to dziś także mało techniczny post. Zapewne już wszyscy widzieli film, który pojawił się na Channel9 dotyczący historii Visual Studio (jeśli nie to nadrób to szybko :)).
Ja umieszczam linki u siebie na blogu, abym w przyszłości nie musiał ich długo szukać.

Co mi się tak w nich podoba? Wszechobecna pasja. Pasja z jaką wypowiadają się bohaterowie tego filmu jest niezwykła. Z przejęciem opowiadają o tym co miało miejsce dawno temu i nadal są tym podekscytowani. Prawdziwe z nich geeki :)

Ja sam uważam, iż to co robię jest więcej pasją niż tylko zajęciem, które wykonuję. I mam nadzieję, że ja także po tylu latach spędzonych przy rozwijaniu oprogramowania będę nadal tak samo pasjonował się tym co robię jak to jest obecnie.