Moim zdaniem najlepiej jest wprowadzić do aplikacji pasek postępu (choć nie zawsze jest to możliwe, bo czasem nie wiadomo ile danych przybędzie) i przede wszystkim – podzielić dane na paczki i prezentować dane progresywnie.

Jak to zrobić?

Najprostszym i przyjemnym sposobem jest użycie klasy BackgroundWorker, ale zacznijmy od początku. W celach demonstracyjnych stworzymy proste okienko, które będzie zawierało ListBox – do prezentacji wyników, przycisk „Start” oraz ProgressBar. Przejdźmy teraz do kodu:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

private BackgroundWorker backgroundWorker = new BackgroundWorker();
private const int Results = 40;
private const int MaxPartCount = 5;
 
public PartialUpdateWindow()
{
    InitializeComponent();
 
    //initializing backgroundWorker
    backgroundWorker.DoWork += backgroundWorker_DoWork;
    backgroundWorker.ProgressChanged += backgroundWorker_ProgressChanged;
    backgroundWorker.RunWorkerCompleted += backgroundWorker_RunWorkerCompleted;
    backgroundWorker.WorkerReportsProgress = true;
}

Kod chyba jest bardzo wymowny. Tworzymy nową instancję BackgroundWorkera, dla prostoty przykładu ustalamy ile będzie wyników i ile ma liczyć maksymalna paczka danych do wyświetlenia. Następnie przypisujemy odpowiednie zdarzenia – DoWork – czyli to co ma zostać wykonane, ProgressChanged – zdarzenie odpalane w wątku GUI, które wyświetla wyniki, RunWorkerCompleted – odpalane po zakończeniu DoWork. Ostatnia linijka jest istotna, bo domyślnie ustawiona jest na false i wywołanie ProgressChanged skończy się wyjątkiem. Przejdźmy teraz do implementacji poszczególnych metod.

1
2
3
4
5
6

private void startButton_Click(object sender, RoutedEventArgs e)
{
    resultsListBox.Items.Clear();
    startButton.IsEnabled = false;
    backgroundWorker.RunWorkerAsync(Results);
}

Na początek funkcja podpięta pod przycisk która odpali naszego BackgroundWorkera. Jak widzimy do metody RunWorkerAsync, która uruchamia wątek możemy przekazać opcjonalnie argument. Może być on dowolnego typu i może być tylko jeden. W razie potrzeby, można zawsze przesłać tablicę lub inny kontener.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
    int percentageComplete;
    List<int> tempResults = new List<int>();
    int partsCount;
 
    var random = new Random();
 
    for (var i = 1; i <= Math.Ceiling((int)e.Argument / (double)MaxPartCount); i++)
    {
        Thread.Sleep(random.Next(500, 1000)); //simulating data fetching
 
        if (i * MaxPartCount <= (int)e.Argument)
            partsCount = MaxPartCount; //send maximum
        else
            partsCount = (int)e.Argument - i * MaxPartCount; //send remaining
 
        for (var j = 0; j < partsCount; j++)
            tempResults.Add(random.Next());
 
        percentageComplete = (int)(((double)(i * MaxPartCount) / (int)e.Argument) * 100);
 
        backgroundWorker.ReportProgress(percentageComplete, tempResults);
    }
}

Teraz główna część naszego przykładu, czyli metoda podpięta pod DoWork. W środku tej metody tworzymy pętlę, która przebiega odpowiednią ilość razy (sufit ze wszystkich wyników podzielonych na maksymalna ilość części). Jak widzimy możemy się odwołać do przesłanego argumentu poprzez e.Argument. Musimy jednak stosować rzutowanie, gdyż e.Argument jest typu object (to dosyć oczywiste). W dalszych linijkach generujemy w losowym odstępie czasu po partsCount (równa MaxPartCount albo to co nie zostało jeszcze wysłane) liczb losowych, a także obliczamy procent wykonanej roboty. Kluczową częścią metody jest jej ostatnia linijka, która wywołuje w wątku GUI metodę podpiętą pod ProgressChanged. Do metody tej przekazujemy procent wykonanej pracy oraz znowu mamy opcjonalnie do przekazania jeden argument (ponownie typu object). To umożliwia nam sprytne użycie pozyskanych częściowych wyników – wysłanie ich do GUI. Dalsza część to już oczywistość:

