.:: strefa ::. - Platforma .NET

Źródła niektórych bibliotek .NET Framework będą dostępne

nospam@example.com (Marcin Guzowski) — Fri, 05 Oct 2007 19:31:00 +0200

Microsoft zdecydował się udostępnić kod źródłowy wraz z komentarzami niektórych bibliotek .NET Framework:
- .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text i pewnie jeszcze kilku innych),
- ASP.NET (System.Web),
- Windows Forms (System.Windows.Forms),
- ADO.NET (System.Data),
- XML (System.Xml),
- WPF (System.Windows).

Kod źródłowy zostanie opublikowany na licencji Microsoft Reference License (Ms-RL) wraz z wydaniem .NET Framework 3.5 i Visual Studio 2008. Udostępnienie wyżej wymienionych bibliotek będzie polegać na tym, że w Visual Studio 2008 pobierzemy symbole z jednego z serwerów (pewnie source.msdn.microsoft.com).

Więcej informacji:
ScottGu's Blog: Releasing the Source Code for the .NET Framework Libraries
Microsoft Reference License (Ms-RL)

3 x 2008, czyli premiera Windows Server 2008, SQL Server 2008 i Visual Studio 2008

nospam@example.com (Marcin Guzowski) — Wed, 11 Jul 2007 18:51:00 +0200

Na międzynarodowej konferencji dla przeszło 10 tysięcy firm partnerskich (Worldwide Partner Conference, WPC) w Denver Microsoft ogłosił, że premiery nowych wersji znanych produktów - systemu operacyjnego Windows Server 2008 (codename Longhorn), platformy bazodanowej SQL Server 2008 (codename Katmai) i zintegrowanego środowiska programistycznego Visual Studio 2008 (codename Orcas) odbędą się 27 lutego 2008 roku w Los Angeles. Wydarzenie to zapoczątkuje serię mniejszych konferencji na poziomie krajowym, na których prezentowane będą nowe produkty.

Więcej informacji:
Microsoft PressPass: Microsoft Executives Outline Next-Generation Business Opportunities for Partners With New Products, Tools and Programs

Enterprise Library 3.0

nospam@example.com (Marcin Guzowski) — Fri, 13 Apr 2007 09:21:00 +0200

Na początku kwietnia Microsoft udostępnił trzecią wersję pakietu bibliotek Enterprise Library. EntLib to produkt, który ma ułatwiać developerom implementowanie standardowych funkcjonalności (jak np. cacheowanie) i pomóc w rozwiązywaniu najczęstszych problemów podczas tworzenia dużych aplikacji. Pakiet składa się z 8 bloków podstawowych:
- Caching Application Block
- Cryptography Application Block
- Data Access Application Block
- Exception Handling Application Block
- Logging Application Block
- Policy Injection Application Block
- Security Application Block
- Validation Application Block

EntLib wymaga co najmniej .NET Framework 2.0. Do skorzystania z niektórych grup funkcjonalności (Application Block Software Factory, Validation Application Block WCF i Exception Handling Application Block WCF) potrzebny jest .NET Framework w wersji 3.0.

Więcej informacji i pobieranie:
MSDN: Enterprise Library
Download: Enterprise Library 3.0

Przetwarzanie wyrażeń logicznych

nospam@example.com (Marcin Guzowski) — Sun, 11 Feb 2007 15:02:00 +0100

Ogromna większość technologii programistycznych (języków programowania, języków skryptowych itp.) zakłada specyficzny sposób przetwarzania wyrażeń logicznych zawartych najczęściej w różnego typu instrukcjach warunkowych (IF, WHILE, FOR). Chodzi o to, że zdanie logiczne składające się z kilku wyrażeń, np:

A OR B OR C

jest uwzględniane tylko do momentu, w którym da się określić wartość całego wyrażenia. W powyższym przykładzie moment ten nastąpi już w sytuacji, w której wartość logiczna wyrażenia A będzie prawdziwa (alternatywa jest prawdziwa, gdy prawdziwy jest jeden z jej elementów). Głównym uzasadnieniem takiej obsługi są kwestie wydajnościowe i praktyczne. Opisane podejście do przetwarzania warunków ma jednak szereg konsekwencji, które warto sobie uświadomić. Postaram się zwrócić na nie uwagę bardziej szczegółowo prezentując implementację zasygnalizowanego zagadnienia w kilku środowiskach.

Practical Extraction and Report Language (Perl)

