BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











SharePoint 2010 - Pierwszy program

01-09-2011 07:00 | Jakub Gutkowski
Artykuł jest pierwszą publikacją z cyklu artykułów "Time For SharePoint Punch". Autor przeprowadza czytelnika przez proces tworzenia pierwszego programu.

O artykule

Zakładam, że SharePoint 2010 (SPS) przynajmniej w wersji Foundation został zainstalowany i z konfigurowany poprawnie (to znaczy: baza danych została zainstalowana, została utworzona Web Application jak i Site Collection z domyślną stroną na którą aktualny użytkownik ma dostęp). Jeżeli nie posiadacie zainstalowanego SPS to polecam ściągnięcie wersji darmowej Foundation (http://bit.ly/hMibJL) i zainstalowanie jej jako Stand Alone na Windows Server 2008 wzwyż - przy Windows 7 możecie natrafić na problemy, które nie są łatwe do rozwiązania lub wymagają trochę więcej ręcznej pracy (http://bit.ly/b2ApAV).

W artykule, będę się starał podawać pełny kod źródłowy - pełny to znaczy, wraz z dyrektywą using jak i wszystkimi niezbędnymi metodami by można było go skopiować i od razu uruchomić (po dodaniu referencji). Jeżeli jednak pominę wszystko i wkleję jedynie nazwę metody z kodem lub czysty kod, to poinformuje czego on tyczy i jak można go uruchomić.

Uważam, że podstawą do programowania jest zrozumienie jak kod działa oraz jak działa produkt dla którego piszemy aplikację. Jeżeli trafiliście tutaj by przejść kolejny tutorial i dowiedzieć się, że jak przeciągniesz przycisk na formę to on pojawi się na formie to źle trafiliście. Zakładam jednak, że posiadacie podstawową wiedzę z programowania, potraficie obsługiwać Visual Studio, oraz macie już doświadczenie w programowaniu C#, w przeciwnym wypadku możecie natrafić na pewne sformułowania które nie będą dla was jasne. Wiedza dotycząca SharePoint nie jest wymagana, będę tłumaczył do czego służą odpowiednie klasy czy też metody jak i odsyłał do odpowiednich zasobów.

Najlepiej będzie jak wraz zemną będziecie iść krok po kroku - czyli czytając artykuł będziecie mieć otwarte Visual Studio. Jak Galdwell wspomniał w swojej książce Outliners, by osiągnąć w danej czynności płynność i swobodę należy ją trenować przez 10 tysięcy godzin. Czytanie zaś nie jest programowaniem. Warto więc ćwiczyć wtedy kiedy możecie.

Dodatkowo, jestem przeciwnikiem mówienia bo tak, dlatego też jeżeli natrafimy na problem z kodem dołożę wszelkich starań by problem został wytłumaczony. Nie znajdziecie tutaj więc odpowiedzi typowych dla forum - zmień target i będzie dobrze, dostaniecie dłuższą dlaczego to nie działa, dlaczego należy zmienić target i jak zmienić target.

Wstęp

• Wykorzystanie SharePoint Object Model po stronie klienta;
• Gdzie szukać bibliotek SharePoint;
• Obiekty COM w SharePoint;
• Platforma 32 i 64 bitowa;

Czyli jednak ktoś wam przydzielił pracę z SharePoint albo może sami z siebie chcecie się go nauczyć? Jeżeli to pierwsze, to bym powiedział standard. SharePoint stało się buzzword tak samo jak Could, czy też SOA. Firmy coraz częściej mówią „tu nam potrzebny SharePoint" nie zważając na to, że akurat SharePoint nie koniecznie jest najlepszym rozwiązaniem. Kiedyś o tym już wspominałem u siebie na blogu (http://bit.ly/r2pOfV), warto więc przed podjęciem pracy z SPS zastanowić się czy aby na pewno to jest to.

Jeżeli jednak trafiliście tutaj z drugiego powodu, to szacun +10.

W artykule przeprowadzę was przez proces wypisania na konsole URL głównej witryny. Proces ten mimo że może wydawać się nie skomplikowany - w końcu co może być trudnego w napisaniu Console.WriteLine - okaże się dość pracochłonny :).