1
2
3
4
5
6
7
8
9
10
11

private void backgroundWorker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
    completeProgressBar.Value = e.ProgressPercentage;
    foreach (var item in (List<int>)e.UserState)
        resultsListBox.Items.Add(item);
}
 
private void backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
    startButton.IsEnabled = true;
}

W backgroundWorker_ProgressChanged uaktualniamy stan ProgressBara oraz dodajemy pozyskane elementu do ListBoksa. Jest to możliwe gdyż, jak już wspomniałem, metoda ta wywoływana jest w tym samym wątku co GUI. Warto zwrócić uwagę na przekazany argument dostępny pod e.UserState – znów konieczne jest rzutowanie. Po skończonej pracy odblokowywujemy przycisk start i to tyle.

Podsumowanie

Widzimy, że rozwiązanie problemu częściowego uaktualniania interfejsu za pomocą BackgroundWorkera jest bardzo łatwe. To jest niewątpliwy plus. Ten sposób ma też (jak chyba wszystko ;)) jednak swoje wady. Po pierwsze, widać w kodzie, że w wielu miejscach musimy stosować rzutowanie z typu object na inny typ. Nie jest to operacja bezpieczna i przy jakichkolwiek zmianach w kodzie należy pamiętać aby pozmieniać też rzutowania w innych miejscach. Innym minusem jest utrudnione oddzielnie widoku od logiki, gdyż klasa BackgroundWorker pozostaje mocno powiązana z GUI.

Konicząc mój wywód – jeśli tworzysz małą aplikację lub pogodzenie się z minusami BackgroundWorkera nie jest szkodliwe dla Ciebie, ani dla tworzonego kodu – jak najbardziej polecam to rozwiązanie, bo po co pisać kod, który stworzył już ktoś wcześniej?

1
2
3
4

 lock(somethingSharedToLock)
{
     // operations on the locked object
}

Jak widać składnia jest bardzo prosta, ale co tak właściwie daje nam lock? Użycie słowa kluczowego lock gwarantuje nam, iż żaden inny wątek nie będzie ingerował w zablokowany obiekt podczas wykonywania instrukcji z nawiasu klamrowego. Natomiast jeśli obiekt jest zablokowany przez inny wątek, to kolejny lock będzie cierpliwie czekał na zwolnienie obiektu i dopiero wtedy go zablokuje. Pięknie, prawda? :) Oczywiście lock, jak wszystko – ma swoje wady. Częste i nierozważne lockowanie może doprowadzić do tzw. zakleszczenia (ang. deadlock). Starczy tej teorii, przejdźmy do przykładu (przykład z całą pewnością nie pokazuje best practices tworzenia kodu, ale chodziło mi o maksymalne uproszczenie przykładu).

Stwórzmy sobie prostą klasę producenta:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class Producer
{
public bool IsFinished
{
    get;
    set;
}
public List<int> List
{
    get;
    set;
}
public Producer()
{
    List = new List<int>();
    IsFinished = false;
}
public void Produce()
{
    Random random = new Random();
 
    for (int i = 0; i < 20; i++)
    {
        List.Add(random.Next(0, 20));
        Console.WriteLine("Producer[{0}]={1}", i, List[i]);
        Thread.Sleep(500);
    }
    IsFinished = true;
    Console.WriteLine("Producer has finished his work");
}
}

Klasa ta, jak widać, w konstruktorze przyjmuję listę, a następnie po wywołaniu Produce() wpisuje do tej listy losowe liczby całkowite z przedziału <0,20) wypisując je przy okazji. Klasa posiada pole które poinformuje nas, że praca została zakończona. Usypianie w metodzie produkującej umożliwi nam zaobserwowanie pewnej ciekawej rzeczy, ale o tym dalej.

