17 października 2011

Obudziłem się z ręką w piaskownicy SharePoint'a

Kontakty trzeciego stopnia z Sandbox Solutions


Microsoft w SharePoint 2010 zaproponował nowy sposób wdrażania i uruchamiania komponentów SharePoint'a, który nazywa się Sandbox Solutions (z angielskiego Sandbox to piaskownica). Sandbox Solutions są to "normalne" pliki CAB z rozszerzeniem .wsp, tak jak stare dobre Farm Solutions. Zasadnicza różnica polega na tym, że Sandbox Solutions (SS) mogą być wdrażane na poziomie Site Collection i na poziomie farmy, a Farm Solutions mogą być wdrażane tylko na poziomie farmy SharePoint'a. Docelowo najbardziej pożądanym miejscem dla  SS jest Site Collection.

SharePoint udostępnia oddzielne środowisko uruchomieniowe dla kodu z Sandbox Solutions w postaci oddzielnego procesu (Sandbox Worker Process). Całe środowisko jest tak skonstruowane, że udostępnia tylko część SharePoint API do którego ograniczono dostęp poprzez wprowadzenie Sandbox Proxy Worker Process.  Sandbox Woker Process komunikuje się z Proxy w momencie gdy chce wywołać jakąś metodę lub klasę z Microsoft.SharePoint.dll.  Ładny obrazek architektury SS można zobaczyć tutaj.

Taka architektura ma swoje następstwa. Ograniczono możliwość korzystania praktycznie ze wszystkich pozostały bibliotek SharePoint'a. Powód tego jest prostym, często wymagają one dostępu poza Site Collection np. do Web Application i jest to sprzeczne z architekturą Piaskownicy.


TypeLoadException


Wyobraźmy sobie WebPart, który jest częścią Sandbox Solution. Nie może on skorzystać w kodzie zarządzalnym z Shared Service Applications (np. Manage Metadata Service odpada). Co więcej nie może pobrać nawet kontektu klasy SPServiceContext, gdyż otrzyma wyjątek TypeLoadException. Trudno sobie to wyborazić, ale pozostaje korzystanie z podzbioru Microsoft.SharePoint.dll. Ograniczenia są ładnie opisane w poniższych artykułach, ale aż trudno w nie uwierzyć do momentu aktywacji solution i wyświetlenia np. webpart'a z błędem. Dla przykładu Microsoft.SharePoint.Taxonomy.dll nie jest oznaczony AllowPartiallyTrustedCallers atrybutem i nie można go załadować do Piaskownicy.


Microsoft.SharePoint.dll APIs That Are Available from Sandboxed Solutions 
What Can Be Implemented in Sandboxed Solutions in SharePoint 2010
Available and Unavailable .NET Assemblies from Sandboxed Solutions 
Available and Unavailable SharePoint Assemblies from Sandboxed Solutions
Restrictions on Sandboxed Solutions in SharePoint 2010

Innym scenariuszem gdzie znacząco odczujemy ograniczenia Piaskownicy jest logowanie w sensie zapisu trace'u.  API Developer Dashboard'u, ULS (Unified Logging Service) są niedostępne, czyli w Piaskownicy zapomnij o tym co przeczytałeś o logowaniu. Pozstaje SharePoint Sandbox Logging, ale to rozwiązanie pozostawiam bez komentarza.

 

Obejścia, czyli drugie oblicze Piaskownicy


Pierwszą możliwością objeścia ograniczeń SS jest użycie Full-trust proxy. Polaga ono na implementacji klasy, która udostępnia bardzo prymitywny interfejs. Bazuje on na metodzie przyjmującej nazwę operacji oraz argument i zwracającej obiekt. Rejestracja proxy wymaga dostępu administracyjnego do farmy SharePoint'a, czyli odpada np. w większości planów SharePoint Online.

Innym sposobem jest korzystanie z Client Object Model, pod każdą możliwą postacią, czyli JavaScript, Silverlight, Managed code. W praktyce sprowadza się to do kodowanie w JavaScript'cie, użyciu jQuery i intensywnym reverse enginnering Web Service'ów SharePoint'a (polecam zapoznać się z projektem jQuery Library for SharePoint Web Services).

Microsoft tylnymi drzwiami wprowadził Visual Studio 2010 SharePoint Power Tools. Jest to bardzo ubogi zestaw narzędzi do walki z Sandbox Solutions, umożliwia on tworzenia np. Visual WebPart dla SS (nie wspominałem, że nie można nic dodawać do katalogu 14-hive zatem odpadają User Control i nie tylko). Z tym zestawem "toolsów" miałem pewną przygodę. Pisałem pierwszego w życiu WebPart'a, który miał być częścią Sandbox Solution. W momencie gdy chciałem zaimplementować jakąś funkcjonalność, to kończyło się pisaniem JavaScript'u, w pewnym momencie dostałem błąd przy kompilacji paktycznie pustego code behind.

Microsoft.VisualStudio.SharePoint.Commands.CommandParameter. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. )
I myślę sobie, kurka ... okazało się, że mój plik ascx przekroczył 8Kb tekstu i dostałem coś takiego.



Warnining, który powoduje błąd kompilacji. Po przerzuceniu kilku linijek JavaScript'u do odzielnego pliku wszystko wróciło do normy. Spodziewam się więcej tego typu przygód w przyszłości.

What's hot, what's not? I dlaczego Piaskownica może być hot?


Piaskownica została wymyślona na potrzeby Office 365 i żeby administratorom żyło się lepiej. SharePoint Online na chmurze daje spore możliwości zaistnienia na rynku produktów. W tym momencie jak ktoś ma pomysł, to można wykorzystać tą jeszcze "przez moment niszę" i wyprodukować jakieś cudo polskiej myśli inżynierskiej.

Poza tym Sandbox wymusza pisanie bezpiecznego oprogramowanie, dlatego, że RunWithElevatedPrivileges odeszło do lamusa. Cały czas działamy w kontekście użytkownika, czyli musimy pisać oprogramowanie działające z różnymi zestawami uprawnień, a nie tylko Elevate i do domu....

Pewnym problemem z adaptacją SharePoint'a Online może być to, że w aktualnej wersji SO Microsoft zapomniał napisać provider'a do PowerShell'a (a do Exchange'a napisał). Konsekwencją tego jest to, że wdrożenie pliku wsp na Site Collection będzie zautomatyzowane ręczną aktywacją :).

Ogólnie nie jest łatwo w Piaskownicy, ale w dzieciństwie też nie było łatwo. Zatem trzeba zakasać rękawy i do roboty.

Brak komentarzy:

Prześlij komentarz

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.