Spójrzmy na poniższy skrypt:

#!/usr/bin/perl

use strict;
use warnings;

my $count = 0;
my $a = 1;

if ($a != 1 and func() == 2) {

}

print $count;

sub func
{
$count++;
return 2;
}

Interesuje nas odpowiedź na pytanie, czy funkcja func() zostanie w ogóle wywołana. Otóż - zgodnie z tym, co napisałem we wstępie - nie zostanie. Nie ma potrzeby sprawdzania wyrażenia z funkcją, gdyż już na podstawie nieprawdziwości wyrażenia $a != 1 (1 != 1) można stwierdzić, że całe zdanie warunku jest fałszywe. Skrypt drukuje więc:

Trzeba o tym pamiętać umieszczając funkcję w logice instrukcji warunkowych.

W rzeczywistości to właśnie opisana obsługa warunków umożliwia stosowanie konstrukcji typu:

if (defined $zmienna and $zmienna == 5) { }

Gdyby za każdym razem przetwarzane było całe wyrażenie, to przy zastosowanym use warnings; dochodziłoby do monitu:

Use of uninitialized value in numeric eq (==) at (...)

zawsze wtedy, kiedy $zmienna byłaby undef.

Platforma .NET (C#)

Obsługa jest analogiczna, poniższy program drukuje 0.

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
   class Program
   {
      public static int count = 0;

      public static int func()
      {
         count++;
         return 2;
      }

      static void Main(string[] args)
      {
         int a = 1;

         if (a == 1 || func() == 2)
        {

         }

         System.Console.WriteLine(count);
      }
   }
}

Podobnie jak w Perlu, w C# (i innych językach .NETowskich) dzięki specyficznej obsłudze wyrażeń logicznych możliwe jest stosowanie konstrukcji:

if (obj != null && obj.property == 2) { }

Różnica między C# i Perlem polega jednak w tym przypadku na tym, że o ile w Perlu użycie niezainicjalizowanej zmiennej skutkuje co najwyżej ostrzeżeniem (warning level), o tyle w .NET użycie nieistniejącego obiektu kończy się rzuceniem wyjątku NullReferenceException().

C/C++

Przykładowy kod w przypadku C:

#include < stdio.h>

void main()
{
   int count = 0;
   int a = 1;

   if (a == 1 || func(&count) == 2) { }

   printf("%d", count);
}

int func(int* pcount) {
   (*pcount)++;
   return 2;
}

Jeżeli w powyższym kodzie pierwsze wyrażenie składowe warunku IF zostanie zmienione na 1 == 1, to większość kompilatorów w ogóle nie uwzględni drugiego wyrażenia alternatywy (z funkcją func()) - skompiluje więc warunek jako zawsze prawdziwy. Można się o tym łatwo przekonać zamieniając dodatkowo nazwę funkcji w warunku na taką, która nie istnieje:

if (1 == 1 || nie_mam_definicji(&count) == 2) { }

W obu przypadkach (zmieniony i niezmieniony kod przykładowy) skompilowany program zwraca 0.

JavaScript

Obsługa jest analogiczna:

<SCRIPT TYPE="text/javascript">

var count = 0;
var a = 1;

function func() {
count++;
return 2;
}

if (a == 1 || func() == 2) { }

alert(count);

</SCRIPT>

Alert prezentuje wartość 0.

Microsoft SQL Server

Jeżeli wywołamy poniższy T-SQL:

SELECT 0/0

SQL Server natychmiast rzuci błędem:

Msg 8134, Level 16, State 1, Line 1
Divide by zero error encountered.

Kiedy jednak dzielenie przez 0 znajdzie się w odpowiednim warunku logicznym:

IF (1=1 OR 1=0/0)
PRINT 'TRUE'

błąd nie występuje, gdyż nie dochodzi do wykonania wadliwego kodu.

O ile w przypadku Perla, C czy C# specyficzna ewaluacja warunków logicznych jest czymś pozytywnym, o tyle w świecie baz danych prowadzi do pewnych niekonsekwencji. Trzeba pamiętać, że SQL Server i inne RDBMS implementują logikę trójwartościową (three-valued logic, 3VL). Przestrzeń nie ogranicza się więc do wartości TRUE i FALSE, lecz składa się na nią TRUE, FALSE i UNKNOWN. Może więc dojść do sytuacji, że kiedy - ze względu na operację z NULLem - warunek powinien mieć wartość logiczną UNKNOWN, w praktyce zwraca wartość prawdy. Dokładnie taka sytuacja ma miejsce w poniższym przykładzie:

DECLARE @a int;
SET @a = 1;

IF (NOT (@a<>1 AND 1=NULL))
PRINT 'TRUE';

Warto o tym pamiętać, gdyż NULLe i stany nieokreśloności mogą generować sporą ilość trudno wykrywalnych problemów.

Sposób ewaluacji wyrażeń logicznych jest analogiczny w stosunku do wyżej opisanego w przypadku wszystkich znanych mi technologii (języków). Wiedza o takim sposobie obsługi jest więc całkiem wskazana tym bardziej, że umożliwi ona zapisywanie skomplikowanych warunków logicznych w sposób bardziej wydajny - czyli taki, aby sterując kolejnością wyrażeń składowych jak najwcześniej dało się zaprzeczyć lub uznać za prawdziwy cały warunek. Oczywiście ten swoisty tuning wyrażeń logicznych może mieć miejsce wyłącznie w środowisku, które respektuje kolejność wykonywania wyrażeń składowych zgodnie z ich występowaniem w kodzie (od lewej do prawej). Jest to powszechny standard, ale np. SQL Server się do niego nie stosuje.

Garbage collection i słabe referencje (weak references)

nospam@example.com (Marcin Guzowski) — Sat, 06 Jan 2007 18:08:00 +0100

Różne środowiska uruchomieniowe, w tym także CLR platformy .NET, wykorzystują mechanizm automatycznego zarządzania pamięcią, określany powszechnie jako "odśmiecanie pamięci" (garbage collection). Podstawowym celem zastosowania garbage collection była chęć uwolnienia dewelopera od obowiązku ciągłego myślenia w kategorii skończoności zasobów o przydziale i zwalnianiu dostępnej pamięci. Wpisuje się to oczywiście w ogólną koncepcję tworzenia oprogramowania wg podejścia RAD (Rapid Application Development). Zgodnie z założeniami, w środowisku .NET alokacją i zwalnianiem pamięci zajmuje się specjalny mechanizm - tzw. garbage collector (GC), a programista powinien skupić się na funkcjonalności aplikacji. Nie oznacza to jednak, że możemy zupełnie zapomnieć o kwestiach dotyczących pamięci. GC funkcjonuje w oparciu o zestaw reguł, na podstawie których podejmuje określone działania. Naturalnie reguły te nie są równie efektywne w każdej z możliwych sytuacji, dlatego właśnie świadomy deweloper powinien nauczyć się tak pisać swój kod, żeby w pośredni sposób wpływać na przewidywalne zachowania garbage collectora.

Chciałbym zwrócić uwagę na kilka kwestii związanych z automatycznym zarządzaniem pamięcią na platformie .NET. Tematyka jest bardzo szeroka i wieloaspektowa, dlatego poniższe informacje mogą stanowić jedynie wstęp do bardziej dogłębnej analizy tematu.

Pamięć w sensie funkcjonalnym podzielić możemy na stos (stack) i stertę zarządzaną (managed heap). Typy bezpośrednie (value types, czyli np. zmienne w metodzie) alokowane są na stosie. GC nie ma z nimi za wiele pracy - po opuszczeniu metody pamięć jest w prosty i natychmiastowy sposób zwalniana. Wszystko komplikuje się w przypadku typów referencyjnych, które alokowane są na stercie. Każde utworzenie nowego obiektu powoduje zarezerwowanie określonego obszaru pamięci na stercie (przesuwany jest także wskaźnik alokacji NextObjPtr, wskazujący następny dostępny adres). O ile moment tworzenia obiektu jest jednoznaczny i trywialny do określenia, o tyle identyfikacja obiektów już niepotrzebnych to działanie o wiele bardziej złożone. Zadanie to GC realizuje poprzez cykliczne sprawdzanie, które obiekty nie są osiągalne z żadnego zasięgu w programie. Odbywa się to na zasadzie wstępnej negacji - początkowo wszystkie obiekty uznawane są za martwe, następnie GC z listy śmierci usuwane te, które w danym momencie mogą być osiągnięte przez kod aplikacji. Pozostałe obiekty przeznaczone są do unicestwienia. Podczas okresowej aktualizacji sterty GC zwalnia bloki pamięci odnoszące się do martwych obiektów. Dodatkowo scala pozostałe bloki tak, by nie pozostawały między nimi żadne wolne przestrzenie. Wiąże się to oczywiście z koniecznością aktualizacji wskaźnika alokacji i koniecznością przeadresowania wszystkich referencji do obiektów, gdyż po migracji bloków zmianie ulegają adresy pamięci. Operacje wykonywane przez GC są dla wnętrzności naszego programu dość rewolucyjne i kosztowne pod względem wydajności. Podczas działania GC może wystąpić chwilowa niepoprawność referencji, pamięć musi więc pozostawać niedostępna dla aplikacji, co jest realizowane przez wstrzymanie wszystkich jej wątków. Ze względu na opisaną charakterystykę pracy i kosztowność operacji, GC uruchamiany jest zasadniczo dopiero w sytuacji braku pamięci na stercie.