Klasa konsumenta:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class Consument
{
    private Producer producer;
    public Consument(Producer producer)
    {
        this.producer = producer;
    }
    public void Consume()
    {
        int currentElement = 0;
        int elementCount = 0;
 
        while (true)
        {
              elementCount = producer.List.Count;
 
              if (producer.List.Count > currentElement)
              {
                   producer.List[currentElement] += 2;
                   Console.WriteLine("Consument[{0}]={1}", currentElement, producer.List[currentElement]);
                   currentElement++;
              }
              if (producer.List.Count == currentElement && producer.IsFinished)
                   break;
         }
         Console.WriteLine("Consument has finished his work");
    }
}

Konsument, w konstruktorze przyjmuje producenta, a po wywołaniu Consume(), o ile pojawiło się coś nowego zwiększa wartość każdego elementu o 2, a następnie go wypisuje. Metoda kończy swoje działanie w momencie, gdy Producent da o tym znać i wszystkie elementy zostaną zmienione.

Pozostaje nam odpalić produkcje i konsumpcje w oddzielnych wątkach:

1
2
3
4
5
6
7
8
9
10
11
12
13

private static void Main(string[] args)
{
     Producer producer = new Producer();
     Consument consument = new Consument(producer);
 
     Thread producerThread = new Thread(new ThreadStart(producer.Produce));
     Thread consumentThread = new Thread(new ThreadStart(consument.Consume));
 
     producerThread.Start();
     consumentThread.Start();
     producerThread.Join();
     consumentThread.Join();
}

Wynik działania programu (przykładowy!!):

Producer[0]=0
Consument[0]=2
Producer[1]=4
Consument[1]=4
Producer[2]=17
Consument[2]=17
Producer[3]=8
Consument[3]=8
Producer[4]=0
Consument[4]=2
Producer[5]=16
Consument[5]=16
Producer[6]=6
Consument[6]=6
Producer[7]=13
Consument[7]=13
Producer[8]=17
Consument[8]=19
Producer[9]=9
Consument[9]=11
Producer[10]=15
Consument[10]=17
Producer[11]=14
Consument[11]=14
Producer[12]=11
Consument[12]=13
Producer[13]=3
Consument[13]=5
Producer[14]=15
Consument[14]=15
Producer[15]=13
Consument[15]=13
Producer[16]=16
Consument[16]=18
Producer[17]=5
Consument[17]=7
Producer[18]=2
Consument[18]=2
Producer[19]=14
Consument[19]=16
Producer has finished his work
Consument has finished his work

Ups! Widzimy, że w wielu przypadkach (1, 2, 3, 5, 6, 7, 11, 14, 15, 18 – czyli w połowie wszystkich) wartość producenta nie została zmieniona, tak jakbyśmy chcieli. Czemu się tak stało? Otóż produkcja kolejnych elementów trwa dłużej niż konsumpcja (poprzez wspomniane wcześniej Thread.Sleep(500)) co powoduje iż w pewnych momentach dana jest „jeszcze” tworzona, a próbuje już być skonsumowana, co powoduje iż proces konsumpcji (dodanie do wartości 2) zostaje pominięte. Uniknięcie tej katastrofy jest możliwe dzięki wspomnianemu lockowi. Wystarczy napisać:

1
2
3
4
5
6

lock (((ICollection)List).SyncRoot)
{
    List.Add(random.Next(0, 20));
    Console.WriteLine("Producer[{0}]={1}", i, List[i]);
    Thread.Sleep(500);
}

oraz:

1
2
3
4
5
6
7
8
9
10
11
12
13

lock (((ICollection)producer.List).SyncRoot)
{
    elementCount = producer.List.Count;
 
    if (producer.List.Count > currentElement)
    {
        producer.List[currentElement] += 2;
        Console.WriteLine("Consument[{0}]={1}", currentElement, producer.List[currentElement]);
        currentElement++;
    }
    if (producer.List.Count == currentElement && producer.IsFinished)
        break;
}

To zapewni nam prawidłowe działanie kodu (jak nie wierzycie – sprawdźcie sami :)). A co tak właściwie się stało? Kolekcja w momencie produkowania jest na chwilę blokowana, a więc konsumpcja jest wtedy wstrzymana, gdy produkcja się skończy, konsumpcja zabiera kolekcję dla siebie. Dzięki temu działanie jest zgrabnie zsynchronizowane. Dla kolekcji, w celu synchronizacji należy używać właściwości SyncRoot która jest wymagana przez interfejs ICollection. Wszystkie inne obiekty możemy lockować w sposób bezpośredni (lock(someObject)) chyba, że coś (dokumentacja) podpowiada nam inaczej ;)

