Microsoft zaprezentował Visual Studio for Applications - próbną wersję pakietu do tworzenia własnego zintegrowanego środowiska skryptowego.

Dostosowanie gotowej aplikacji do wymagań klienta wiąże się zazwyczaj z dużymi przeróbkami albo wręcz wymianą całych modułów. Niekiedy klient żąda, by wraz z programem dostarczyć te, które pozwolą mu samodzielnie modyfikować aplikację. Wyzwaniem dla programistów będzie też integracja napisanej przez nich aplikacji z innymi systemami informatycznymi działającymi w firmie klienta. W takich sytuacjach producenci oprogramowania uciekają się do mniej lub bardziej udanych implementacji języków skryptowych, gdzie obok "głównej" aplikacji istnieje zwykle bardzo dużo linii kodu, który korzystając z gotowych elementów "skleja" aplikację oferowaną klientowi.

Elastyczne środowiska

Microsoft dotychczas proponował dwa rozwiązania - Windows Scripting Host (WSH) i Visual Basic for Application (VBA). WSH miał za zadanie automatyzować pewne operacje w systemie. VBA to natomiast pełne środowisko przez- naczone do tworzenia makr i własnych rozwiązań opartych na aplikacjach biurowych. VBA jest wykorzystywane w MS Office (po raz pierwszy pojawiło się w Excelu w 1993 r.) i w ponad 250 innych systemach, których producenci licencjonują tę technologię od Microsoftu.

Obszar zastosowań WSH częściowo pokrywał się z obszarem zastosowań VBA. Co prawda VBA jest mechanizmem znacznie większego "kalibru" niż WSH (ma małe wymagania), ale jednocześnie znacznie wygodniejszym. W przypadku gdy producent aplikacji chciał udostępnić oba mechanizmy, musiał tworzyć dwa typy interfejsów, bardzo podobnych funkcjonalnie, ale różnych pod względem implementacyjnym.

Nowy Visual Studio for Applications (VSA) ma dwa główne zastosowania. Po pierwsze, jest idealnym narzędziem do osadzania w aplikacji funkcji "programowania", czyli mówiąc ogólniej, dostosowania do własnych potrzeb gotowych programów. Klient, wraz z aplikacją, otrzymuje gotowe środowisko, w którym może dostosować dokładnie przepływ danych w warstwie logiki biznesowej czy ustalić własne metody raportowania. Po drugie, firma tworząca aplikacje może część związków, zwłaszcza pomiędzy obiektami w logice biznesowej, oprzeć na wydajnym motorze VSA.

Wykonywanie kodu przygotowanego w VSA składa się z kilku etapów. Najpierw tworzona jest instancja obiektu, który jest "motorem" VSA. Równocześnie określa się język skryptowy. Następnie wczytywany jest kod, który dostosowuje aplikację. VSA pozwala, by kod był związany z konkretnymi wersjami interfejsów udostępnianymi przez obiekty biznesowe lub był wręcz powiązany z określoną wersją aplikacji. Możliwe jest też, aby motor wczytywał odpowiedni kod w zależności od danych klienta, który kupił produkt!

Następnie do motoru VSA dodawane są obiekty biznesowe, z których kod może korzystać, np. źródło zdarzeń czy obiekt odpowiedzialny za przeprowadzanie transakcji finansowych. Dopiero tych obiektów może używać kod VSA.

Język .NET

Trudności, jakie napotykali programiści stosujący WSH z VBScript czy VBA, wynikały z tego, że tak naprawdę były to języki tylko "podobne" do Visual Basic. VBA bardziej przypominał Visual Basic, ale już w VBScript brakowało wielu elementów, jak chociażby jawnego deklarowania zmiennych danego typu.

Obecnie VSA wykorzystuje ten sam język co Visual Basic.NET, (prawdopodobnie będą dostępne także inne języki .NET, a na pewno zostanie opublikowana specyfikacja "podłączania" nowych języków). Co więcej, nie mamy do czynienia z językami interpretowanymi - VSA przed wykonaniem kompiluje kod "dostosowujący" aplikację, co sprawia, że nie ma dużej różnicy w prędkości działania pomiędzy rozwiązaniami opartymi na VSA a wkompilowanymi w kod aplikacji.

VSA jest motorem "skryptowym", który w pełni korzysta z możliwości platformy .NET, w tym z bardzo silnej kontroli praw dostępu, nawet na poziomie blokady poszczególnych klas API. Wydaje się, że tworzenie wirusów, które będą korzystały z motoru VSA, stanie się znacznie trudniejsze (a może wręcz niemożliwe) niż w przypadku Windows Scripting Host, gdzie z punktu widzenia systemu operacyjnego plik z odpowiednim rozszerzeniem był jeszcze jednym plikiem wykonywalnym, a zabezpieczenia można było wprowadzić tylko na poziomie źródła pochodzenia pliku.

VSA może korzystać z dowolnego elementu .NET, w tym z mechanizmów wielowątkowych, zdalnego wywoływania obiektów czy komunikacji opartej na SOAP. W VSA można "reagować" na zdarzenia zgłaszane przez obiekty biznesowe. Praktycznie nie ma ograniczeń dotyczących wielkości rozwiązań itp. Takie ograniczenia istniały w VBA.

Środowisko pracy

Podobnie jak w VBA, zintegrowane środowisko IDE Visual Studio for Application może albo stanowić część okien aplikacji, albo być uruchomione jako oddzielna aplikacja. Należy podkreślić, że można "odchudzić" aplikację i szybko usunąć mechanizmy służące do edycji kodu VSA.

Po stronie aplikacji - hosta VSA - wymagane jest, by zapewniała ona właściwy interfejs (ICodeProvider) do zapisania kodu wprowadzonego w VSA. Mechanizm zapisywania jest oparty na modelu strumieniowym i dla programisty wykorzystującego VSA zupełnie nie ma znaczenia, gdzie jego kod jest zapisywany. IDE przypomina środowisko Visual Studio.NET z debuggerem, edytorem i narzędziami do graficznego projektowania interfejsu.

Beta SDK dla VSA ma być dostępna wiosną 2001 r. Wersja ostateczna zostanie opublikowana niemal równocześnie z Visual Studio.NET.