Algorytm garbage collection działa w rzeczywistości w nieco bardziej skomplikowany sposób, uwzględniając m.in. tzw. generacje. Możliwe jest także wymuszone uruchomienie GC z kodu aplikacji (System.GC.Collect()). Wymienione kwestie, jak też inne szczegóły wykraczają jednak poza zakres tego powierzchownego artykułu - zainteresowanych zapraszam do zapoznania się z linkami zebranymi poniżej.

Trzeba pamiętać, że GC zajmuje się zwalnianiem pamięci zajmowanej przez martwe obiekty, a nie zwalnianiem wszystkich zasobów przez te obiekty wykorzystywanych. Sami więc musimy zadbać o zwolnienia zasobów niezarządzanych (plikowych, sieciowych, sprzętowych), np. otwartego połączenia do bazy danych. Nie chodzi tutaj wyłącznie o tzw. finalizację (zaimplementowanie finalizatora klasy), która w wielu sytuacjach może okazać się mało efektywna. Lepszym wyjściem będzie oprogramowanie metod Close() i Dispose(), czy stosowanie bloku using.

Ciekawe możliwości oferują tzw. słabe referencje (weak references). Nie jest to pomysł ani nowy, ani specyficzny wyłącznie dla platformy .NET. Słabe referencje spotykamy również w innych technologiach z mechanizmem typu garbage collection (jak Java czy Perl).

Dla jednoznaczności warto uściślić, że silna referencja do obiektu (strong reference) występuje w sytuacji, kiedy obiekt może być osiągnięty z kodu aplikacji. W sytuacji silnej (zwykłej) referencji obiekt jest więc poza zainteresowanie GC. Słaba referencja natomiast to swoisty kompromis - obiekt jest co prawda dostępny dla aplikacji (która może uzyskać do niego silną referencję), ale w każdym momencie GC może go unicestwić.

Pozornie może się wydawać, że nie ma to wielkiego sensu. Są jednak sytuacje, w których opisany kompromis jest całkiem akceptowalny. Słabe referencje świetnie nadają się do obiektów, które zajmują duży obszar pamięci, ale mogą być łatwo odtworzone. Wprowadza to swoistą elastyczność obsługi do naszej aplikacji. Kiedy zabraknie pamięci, obiekt ze słabą referencją zostanie unicestwiony przez GC i na stercie przybędzie potrzebnej w danym momencie wolnej przestrzeni. Jeżeli obiekt będzie potrzebny ponownie, zostanie w prosty sposób zrekonstruowany. W sytuacji dostatecznej ilości wolnej przestrzeni na stercie, obiekt nie zostanie zniszczony, aplikacja będzie więc go mogła użyć natychmiast po wykorzystaniu słabej referencji.

Słabych referencji nie należy stosować przy małych obiektach jak też nie są one remedium na wszystkie problemy wydajnościowe aplikacji - w każdym razie na pewno nie zastąpią rozsądnego i przemyślanego cacheowania.

Więcej informacji:
MSDN: Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
MSDN: Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework
MSDN: Using Weak References

Deduplikacja danych: .NET vs Perl

nospam@example.com (Marcin Guzowski) — Thu, 16 Nov 2006 22:39:00 +0100

Systemy informatyczne przetwarzają coraz większe ilości danych, w naturalny sposób pojawia się więc coraz większa potrzeba ich automatycznej analizy i obróbki. Deweloperzy związani z bazami danych muszą tworzyć specyficzne, dedykowane rozwiązania, a wybór odpowiedniej technologii to praktycznie klucz do sukcesu. Chciałbym porównać dwie wybrane platformy - .NET i Perl - w hipotetycznym scenariuszu automatycznego przetwarzania danych.