To tyle w tej kwestii, dla zainteresowanych polecam poczytać Thread Synchronization oraz How to: Synchronize a Producer and a Consumer Thread.

Pełny listing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

using System;
using System.Collections;
using System.Collections.Generic;
using System.Threading;
 
namespace ProducentConsumerExample
{
    class Example
    {
        private static void Main(string[] args)
        {
            Producer producer = new Producer();
            Consument consument = new Consument(producer);
 
            Thread producerThread = new Thread(new ThreadStart(producer.Produce));
            Thread consumentThread = new Thread(new ThreadStart(consument.Consume));
 
            producerThread.Start();
            consumentThread.Start();
 
            producerThread.Join();
            consumentThread.Join();
        }
    }
 
    class Producer
    {
        public bool IsFinished
        {
            get;
            set;
        }
 
        public List<int> List
        {
            get;
            set;
        }
 
        public Producer()
        {
            List = new List<int>();
            IsFinished = false;
        }
 
        public void Produce()
        {
            Random random = new Random();
 
            for (int i = 0; i < 20; i++)
            {
                lock (((ICollection)List).SyncRoot)
                {
                    List.Add(random.Next(0, 20));
                    Console.WriteLine("Producer[{0}]={1}", i, List[i]);
                    Thread.Sleep(500);
                }
            }
 
            IsFinished = true;
 
            Console.WriteLine("Producer has finished his work");
        }
    }
 
    class Consument
    {
        private Producer producer;
 
        public Consument(Producer producer)
        {
            this.producer = producer;
        }
 
        public void Consume()
        {
            int currentElement = 0;
            int elementCount = 0;
 
            while (true)
            {
                lock (((ICollection)producer.List).SyncRoot)
                {
                    elementCount = producer.List.Count;
 
                    if (producer.List.Count > currentElement)
                    {
                        producer.List[currentElement] += 2;
                        Console.WriteLine("Consument[{0}]={1}", currentElement, producer.List[currentElement]);
                        currentElement++;
                    }
                    if (producer.List.Count == currentElement && producer.IsFinished)
                        break;
                }
            }
 
            Console.WriteLine("Consument has finished his work");
        }
    }
}

W końcu! Na stronach Microsoftu dostępne jest do ściągnięcia ASP.NET MVC 1.0. To doskonała wiadomość dla wszystkich developerów ASP.NET, sam nie mogę się doczekać, aż dobiorę się do świeżutkiego release’a.

W związku z tym, z tego miejsca zapowiadam przepisanie mojego bloga (i udostępnienie źródeł) do ASP.NET MVC 1.0 :) Przy okazji polecam zapoznanie się z fragmentem książki, w którym można znaleźć kompletną instrukcję na temat tego, jak zbudować kompletną aplikację w ASP.NET MVC.

PS. W następnej notce zamieszczę relację z C2C 2009.

Jeśli prowadzicie blog, jedyne czego Wam potrzeba, to ograniczyć „anonimowym” dostęp do pewnych stron i akcji (jak np. dodawanie nowych notek), a dla siebie zatrzymać pełne uprawnienia. W tej sytuacji moje minimalistyczne rozwiązanie wydaje się być rozsądne :) Do rzeczy!

Na początek, w głównym pliku Web.config naszej aplikacji musimy dodać:

<authentication mode=”Forms />”

Aby nasza aplikacja wiedziała, czego od niej chcemy ;) Teraz należałoby stworzyć zwykły widok-formularz, w którym umieścimy pola login i hasło oraz odwołanie do odpowiedniej akcji, na przykład:

<form action=”/Admin/Authenticate/” method=”post”>

To znaczy, że po wciśnięciu przycisku submit uruchomiona zostanie akcja podłączona pod route (to wszystko można ustawić w Global.asax) „http://naszaplikacja.com/Admin/Authenticate/” przekazując przy tym wartości pól Login i Password. Proste, prawda? Teraz należałoby obsłużyć żądanie w kontrolerze. Przykładowa akcja poniżej:

1
2
3
4
5
6
7
8
9
10
11

[AcceptVerbs("POST")]
public ActionResult Authenticate(string Login, string Password)
{
if (!ZaawansowaMetodaAutoryzacji())
throw new Exception();
else
{
FormsAuthentication.SetAuthCookie("Admin", false);
return Index();
}
}

Bardzo ważna jest tutaj linia:

FormsAuthentication.SetAuthCookie(„Admin”, false);

To ona spowoduje, że zostaniemy autoryzowani jako użytkownik „Admin”. Drugi parametr („false”) działa jak znane pole „Remember me”, więcej do poczytania tutaj. Fajnie, prawda?

Teraz pozostaje nam już tylko oznaczyć odpowiednie akcje jako chronione. To ważne, chrońcie akcje a nie strony! Odpowiedź czemu zdaje się być oczywista. W dobrze napisanej aplikacji MVC każdy widok (każda strona) renderowana jest po przejściu przez kontroler, a więc przez odpowiednią akcję. Jeśli zabronimy „anonimowym” dostępu do odpowiednich akcji uzyskamy niemal 100% pewność, że nie obejrzą oni danej strony, ani nie wywołają nieprzeznaczonej dla nich metody (np. tworzącej nowy wpis na blogu) :) Jak zabronić dostępu użykownikowi do danej metody (akcji)? To bardzo proste. Wystarczy metodę oznaczyć atrybutem PrincipalPermission. Na przykład:

1
2
3
4
5
6
7

[PrincipalPermission(SecurityAction.Demand, Name = "Admin")]
[AcceptVerbs("POST")]
public RedirectToRouteResult AddEntry(string Title, string Text)
{
dataContext.AddEntry(Title, Text);
return RedirectToAction("Recent", "Blog");
}

Dzięki temu metoda – wpis może być dodany tylko przez użytkownika „Admin”. W taki sposób oznaczamy wszystkie metody, do których chcemy dodać restrykcje. To tyle! Tym sprytnym sposobem nasza aplikacja jest chroniona w bardzo prosty sposób :)

Jeśli prowadzisz stronę z dynamiczną zawartością, to z całą stanowczością potrzebujesz udostępniać ją jako kanał informacyjny. Coraz więcej osób (w tym od niedawna ja ;)) przegląda niusy, wpisy na blogach tylko i wyłącznie używając syndykacji. Ba, myślę nawet, że wiele stron z powodzeniem istniałoby bez jakiegokolwiek layoutu, a jedynie jako feed :) Ale dosyć już spekulacji, do dzieła! :)

Istnieją dwa liczące się standardy kanałów są to Atom i RSS. Polecam zapoznać się z linkami z jakże niezawodnej wikipedii :) W tym miejscu wypadałoby zdecydować się na któryś standard. Ja opiszę przygotowanie feeda w RSS 2.0, ale nic nie stoi na przeszkodzie, żeby zdecydować się na Atom. RSS wydaje mi się nadal być popularniejszym (osobiste odczucie), ale Atom depcze mu po piętach.
Na początek wypadałoby utworzyć stronę o jakiejś wdzięcznej nazwie, np. Feed.aspx. To było proste, teraz jednak przechodzimy w końcu do kodu :) Nie będę się tutaj rozwodził nad specyfikacją gdyż można o niej przeczytać tutaj. Jeśli jesteś leniwy, to wikipedia przedstawia bardzo skrótowy opis i przykład, który jednak nam wystarcza. Oto fragmencik pliku generującego kanał z bloga, którego czytasz:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Feed.aspx.cs" Inherits="hLog.Views.Blog.Feed" %><%Response.ContentType = "application/xml";%><%@ Import Namespace="hLog.Models"%><?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title>Łukasz Sowa - blog programisty .NET</title>
<link>http://lukaszsowa.pl</link>
<description>Feed z najnowszymi notkami</description>
<% foreach(Entry entry in ViewData.Model) { %>
<item>
<title><![CDATA[<% Response.Write(entry.Title); %>]]></title>
<pubDate><![CDATA[<% Response.Write(entry.Date.ToString()); %>]]></pubDate>
<link><![CDATA[<% Response.Write("http://lukaszsowa.pl/Blog/View/" + entry.ID + "/"); %>]]></link>
<description><![CDATA[<%Response.Write(entry.Text); %>]]></description>
</item>
<%} %>
</channel>
</rss>

