W ramach najnowszej aktualizacji platformy Dataverse Microsoft umożliwił nam rejestrowanie i uruchamianie kodu znajdującego się wewnątrz pakietów NuGet (pliki: nupkg). Co właściwie nam to daje? Do tej pory – programiści tworzący rozszerzenia do systemy za pomocą bibliotek .NET skazani byli na umieszczanie całości rozwiązania w pojedynczym pliku lub korzystania z narzędzi w rodzaju: ILMerge lub Fody/Costura. Zastosowanie pakietu *.nupkg daje nam możliwość umieszczenia w jego wnętrzu wielu bibliotek, np. pobranych za pomocą galerii NuGet lub znajdujących się w tym samym rozwiązaniu Visual Studio, w którym znajduje się projekt pluginów.
Każdy programista korzystający z Dataverse zakrzyknie zapewne w tym momencie: „W końcu!”. Żegnajcie narzędzia do łączenia bibliotek! Żegnajcie współdzielone projekty Visual Studio lub mikroserwisy, których jedynym zadaniem jest pośrednictwo (proxy) dla wywołań zewnętrznych bibliotek.
Z korzyści, które daje nam rejestrowanie wewnątrz Dataverse pakietów NuGet chciałem skorzystać i ja! Po ściągnięciu najnowszych wersji Plugin Registration Toola oraz Power Platform CLI uruchomiłem Visual Studio i korzystając z instrukcji umieszczonej pod adresem Dependent Assembly plug-ins (preview) (Microsoft Dataverse) – Power Apps | Microsoft Docs rozpocząłem development swojego pierwszego pakietu rozszerzeń. Cały proces przebiegł wybitnie sprawnie, a wynikowy pakiet zawierający kompletne rozwiązanie został utworzony automatycznie po zakończeniu buildu aplikacji z poziomu Visual Studio.
Przy wdrożeniu wspomnianego pakietu napotkałem natomiast na 2 niewielkie problemy, o których chciałbym w tym miejscu wspomnieć. Mam nadzieję, że oszczędzi to Wam nieco czasu, który musielibyście spędzić na samodzielnych poszukiwaniach ich rozwiązań.
Uno…
Wbrew temu, co Microsoft twierdzi w swojej dokumentacji – biblioteki (assembly) wchodzące w skład pakietu powinny być podpisane kluczem (strong name key). W przypadku bibliotek niepodpisanych – środowisko uruchomieniowe Dataverse nie będzie w stanie wywołać kodu znajdującego się w takiej bibliotece. Tak przynajmniej stało się w czasie moich testów.
Duo…
Domyślny szablon projektu pluginów, utworzony za pomocą Power Platform CLI, zawiera referencję do pakietu Microsoft.CrmSdk.CoreAssemblies. Ma to sens , ale powoduje, że do NuGeta tworzonego po zakończeniu procesu kompilacji trafiają biblioteki Microsoft.Xrm.Sdk.dll oraz Microsoft.Crm.Sdk.Proxy.dll. Próba rejestracji takiego pakietu zakończy się niestety następującym błędem:
Plugin Package update Failed: PluginPackage can not contain Microsoft.CrmSdk.CoreAssemblies. Assembly found Microsoft.Xrm.Sdk, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 in the package (mscorlib)
Powyższy problem możemy rozwiązać na 2 sposoby. Pierwszy z nich polega na ręcznym usunięciu z pakietu biblioteki Microsoft.Xrm.Sdk. Druga z wymienionych powyżej bibliotek, nie wiedząc czemu, nie stanowi problemu. Metoda ta jest oczywiście mocno upierdliwa, ponieważ proces należy powtarzać za każdym razem przed aktualizacją pakietu w systemie. Oczywiście operacje możemy zautomatyzować za pomocą np. skryptu PowerShell, ale jest to jednak podejście mocno toporne.
Drugi, „lepsiejszy” w moim przekonaniu sposób polega na modyfikacji pliku projektu rozszerzeń (*.csproj) i dodaniu do referencji pakietu Microsoft.CrmSdk.CoreAssemblies parametru PrivateAssets o wartości „All”:
Po dodaniu ww. linii oraz ponownym zbudowaniu projektu ww. biblioteki nie znalazły się już w zbudowanym pakiecie, a jego rejestracja oraz uruchomienie znajdującego się wewnątrz niego kodu przebiegły bez żadnych dodatkowych problemów.