Wspomniany scenariusz zakłada potrzebę wyznaczenia rekordów podobnych w bazie klientów, a dokładniej - w tabeli, która zawiera 10000 wierszy z danymi teleadresowymi (przykładowe kolumny: nazwa, miejscowość, adres, kod, nip). Dane w bazie są zwielokrotnione, tzn. kilka rekordów w rzeczywistości opisuje jednego i tego samego klienta (zapisanego oczywiście w różny sposób, np. "FIRMA HERKULES", "HERKULES S.C.", "HERKULES - SKLEP"; analogicznie z danymi adresowymi: "WIEJSKA 15", "ULICA WIEJSKA" itd.). Aby zrealizować cel, do tabeli zostanie dodana kolumna unikalnego identyfikatora, a algorytm zapełni ją odpowiednimi wartościami, przydzielając rekordom dostatecznie podobnym taki sam identyfikator. Zakładamy ponadto warunek brzegowy (minimalizacja ryzyka błędu): rekordy oznaczone jako podobne muszą posiadać identyczny NIP.

Zadanie opisane wyżej to klasyczna deduplikacja danych. Od prawie 2 lat zajmuję się m.in. procesami inteligentnej analizy, przetwarzania danych i obserwuję w ostatnim czasie znaczący, dynamiczny wzrost popularności tej tematyki. Złoty wiek różnorodnych automatów właśnie się rozpoczął.

Wracając do naszego scenariusza, można sobie wyobrazić co najmniej kilka koncepcji algorytmu deduplikacji, oczywiście każdy z nich ma swoje mocne i słabe strony. Skupiamy się na technologii, a nie na funkcjonalnościach - więc dodam tylko, że do oceny zgodności poszczególnych pól użyłem metody Levenshtein-Distance (google zaprasza zainteresowanych).