1
2
3
4

 protected void Page_Load(object sender, EvenrArgs e)
{
Response.ContentType = "application/xml";
}

Teraz nasza przeglądarka będzie wiedziała (dzięki zmodyfikowanemu nagłówkowi), że odczytuje XML.

Teraz już powinno wszystko działać. Voila! :) Ciesz się swoim własnym kanałem.

PS. To mój pierwszy stricte techniczny tekst, więc liczę na feedback i wyrozumiałość :)

Skończyłem pisać obsługę kanału RSS dla bloga i postanowiłem skrobnąć nieco moich przemyśleń. System blogowy zacząłem pisać tydzień temu i mniej więcej gotowy był po 6 dniach (byłoby szybciej, gdyby nie moje problemy z ASP.NET :)). Wydaje mi się, że to całkiem niezła szybkość produkcji. Dodam, że proces tworzenia nie był zbyt intensywny, a moja znajomość frameworku zbudowana była na lekturze 3 z 4 tutoriali Scotta Guthrie. Fakt, że może przez to cały system nie jest zbyt zaawansowany, ale jest i co najważniejsze – działa! ;)

Oprócz szybkości tworzenia, najważniejszą cechą powstającego dziecka MS jest to, że aplikacje webowy tworzy się dzięki niemu bardzo łatwo i przyjemnie. Naprawdę odczuwałem niesamowitą radość przy klepaniu. Wszystko przychodziło z łatwością, a jeśli nawet czegoś nie wiedziałem, to jedno, dwa spojrzenia w dokumentację (która co prawda jest na razie szczątkowa) i już wszystko było jasne. Kontrolery działają bardzo przewidywalnie (intuicyjnie konfigurowalny routing), a model (który wygenerowałem za pomocą LINQ to SQL – miodzio! korzystałem z tego pierwszy raz i jestem zachwycony!) świetnie z nimi współpracował. Do widoków dane przekazuje się bardzo łatwo – niejawnie, poprzez JEDEN słownik ViewData, bądź po prostu używając silnej typizacji (wymagana jest jedynie zmiana w klasy, z której dziedziczy dany widok. Wszystko to opisane jest tu. Kolejną rzeczą, która zwróciła moją uwagę, to fakt, że w frameworku tym, przynajmniej na pierwszy rzut oka, nie widać „magii”, czyli tego co najbardziej raziło mnie w Ruby on Rails. Nie mam wielkiego doświadczenia z RoR, ale wydaje mi się, że produkt MS niczym nie ustępuje tworowi Davida Heinemeiera Hanssona. Większe doświadczenie mam z Django i stwierdzam, że póki co, ASP.NET MVC brakuje tej „lekkości”, którą ma pythonowy framework. Mam szczerą nadzieję, że to jednak się jeszcze zmieni, przecież dopiero mamy wersję Preview 3, a Django już zdążyło zdobyć doświadczenie na polu frameworków webowych. Kolejną rzeczą, którą można uważać za pewnego rodzaju minus jest brak jakichkolwiek skryptów wspomagających takich jak scaffold w Ruby, czy admin page w Django. Z drugiej strony skrypty te trochę „zaciemniają” oczywistość frameworka, a wszystkie strony tworzone przy ich pomocy są do siebie bardzo podobne, więc przy profesjonalnych cyklach produkcyjnych raczej nie mają zastosowania na większą skalę. Ostatnim minusem jest kiepska integracja z VS. IDE często udziela ostrzeżeń, bądź nawet uważa coś za ewidentny błąd mimo, że kompilator to kompiluje i wszystko działa. Choć może to bardziej wina VS..?

To tyle na pierwszy akt :) Dodam jeszcze, że moje wrażenia opieram na wersji Preview 2, gdyż nie miałem jeszcze okazji zlustrować „trójki”.