Od kiedy wyszedł SharePoint 2007 i moje środowisko developerskie zostało podzielone na dwa komputery, zacząłem szukać sposobów ułatwiających sobie pracę. Jednym z głównych problemów, które zwalczałem był deployment assemblies do GAC.

Na samym początku tworzyłem sobie skrypty na post build action w VS, tak by kopiowały mi wszystko na SharePoint a tam miałem ustawiony Windows JOB (w późniejszym okresie Windows service), który mi deployował moje DLLki do GAC jak tylko zostały one wgrane do określonego przeze mnie katalogu. Ogólnie chciałem osiągnąć maksymalnie dużo bez konieczności wchodzenia na serwer i kopiowania ręcznego elementów – każdy kto kiedykolwiek programował na SharePoint wie o czym mówię, średnio traci się jedną do dwóch godzin dziennie na deployment elementów.

Minusem tego rozwiązania była nie tylko usługa sama w sobie, którą trzeba było zainstalować na komputerze docelowym, ale także konieczność zainstalowania gacutil. Tak jak miałem możliwość wpłynięcia na środowisko developerskie by gacutil był tam zainstalowany wraz z dostarczoną mi maszyną, tak moją usługę musiałem instalować już ręcznie.

Wtedy też znalazłem narzędzie PsExec napisane przez SysInternals, które umożliwia wykonywanie poleceń command line zdalnie. Dzięki temu za pomocą komendy:

PSExec MyServer "C:Program FilesMicrosoft SDKsWindowsv6.0binGACUtil.exe" "C:binMyAssembly.dll"

(ścieżki odpowiadają ścieżką lokalnym na serwerze MyServer), byłem wstanie dzięki odpowiednio stworzonemu Post Build Action zainstalować swoją konkretną DLL w GAC a następnie wykonać reset app pool.

Ostatnio zaś natrafiłem na projekt Remote Gacutil (Remote GAC Manager), który nie tylko umożliwia instalowanie DLLek na komputerze zdalnym ale także nie wymaga by komputer posiadał narzędzie GACUtil.

Aplikacja ta, wykorzystuje PsExec do wykonania operacji na serwerze zdalnym, przyczym ona w sama w sobie zawiera narzędzie GACUtil. Standardowo jest to aplikacja okienkowa, gdzie wszystkie operacje jak instalowanie/odinstalowywanie oraz pobieranie DLL z GAC wykonywane jest z okna aplikacji:

gac

Jednakże znów, operacja instalacji wymagała odpalenia aplikacji i dokonania zmian ręcznie. To nie załatwiało tego, co chciałbym osiągnąć. Więc pobrałem sobie jej kod źródłowy i zmodyfikowałem EntryPoint tak by akceptował on parametry z linii poleceń, zarówno do instalacji jak i odinstalowywania DLLek, z modyfikowana funkcja wygląda następująco:

/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
    if(args.Length == 3)
    {
        // server na którym ma być zainstalowana DLLka
        string server = args[1];
        // pełna ścieżka do assembly
        // lub assembly full name
        // BDATunePIA, Version=6.1.0.0, Culture=neutral,
        // PublicKeyToken=31bf3856ad364e35,
        // processorArchitecture=x86
        string assembly = args[2];
 
        if(args[0] == "i")
        {
            new GacUtil(server).Install(assembly);
        }
        else if(args[0] == "u")
        {
            new GacUtil(server).Uninstall(assembly);
        }
    }
 
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new MainForm());
}

I to wszystko! :) Od teraz za pomocą prosty Post Build Actions jestem wstanie z deployować całą swoją aplikację na serwer bez konieczności logowania się na niego.

Plusem tego rozwiązania jest to, iż jest ono ustawiane per project a nie per komputer!

A wy jak sobie radzicie z problemem remote deploymentu?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

4 KOMENTARZE

  1. Teraz pracuje na Windows 2008 i żeby sprawdzać rozwiązanie mogę od razu u siebie – skrypty w VS wystarczają.
    Jeśli chodzi o przerzucanie do klienta to w początkowym etapie może wystarczyć bin. Na komputerze docelowym udostępniam katalog bin aplikacji. Dodatkowym plusem jest to ze wgrywając do bin’a aplikacja się restartuje.

  2. Pracuje na win2003 wiec post build action sam wrzuca do GACa. Jak natomiast radzisz sobie z debugowaniem swoich rozwiazan na zdalnym serwerze? Byc moze niedlugo zmienie XP+Win2003 na viste i sprobuje tam zainstalowac Sharepointa – jakies doswiadczenia z takiego srodowiska developerskiego?

  3. @Kola and @maw

    Mowilem o sytuacji kiedy nie ma VS na komputerze z SharePoint. Czyli macie dwa komputery, jeden do dev a drugi z SharePoint.

    Majac ten sam komputer na DEV i SharePoint to w ogole nie ma problemu i praca jest przyjemna :)

    Jedyny mankament Windows 2008 jest taki iz w zaleznosci od uprawnien bedzie mozna przezucic DLL do GAC recznie lub nie – ale to samo jest z Vista.

    @Kola

    BIN jest spoko, jednakze znow :) nie zawsze… wszystko zalezy od tego jaki kod piszesz i co on ma wykonywac.

    @maw

    Nie korzystam z Visty jako dev env. To znaczy mam zainstalowany VS i wszystko i wrazie co jestem wstanie cos napisac, ale SharePoint tak czy siak stoi na maszynie wirtualnej.

    Ostatnio nawet bardzo mi sie spodobal pomysl maszyn wirtualnych przygotowanych przez MS, w szczegolnosci tej najnowszej:

    http://www.microsoft.com/downloads/details.aspx?familyid=1beeac6f-2ea1-4769-9948-74a74bd604fa&displaylang=en

    zrobilem na niej bezposrednio 2 projekty po godzinach.

    Jednakze w pracy mam srodiwsko tak jak opisalem: dwa kompy.

    Co do debugowania. Mam napisana aplikacje ktora wrzuca mi do odpowiednich katalogow w GAC moje pliki PDB (nie zastanawialem sie nad tym czy mozna je gdzie indziej umieszczac, jezeli tak to dajcie znac) zas na serwerze jest remote debugger zainstalowany. To calkowicie wystarcza.

    Gutek

  4. @maw
    Jeśli chodzi o debugowanie to teraz rzadko to robię. Głównie loguje sobie błędy z aplikacji. Do logowania stworzyłem już sobie mechanizm który w przypadku wystąpienia błędu zakłada listę Logger i tam zapisuje wyjątek itp. Oczywiście lista jest czyszczona itp.

    @Gutek
    Co do przerzucania do GAC w Windows 2008 faktycznie dużo się namęczyłem żeby ustawić uprawnienia. Jednak teraz już to działa ;)

Comments are closed.