Praca z SPS nigdy to prostych nie należy i to co wydaje się proste, kończy się na godzinach spędzonych przez blado świecącym monitorem, kilku kubkach kawy i min. czterech paczek żelek (polecam świnki Mark&Spencer, dostępne w M&S w Złotych Tarasach) oraz kacem moralnym dlaczego ja w ogóle się tego podjąłem.

Niestety dla nas, kac ten jest głównie spowodowany niezrozumieniem platformy i jej ograniczeń - poprzez kopiowanie gotowych rozwiązań z blogów na których ludzie piszę u mnie działa. I ja tak robiłem, do póki nieprzespane noce nie zaczęły dawać się we znaki. Starałem się znaleźć odpowiedzi w sieci na pytania które mnie nurtowały, jednak im głębiej szukałem tym jaśniej świeciła czerwona żarówka z tabliczką oni powtarzają zasłyszane rzeczy a nikt tak naprawdę nie rozumie dlaczego tak się dzieje, po jakiego grzyba tworzą 50 postów mówiących zmień X na Y zamiast napisać jeden, że X nie działa gdyż A, B i C dlatego obejściem problemu jest Y. Brakowało mi nie tutoriala, za którym mam ślepo podążać, a wytłumaczenia pewnych dziwnych zachowań - dlaczego, po co, gdzie i jak. Moje godziny z SPS więc nie spędzałem na pisaniu coraz to nowszych rozwiązań za pomocą tutaj upuścić, dwu-klik, skopiuj kod a spędzałem czas na czytaniu kodu SharePoint - niestety czasami bez z zrozumienia. Jednak dało mi to dobry wgląd w wnętrzności i zrozumienie dlaczego WF nie działa na ankietach (zrozumienie dlaczego pod względem kodu, bo naprawdę dalej nie wiem dlaczego funkcjonalnie MS zdecydował się na taki ruch).

Artykuł ten jest więc tym co bym chciał przeczytać jak ja zaczynałem naukę SharePoint, zachęcam do lektury.

Narzędzia

Podczas pracy z SharePoint przydaje się mieć przynajmniej podstawowy zestaw narzędzi, których celem jest ułatwienie nam pracy. Poniżej znajduje się lista narzędzi z których będę. Listę tę uważam za maksymalne minimum jakie powinniśmy posiadać:

ILSpy (http://bit.ly/i4zP81) - narzędzie umożliwia dekompilację kodu, dzięki czemu możemy zajrzeć w wnętrzności SharePoint i dowiedzieć się dlaczego pewne rzeczy działają jak działają. Jeżeli do tej pory nie pracowaliście z narzędziem umożliwiającym przeglądanie z kompilowanego kodu, to jest najwyższy czas by rozpocząć swoją przygodę. Dokumentacja bardzo często nie zawiera kluczowych informacji dot. działania metody czy też po prostu jej nie ma. W tym momencie narzędzia typu ILSpy czy też ReSharper w wersji 6.0 z opcją dekompilacji (http://bit.ly/hncZRB) stają się bezcenne.
SQL Server 2005/2008 Express Profiler (http://bit.ly/hBDX4o) - jeżeli korzystanie z wersji SQL Server Express edition, to niestety nie posiadacie narzędzia Profiler z rodziny SQL Server - jest ono dostępne jedynie od wersji Standard wzwyż. Express Profiler jest darmowym narzędziem, który umożliwi prześledzenie tego co jest wykonywane na bazie danych - momentami bardzo przydatna funkcja w szczególności kiedy nagle z niewiadomych przyczyn dostajemy timeouty na połączeniu do bazy danych przy pracy z SharePoint.
ULS Viewer (http://bit.ly/fYlcUr) - przydatne narzędzie do przeglądania logów SharePointa, nie jest to jedyne dostępne, ale mi osobiście odpowiada. Jeżeli macie swoje ulubione to korzystajcie z niego, jeżeli nie to możecie zobaczyć co oferuje ULS Viewer jak i sprawdzić inne narzędzia (na przykład http://bit.ly/f2MOqq).
SharePoint 2010 Service Manager (http://bit.ly/dIJyHx) - narzędzie jest bardzo przydatne kiedy nie korzystamy lub chcemy skorzystać z SharePoint. SharePoint zajmuje nasze zasoby systemowe nawet jak z niego nie korzystamy, narzędzie umożliwi nam wyłączenie usług powiązanych z SharePoint gdy nie są nam one potrzebne oraz ich uruchomienie gdy będą potrzebne.

Pierwszy program

Mottem pierwszego programu jest: do póki nie zrozumiesz dlaczego coś nie działa, to nie zrozumiesz dlaczego to działa.

Tworzymy nowy projekt Console Application w Visual Studio 2010 (VS2010), na maszynie na której nie ma zainstalowanego SharePointa, pobieramy DLLkę Microsoft.SharePoint.dll (możemy ją wziąć z katalogu 14 HIVE*\ISAPI).

* 14 HIVE jest to powszechna nazwa katalogu gdzie znajduje się instalacja SharePoint: X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14 gdzie X to nazwa dysku.

Do projektu dodajemy referencje do pobranej dllki i piszemy następujący kod:

01

Zanim przejdę do omówienia kodu, chciałbym coś zaznaczyć.


Terminologia Site/Web. W SharePoint następuje kolizja nazewnictwa i to dość znacząca - oczywiście kolizja istnieje przez to, że MS stwierdził że zmieni nazwy widoczne dla użytkownika a kod pozostawi bez zmian ze względu na kompatybilność wstecz (bodajże trzymają nazewnictwo od wersji 1.0). Jeżeli poprzez stronę tworzycie Site Collection to w rzeczywistości wykorzystujecie instancję klasy SPSite. Zaś Site to SPWeb oraz Top-level Site to RootWeb. A by jeszcze bardziej utrudnić to klasa pozwalająca na tworzenie nowych site collection nazywa się SPSiteCollection. Dla mnie nazewnictwo oficjalne (site collection, site, top-level site itp.) jest mylące i się w nim gubię - jak ktoś do mnie mówi open connection to site to otworzę do SPSite. W artykule więc będę się trzymał starego nazewnictwa odwołując się do site collection będę używał zamiennie stroną, site lub SPSite, site zaś będę nazywał witryną, web lub SPWeb. Jeżeli natraficie na kolizję lub nie będziecie mnie rozumieć, polecam odwołać się do tego akapitu.

Klasa SPSite jest podstawową klasą z jaką będziemy pracować, czasami będzie nam ona dostarczona przez SharePoint, czasami będziemy musieli ją utworzyć ręcznie (utworzenie ręcznie nie powoduje utworzenie nowej strony, jedynie powoduje to odwołanie się do już istniejącej - jeżeli strona nie istnieje zostanie zwrócony wyjątek FileNotFoundException). Stanowi ona furtkę dostępową do modelu SharePointa, dzięki niej jesteśmy wstanie pobrać wszystkie witryny (strona zespołu, planowanie spotkania itp.). Każda witryna to instancja klasy SPWeb, która zaś stanowi furtkę dostępową do Listy (SPList) jak i wielu innych obiektów. 80-90% czasu jaki będziemy spędzać na programowaniu w modelu obiektowym SharePointa, będzie się głównie dotyczył operacji na SPSite, SPWeb i SPList lub wokół tych klas.


W naszym konkretnym przypadku otwieramy połączenie do domyślnej strony i następnie wyświetlamy URL do RootWeb na konsolę i kończymy nasz program. Kod jest prosty, ale jak zobaczycie, będzie on stanowił nie lada wyzwanie.

Wróćmy do przykładu, jeżeli mamy już dodaną referencję oraz napisany kod, pora uruchomić nasz program (F5). Podczas kompilacji powinniśmy otrzymać następujący błąd:

The type or namespace name 'SharePoint' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)

Opis błędu za dużo nie mówi i wiedza na temat SharePointa też nie pomoże. Problem leży w nowych opcjach kompilacji w .NET Framework 3.5 oraz 4.0 zwanych Client Profile (CF).

Client Profile. W skrócie, daje to możliwość kompilowania kodu, który ma działać po stronie klienta jednak nie załącza on pełnej wersji .NET Framework. To znaczy, że aplikacje z takim targetem, korzystają z okrojonej wersji .NET. Jest to przydatne przy tworzeniu aplikacji i instalatora do nich - zmniejsza to rozmiar danych jakie użytkownik musi pobrać z sieci jak i także rozmiar instalacji na dysku. Powoduje to jednak, że nie wszystkie niezbędne dllki mogą być dostępne.

CF stanowi pewien problem, gdyż SharePoint wymaga referencji do assemblies które nie są dostarczane przez CF - na przykład System.Workflow.Activites. Ze względu na to, ustawienie target framework na CF powoduje iż biblioteka SharePoint nie może być w pełni załadowana, co owocuje problemem wyżej wymienionym.

Pełna lista dostępnych assembly w CF dla .NET 3.5 znajduje się tutaj: http://bit.ly/h2Sf2b zaś pełna lista dla .NET 4.0 tutaj: http://bit.ly/g3ojmn. Jeżeli nie mamy dostępu do Internetu, to nic straconego, wystarczy, że otworzymy następujące katalogi:

  • Dla .NET 3.5: C:\Program Files[ (x86)]\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client
  • Dla .NET 4.0: C:\Program Files[ (x86)]\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client

Gdzie C to nasz dysk zaś [ (x86)] opcjonalna część w zależności od tego czy mamy system 64 bitowy czy też nie.

By dowiedzieć się jakie DLLki są wymagane przez Microsoft.SharePoint.dll możemy otworzyć assembly w ILSpy:

02

Teraz już wiemy jak reagować na problem i jak go rozwiązać. A co najważniejsze, dlaczego on występuje.

Przejdźmy spokojnie do kolejnego kroku - zmiany target framework z .NET 4.0 CF na .NET 4.0 (Alt+Enter na projekcie otworzy jego właściwości, następnie zakładka Build i opcja target framework). Spowoduje to dodanie niestety lub stety pliku konfiguracyjnego dla naszej aplikacji - ale nie trzeba się nim zbytnio przejmować.


W tym momencie kompilacja projektu powinna zakończyć się sukcesem, pora więc na próbę uruchomienia aplikacji (F5), która spowoduje wystąpienie wyjątku:

The type initializer for 'Microsoft.SharePoint.CoreResource' threw an exception.

Jak pamiętacie na początku, do naszego projektu dodaliśmy jedynie bibliotekę Microsoft.SharePoint, zaś z błędu CF wiemy, że biblioteka ta ma pewne zależności które muszą być spełnione by móc wykorzystać ją w projekcie. Tak jest i w tym wypadku. Klasa CoreResources odpowiedzialna jest za dostęp do z lokalizowanych zasobów - w tym wypadku do tak zwanej satelite assembly Microsoft.SharePoint.intl.dll, to właśnie dzięki niej zawdzięczamy przetłumaczenie błędu Access Denied na Farma nie dostępna. Niestety jest ona umieszczona w Global Assembly Cache (GAC) i dostęp do niej jest trochę utrudniony. Jeżeli jednak dalej chcecie sprawdzić co się będzie działo, to proponuje podłączyć następujący zasób jako dysk sieciowy: \\COMP_WITH_SPS\c$\Windows\Assembly - podłączenie katalogu jako dysk sieciowy spowoduje, że rozszerzenia Windows Explorer Shfusion.dll nie zostanie załadowane i umożliwi nam to przeglądanie prawdziwej struktury katalogów GAC - w przeciwnym wypadku dostaniemy ładnie wyglądającą listę bibliotek bez możliwości ich skopiowania.

Wykorzystując proste wyszukiwanie (*SharePoint*) jesteśmy wstanie odnaleźć wszystkie niezbędne biblioteki jakie będą nam potrzebne do dalszej pracy. Osobiście jednak nie zachęcam do tego i proponuje następne paragrafy po prostu przeczytać by się dowiedzieć co będzie się działo i dlaczego.

Mając pełny komplet bibliotek, możemy kontynuować pracę. Do naszego projektu dodajemy referencję do Microsoft.SharePoint.intl.dll i następnie uruchamiany projekt (F5). Tym razem jesteśmy trochę bardziej do przodu, błąd, który się pojawia to:

Could not load file or assembly 'Microsoft.SharePoint.Library, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.

W poprzednim kroku przygotowaliśmy się już na taką okoliczność i z katalogu gdzie mamy nasze wszystkie biblioteki, wybieramy Microsoft.SharePoint.Library.dll i dodajemy ją jako referencję do projektu. W tym wypadku sprawa już nie jest taka prosta. Library* mimo iż dodana jako referencje do projektu, nie skopiuje się nam do katalogu wyjściowego a opcja ustawienia kopiowania jest wyszarzana.

* Czasami będę stosował skróty przy nazwach bibliotek zamiast podawać ich pełną nazwę - dla przykładu do Microsoft.SharePoint.dll będę się od nosił SharePoint, zaś do Microsoft.SharePoint.Library.dll jako Library. Kolizja znaczenia słów nie powinna nastąpić i z kontekstu powinno wynikać czy odwołuje się do SharePoint jako biblioteki czy do SharePoint jako oprogramowania.

03

Rozwiązanie jest dość proste, należy dodać bibliotekę do projektu ale tym razem jako i add existing item (Shift+Alt+A) lub po prostu przeciągnąć i upuścić ją na nazwie projektu. Następnie w opcjach (Alt+Enter na pliku) ustawiamy własność Copy to Output Directory na Copy always lub Copy if newer - spowoduje do skopiowanie biblioteki do katalogu w którym nasza aplikacja jest uruchamiana, dzięki czemu zostanie ona odnaleziona przez .NET Framework i załadowana.

04

Tym razem, jak uruchomimy aplikację (F5) pojawi nam się inny błąd (dość sporo jak na prosty przypadek):

The Web application at http://www.wssdemo.com/ could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.

W końcu jednak dochodzimy do czegoś, informacja wyraźnie mówi iż strona internetowa nie mogła zostać odnaleziona. Jeżeli jednak jesteśmy ciekawscy i posiadamy IntelliTrace, odkryjemy, że zanim został nam zwrócony wyjątek, wystąpił problem z odnalezieniem kolejnej biblioteki Microsoft.SharePoint.Security.dll:

05

Naprawienie błędu nie jest skomplikowane - wystarczy dodać referencję do Security. Jest to też ostatnia biblioteka o jaką SharePoint nas poprosi.

Od tej pory każde uruchomienia aplikacji będzie kończyło się wyświetleniem błędu, że strona nie została odnaleziona, zaś InteliiTrace podpowie nam, że także wystąpił problem z obiektem COMowym.

Retrieving the COM class factory for component with CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

06

Tutaj dochodzimy do sedna sprawy - dlaczego nie możemy korzystać z modelu obiektowego SharePoint na komputerze na którym SPS nie został zainstalowany. SharePoint wewnętrznie jest silnie związany z obiektami COM, które są rejestrowane w systemie podczas instalacji SPS. Jednym z takich obiektów jest obiekt odpowiedzialny za komunikację pomiędzy kodem zarządzanym a bazą danych. Jest on także podstawowym komponentem od kiedy istnieje SharePoint. Wrapperem na obiekt COM w bibliotece Microsoft.SharePoint.Library.dll jest obiekt SPRequest a dokładniej SPRequestInternalClass. SPRequest jest odpowiedzialny za wywoływanie metod dostępnych w SPRequestInernalClass oraz zarządzanie wyjątkami jakie mogą zostać zwrócone przez wykonanie metody na kodzie niezarządzanym. To co dostarcza nam biblioteka Microsoft.SharePoint.dll jest tak naprawdę ładnym (w porównaniu z wyżej wymienionymi klasami) opakowaniem na metody dostarczone przez SPRequest (których jest ponad 400 licząc Dispose). Dla przykładu, definicja metody odpowiedzialnej za dodanie lub aktualizację elementu na liście wygląda tak:

07

Raczej dużo programistów by nie pisała pod i bawiła się SharePointem gdyby musiała wywoływać tego typu metody.

Wszystkie te metody, są zaimplementowane w komponencie COM w pliku OWSSVR.dll. Komponent ten jest zarazem rozszerzeniem ISAPI do IIS, dzięki czemu umożliwia on komunikację bezpośrednią poprzez HTTP (http://[site_name]/_vti_bin/owssvr.dll) - oprogramowanie Office wykorzystuje to do komunikacji z SharePointem. Dokumentację jak wykorzystać OWSSVR.dll we własnej aplikacji można znaleźć tutaj: http://bit.ly/eV0GKb.

SharePoint i IIS. SharePoint integruje się ścisłe z IIS poprzez własną implementację HttpApplication (SPHttpApplication), HttpHandler (SharePointHandler) i HttpModule (SPRequestModule) do tego można dodać VirtualPathProvider (SPViertualPathProvider), PageParserFilter (SPPageParserFilter) i wiele innych klas, które umożliwiają SharePointowi działanie. Zrozumienie ich i sposobu ich działania jest poza częścią merytoryczną artykułu, każda dobra książka dotycząca programowania w SharePoint powinna zawierać informacje na ten temat - jedną z lepszych dla SharePoint 2007 była Inside Microsoft SharePoint Services 3.0 Teda Pattinsona. Niebawem powinna wyjść edycja dla SharePoint 2010 - informacja o tym jak SharePoint rozszerza IIS o nowe moduły będzie tam na pewno zawarta.

Z tego samego powodu z jakiego my nie jesteśmy wstanie się podłączyć do SharePointa w jednej linijce kodu, Visual Studio nie umożliwi nam pisania kodu pod SharePoint z wykorzystaniem szablonów projektów SharePointowych. Jeżeli byśmy chcieli spróbować stworzyć nowy projekt na przykład Web Part, otrzymamy następujący błąd:

A SharePoint server is not installed on this computer. A SharePoint server must be installed to work with SharePoint projects.

Oczywiście nie tylko to jest problemem przy szablonach w Visual Studio, jednak to uniemożliwia Visual Studio na komunikację z SharePoint z wykorzystaniem jego API z którego VS korzysta przy każdej zdarzającej się okazji jak na przykład Server Explorer (który umożliwia przeglądanie w postaci drzewa witryn SPS). SharePoint ma swoją specyficzną strukturę katalogów i odpowiednie wpisy w rejestrach, z których Visual Studio także korzysta - więc nawet gdyby nam się udało utworzyć projekt WebPart, to nie moglibyśmy go z deployować, a co dopiero debugować.

Zrozumienie tego iż prawie cała komunikacja pomiędzy naszym kodem a bazą danych odbywa się poprzez niezarządzane komponenty COM jest kluczowe do nie tylko zrozumienia jak działa SharePoint, dlaczego nasz kod musi być wykonywany na instancji maszyny z SPS zainstalowanym, ale także dlaczego tak ważne jest zarządzanie obiektami wrapperami w trakcie pisania kodu. Jak wiemy .NET zawiera garbage collector (GC), który odpowiedzialny jest za czyszczenie nieużywanych obiektów. Niestety działa on jedynie na kodzie zarządzanym, jeżeli kod zarządzany posiada zaalokowane zasoby w kodzie nie zarządzanym, kod ten jest odpowiedzialny za odblokowanie tych zasobów. GC nam w tym nie pomoże.

GC i .NET Framework. - zasady działa GC są poza merytoryką tego artykułu, dla chętnych polecam http://bit.ly/gbntaJ oraz artykuły w MSDN Magazine: http://bit.ly/g6wIew.

O SPRequest można przeczytać tutaj: http://bit.ly/qpYhRY, teraz jednak dobrze by było gdyby udało nam się w końcu uruchomić nasz prosty przykład. W tym celu musimy się przenieść z naszym kodem na maszynę na której zainstalowany jest SPS (jeżeli w momencie kiedy was poprosiłem przestaliście się bawić w pisanie i testowanie kodu, to teraz jest pora by do tego wrócić). Nie będziemy już potrzebować naszych własnych referencji do SharePoint, intl, Library i Security - można je więc wykasować wraz z dllkami. Oczywiście powinniśmy dodać referencje do SharePoint - jak pamiętacie znajduje się ona w 14 HIVE\ISAPI - wystarczy tylko i wyłącznie referencja do SharePoint, reszta bibliotek znajduje się w GAC i .NET Framework odnajdzie je kiedy będzie je potrzebował.

Przy uruchomieniu (F5) powinniśmy dostać po raz kolejny taki sam błąd jak poprzednio. Tym razem jego znaczenie do problemu ma się tak jak książka do klamki - nijak. Mianowicie, wszystkie nowe produkty serwerowe Microsoft są w wersji 64bitowej, zaś domyślnie console application ma ustawiony target na aplikacje 32bitowe. Microsoft zmienił to w wersji Visual Studio 2010, ze względu na to by programiści w końcu zaczęli na to zwracać uwagę, w Visual Studio 2008 domyślny target był na Any CPU co umożliwiało uruchamianie aplikacji zarówno na architekturze 64 jak i 32 bitowej. Ruch Microsoft był bardzo dobry, jednak jak to bywa, czasami po prostu zawodzi wykonanie. Tak jest i w tym przypadku. Zamiast dodać informację o problemie z target, dostajemy informacje, że strona nie istnieje. Poprawić to można na dwa sposoby:

  1. W Configuration Manager (Alt+B+O) należy dodać nową platformę bazującą na x86 - może to być zarówno x64 jak i Any CPU, następnie dla tej platformy należy zaznaczyć build dla naszego projektu;
  2. We właściwościach projektu (Alt+Enter na projekcie) przejść do zakładki Build i ustawić platform target na x64;

Różnica polega na tym iż jedno jest definiowane globalnie a drugie lokalnie. To znaczy, możemy mieć build dla platformy Any CPU, gdzie niektóre projekty będą posiadały platform target x86, inne x64 a jeszcze inne Any CPU. Problem jednak jest taki iż ustawienia platform target we właściwościach projektu należy ustawić dla wszystkich możliwych konfiguracji i platform, zaś kiedy korzystamy z Configuration Manager możemy to zrobić globalnie i mieć jedno miejsce dostępowe do ustawień projektu. Osobiście doradzam opcję pierwszą nad drugą.
Po dokonaniu zmiany platformy, wykonujemy kod jeszcze raz (F5) i otrzymujemy następny, obiecuje już, że przedostatni wyjątek, ale za to bardzo istotny:

An unhandled exception of type 'System.PlatformNotSupportedException' occurred in Microsoft.SharePoint.dll
Additional information: Microsoft SharePoint is not supported with version 4.0.30319.1 of the Microsoft .Net Runtime.

Tak jak z SharePoint 2007, Microsoft po raz kolejny nie nadążył ze zmianą .NET Framework, 2007 było napisane pod .NET Framework 2.0, zaś 2010 pod .NET Framework 3.5 (z SP1 - są pewne różnice pomiędzy wersją bez SP1, jak chociażby sposób działania Cast w LINQ). Powoduje to, że nie możemy korzystać z dobrodziejstw .NET 4.0 takich jak workflow 4 (podobno lepsza implementacja, przynajmniej maniacy SPS na to czekają z niecierpliwością), dynamic czy też optional parameters i co gorsza, nie ma na to obejścia.

SharePoint 2007 i .NET Framework 2.0. To dlaczego byliśmy wstanie wykorzystać SharePoint 2007 przez .NET Framework 3.5 było spowodowane CLR, które przez 3 wersje .NET (2, 3, 3.5) było w wersji 2.0. W .NET 4.0, uległa zmiana wersji CLR na 4.0 - informacje o wersjach zarówno VS jak i .NET można znaleźć tutaj: http://bit.ly/dYVLew. Ma to na pewno znaczenie przy ASP.NET, jednak dlaczego z aplikacji konsolowej tego zrobić nie można - nie jestem pewny, to znaczy nie chcę podać nie poprawnych informacji a jedynie spekulacje i domysły.

Wracając do wyjątku, to co dostajemy zwracane jest przez getter w klasie SPConfigurationDatabase zwracający obiekt SPFarm, kod który jest za to odpowiedzialny wygląda tak:

08

To tyle jeżeli chodzi o nie hardcodowanie pewnych własności.

Zmieniamy .NET Framework na .NET 3.5 i uruchamiamy aplikację (F5), naszym oczom powinien ukazać się już chyba znienawidzony wyjątek o niemożliwości znalezienia strony. Nagle też IntelliTrace przestał nam działać, to utrudni nam trochę analizę przyczyny błędu (IntelliTrace działa jedynie dla architektury 32bitowej, od wersji VS 2010 SP1 IntelliTrace już działa dla SharePoint 2010).
Przyczynę jednak łatwo jest odkryć gdy posiadamy SQL Profiler, możemy wtedy wyśledzić takie o to zapytanie:

09

wykonane na bazie konfiguracyjnej od SharePoint. Jeżeli wykonamy takie same zapytanie sami, to zobaczymy, że nic nam nie zostanie zwrócone, zrobienie zaś:

10

Powie nam iż nawet na pewno nie mamy tam takiej witryny. Jeżeli zmienimy adres na poprawny (nasz lokalny) to tym razem uda nam się uruchomić aplikację..

Podsumowanie

Dość sporo się działo do tego by wypisać jedną linijkę tekstu na konsolę, wiem, że proces mógł być trochę drażniący jednak był on bardzo wartościowy. Dzięki niemu mamy podstawę na której możemy budować naszą wiedzę i praktykę. To co omówiliśmy to:

  • Dlaczego SharePoint nie współpracuje z wersją Client Profile .NET Framework;
  • Dlaczego nie możemy wykorzystać modelu obiektowego z Microsoft.SharePoint.dll po stronie klienta;
  • OWSSVR jest sercem SharePointa, zaś wszystko to co znajduje się w Microsoft.SharePoint.dll można nazwać ładnym opakowaniem na zbiór ponad 400 metod;
  • Visual Studio 2010 podobnie jak nasza aplikacja konsolowa, też nie potrafi współpracować z SharePoint bez jego lokalnej instalacji;
  • SharePoint jak wszystkie najnowsze produkty serwerowe MS jest w wersji 64 bitowej, co musi być uwzględnione przez kod, który do niego się odwołuje.

By ułatwić sobie życie, można ściągnąć rozszerzenie CKS Dev dla SharePoint i Visual Studio (http://bit.ly/gXFJQM), które oprócz wielu przydatnych dodatków zawiera także szablon projektu Console Application, który ustawi za nas wszystkie wymagane właściwości, dzięki czemu nie będziemy musieli co projekt przechodzi przez komplet operacji - zmiana framework, zmiana platformy, dodanie referencji. Na pewno przyspieszy trochę nam pracę jak i oszczędzi niemiłych niespodzianek.

Autor: Jakub Gutkowski "Gutek"

 

Jakub Gutkowski

Ot gościu na którego SharePoint wpadł a on zaś nie wypadł - 5 lat zagubiony w labiryntach szuka wyjścia. Jego pasja trzymania się lewej strony w labiryncie została nie raz doceniona tytułem Microsoft MVP. Absolwent Polsko-Japońskiej Wyższej Szkoły Technik Komputerowych w Warszawie nie potrafiący zagrzać sobie miejsca, więc teraz grzeje – zdalnie bo mu tak łatwiej, raz w kawiarniach raz domu. Daje mu to okazję bawić się zawodowo różnymi technologiami (patrz. Microsoft) i wieloma językami (patrz. Microsoft), choć próbuje być cool i rubinem też się bawi.

tagi: Sharepoint

Komentarze 3

Michał Gołda
Michał Gołda
60 pkt.
Poczatkujacy
01-09-2011
oceń pozytywnie 0

Gratulacje Gutek, świetny artykuł!!!

MCP, MCAD, MCTS Web Developer, MCPD

Tobiasz Janusz Koprowski Ekspert WSS
Tobiasz Janusz Koprowski
787 pkt.
Senior
MVP
02-09-2011
oceń pozytywnie 0

Pierwszy artykuł i od razu z grubej rury. Ciekawe i inspirujące. Grats!

Anorak

Microsoft Registered User No 497509
Some Certification successed. Some others... still in progress
-----
Find a Better Way of Life
[ GITCA ] | [ PASS ] | [ BLOG ] | [ BLOG ]

Grzegorz Skorupa
Grzegorz Skorupa
25 pkt.
Nowicjusz
07-09-2011
oceń pozytywnie 0

Szacun! Czekamy na więcej...

Grzegorz Skorupa MCT, ITILv2/3, CA SiteMinder, MCITP, MCSE2003+S

pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.