Środowisko testowe wyglądało następująco: serwer Windows Server 2003 SE 32bit, baza danych SQL Server 2005 SP1, wszystko postawione na jednej maszynie (na której uruchamiane były również testowe implementacje). Jak widać środowisko zostało dobrane tak, żeby lekko faworyzować platformę .NET. Implementacja algorytmu w CLR (język C#) to klasyczna aplikacja obiektowa z providerem OLE DB (natywne rozwiązanie względem SQL Servera).

Algorytm został również zaimplementowany w Perlu (wersja 5.8.8), dostępem do danych zajmował się moduł DBI działający na providerze ODBC.

Mamy więc pojedynek technologii, za którą stoją miliardy dolarów w jej naturalnym środowisku - i - technologii open source, która dzięki wieloletniej pracy rzeszy ludzi została wysoce zoptymalizowana do przetwarzania danych, a wyrażenia regularne traktuje tak samo natywnie jak choćby instrukcję warunkową IF. Poniżej przedstawiam wyniki:

(średni czas dla 3 prób)

PERL:
81 s

.NET:
127 s

Wyraźnie zwyciężył więc Perl, który zadanie wykonał o 55% szybciej niż konkurent (jakość była jednakowa w obydwu przypadkach, zgodnie z założeniem). Nie pierwszy raz przekonałem się, że Practical Extraction and Report Language nie ma sobie równych wśród technologii do przetwarzania danych. Warto też dodać, że obydwie implementacje powstały w tak samo krótkim czasie, mimo że do stworzenia kodu w Perlu wykorzystałem zwykły edytor tekstowy, a do .NET - potężne Visual Studio 2005 z pełnym intellisense i innymi programistycznymi udogodnieniami.

Bezpieczeństwo kodu źródłowego

nospam@example.com (Marcin Guzowski) — Sat, 11 Nov 2006 14:36:00 +0100

Platforma .NET dostarcza deweloperom wielu nowych możliwości, ułatwień i ulepszeń, także w aspekcie bezpieczeństwa - zwiększając tym samym ochronę szeroko pojętych dóbr intelektualnych. Współczesne organizacje poświęcają wiele energii dbając o to, by określona informacja nie dotarła do osób niepowołanych. Stosowane są zaawansowane metodyki bezpieczeństwa, szyfrowanie, ścisła identyfikacja zasobów, firewalle itd. Tymczasem dając użytkownikowi do ręki skompilowaną do kilku plików DDL i pliku EXE aplikację .NET - dajemy mu jednocześnie na talerzu co najmniej jej algorytmiczne tajemnice, a często także szereg innych cennych informacji.

Wszystkie .NETowskie asemblacje objęte są tzw. mechanizmem reflection, który jest interfejsem do pozyskania szczegółowych metainformacji dotyczących wszystkich klas w danej assembly. To cena, jaką płacimy m.in. za intellisense w Visual Studio.

Wprawdzie self-desribing assemblies nie ujawniają własnego kodu MSIL (Microsoft Intermediate Language), jednak droga do jego pozyskania dla amatorów cudzego kodu źródłowego jest banalnie prosta. Jeszcze łatwiej natomiast zamienić instrukcje języka pośredniego na kod języka wyższego poziomu - C#, VB.NET czy managed C++. Razem z .NET Framework dostarczany jest IL Assembler - to oczywiste. Być może mniej oczywisty jest fakt, że wraz z .NET Framework SDK (dołączonym m.in. do Visual Studio), dostarczany jest także IL Disassembler. Wystarczy więc uruchomić plik lidasm.exe i już mamy okienkowy interfejs prowadzący wprost do kodu pośredniego dowolnej aplikacji .NET, nie robiąc przy tym kompletnie nic nielegalnego. IL Disassembler jest jednak troszkę toporny, w końcu dlaczego nie mielibyśmy od razu otrzymać kodu w dowolnym języku wyższego poziomu (do wyboru), wraz z całą hierarchią obiektów, typami, metodami w przyjaznym dla oka GUI? Nic bardziej prostszego, programów tego typu jest całkiem sporo. Wystarczy polecić Lutz Roeder's .NET Reflector (strona domowa). Na życzenie program ten wygeneruje nam w pełni funkcjonalny projekt, który natychmiast możemy otworzyć w Visual Studio.

Okrutna prawda jest taka, że każdy program można poddać mniej lub bardziej skutecznej disasemblacji, przy czym jest to o wiele trudniejsze w przypadku binarki Win32, a o wiele łatwiejsze w przypadku aplikacji .NET (analogicznie: Javy czy Perla). Potwierdza to starą zasadę, że nie ma zabezpieczenia, którego nie dałoby się złamać. Jedyne co można zrobić, to maksymalnie utrudnić reverse engineering, mając nadzieję, że skutecznie zniechęci to ewentualnych zainteresowanych. Jeżeli już musimy udostępnić komuś bezpośrednio skompilowany program, to zadbajmy chociaż o maksymalne "zaciemnienie" jego kodu źródłowego. Można użyć do tego celu jednego z powszechnie dostępnych obfuscatorów, np. programu Dotfuscator (strona domowa, polecany przez Microsoft). Kod źródłowy zostanie wtedy odpowiednio zmodyfikowany: obfuscator zamieni nazwy zmiennych, obiektów, metod na niezrozumiałe dla człowieka sekwencje znaków, zaszyfruje wartości stringów, zastosuje instrukcje goto utrudniające zrozumienie kolejności instrukcji itp. Oczywiście wszystkie wymienione czynności nie będą wpływały na efekt działania skompilowanej aplikacji, chodzi tylko o jak największe skomplikowanie analizy kodu pozyskanego przez disasemblację. Trzeba jednak od razu zaznaczyć, że istnieje co najmniej kilka deobfuscatorów, które potrafią przywrócić kod do całkiem czytelnej formy...

Szczerze mówiąc, nie ma dobrej metody na ochronę kodu aplikacji .NET, jeżeli fizycznie przekazujemy skompilowany program osobie trzeciej. Trzeba mieć to na uwadze projektując rozwiązania z zastosowaniem tej technologii. Nie zawsze jednak sytuacja wymaga takiego kroku - wtedy otwiera się obszar dla zastosowania technologii webowej lub usług terminalowych. Może i są to rozwiązania mniej wygodne dla użytkownika, ale nie ma przecież nic za darmo.

Czas wykonania bloku kodu

nospam@example.com (Marcin Guzowski) — Thu, 12 Oct 2006 20:01:00 +0200

Zadanie: określić jak długo wykonywał się dowolny fragment kodu. Interesuje nas czas w sekundach, który można od razu wyświetlić w dowolnej kontrolce (rzutowanie na string). Poniżej kod w C#:

long Ticks = System.DateTime.Now.Ticks;
// początek kodu objętego pomiarem
for (int i=0;i<1000000;i++)
{
i = i+1;
}
// koniec kodu objętego pomiarem
Ticks = System.DateTime.Now.Ticks - Ticks;
string strSeconds = new System.TimeSpan(Ticks).TotalSeconds.ToString();

Struktura TimeSpan przechowuje czas w postaci określonej liczby tzw. ticków (1 tick = 100 nanosekund), które w powyższym przykładzie przekazywane są do konstruktora za pomocą zmiennej Ticks (typ long integer). TimeSpan udostępnia czas w bardziej dla człowieka zrozumiałej formie przy pomocy kilku property methods:
- TotalMilliseconds
- TotalSeconds
- TotalMinutes
- TotalHours
- TotalDays

ASP.NET - DataGrid i własne nagłówki

nospam@example.com (Marcin Guzowski) — Sun, 01 Oct 2006 21:20:00 +0200

Załóżmy następujący, całkiem popularny scenariusz: ASP.NET 1.1/2.0, kontrolka DataGrid i bindowany do niej DataSet lub inny obiekt z danymi pobranymi z BD (DataTable, DataView). Interesuje nas sposób wpływania na nagłówki grida tak, aby możliwe było przykładowo wprowadzenie dwuwierszowych komórek w nagłówkach i/lub łączenie odpowiednich komórek, tj.:

Domyślnie DataGrid tworzy nagłówki kolumn w jednym wierszu na podstawie kolekcji kolumn ze źródła danych (czyli np. DataView.Table.Columns). Aby to naturalne zachowanie zostało zmienione, należy przejąć kontrolę nad renderowaniem grida. Wykorzystamy do tego celu metodę SetRenderMethodDelegate, która oddeleguje obsługę renderowania grida dgGrid na naszą metodę GridRendering:

// najbezpieczniej umieścić po wywołaniu DataBind()
dgGrid.SetRenderMethodDelegate(new System.Web.UI.RenderMethod (GridRendering));

Teraz pozostaje tylko przygotować metodę GridRendering, która będzie odpowiadała za zbudowanie grida. Tym samym schodzimy na niższy poziom procesu powstawania strony aspx, gdzie grid jest po prostu zbiorem odpowiednich dyrektyw języka HTML. Dzięki temu zyskujemy dostęp do wszystkich możliwości wpływania na layout, jakie daje nam HTML, CSS czy JavaScript. Przykładowy kod metody może wyglądać tak:

// using System.Web.UI;
// using System.Web.UI.WebControls;
private void GridRendering (HtmlTextWriter writer, Control ctrl)
{
   // nagłówki
   string header = @"
   <tr>
      <td colspan=""2"">A</td>
      <td colspan=""2"">B</td>
   </tr>
   <tr>
      <td>C</td>
      <td>D</td>
      <td>E</td>
      <td>F</td>
   </tr>
   ";

   writer.Write(@"<table border=""1"">");
   writer.Write(header);

   // pozostałe komórki
   Control GridControl = ctrl.Controls[0];

   foreach (Control ctl in GridControl.Controls)
   {
      // rzutowanie
      DataGridItem item = (DataGridItem)ctl;

      // sprawdzenie typu komórki - aby pominąć nagłówki
      if (item.ItemType != ListItemType.Header)
      {
         // ustawienie stylu CSS dla komórki i rendering
         item.Attributes.Add("class","nazwa_CSS");
         item.RenderControl(writer);
      }
   }
   writer.Write("</table>");
}

Metoda GridRendering najpierw drukuje zdefiniowane przez nas nagłówki kolumn - ich struktura/liczba musi być dostosowana do ilości kolumn w źródle danych, następnie wykonana zostaje pętla po pozostałych komórkach. Nie musimy dla nich za każdym razem drukować tagów HTML (budować elementów html-owej tabeli), wystarczy wywołanie metody RenderControl(writer). Dodatkowo, aby ułatwić zarządzanie layoutem z poziomu CSS, do każdej komórki dodawany jest odpowiedni atrybut class. Oczywiście atrybut ten może być również dodany do kodu HTML samego nagłówka (zmienna header).

Możliwości samego rozwiązania są bardzo duże, można np. dynamicznie tworzyć złożone nagłówki, a od tego już tylko krok do tabeli przestawnej. Można również dowolnie kreować całego grida i tworzyć na jego bazie własne atrakcyjne i dostosowane do specyficznych potrzeb kontrolki.