Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
SolutionPackager to narzędzie, które może odwracalnie dekomponować skompresowany plik rozwiązania Microsoft Dataverse na wiele plików XML i inne pliki. Następnie można łatwo zarządzać tymi plikami, używając systemu kontroli źródła. W poniższych sekcjach przedstawiono sposób uruchamiania narzędzia oraz korzystania z niego podczas pracy z rozwiązaniami zarządzanymi i niezarządzanymi.
Ważne
Narzędzie SolutionPackager nie jest już zalecanym sposobem rozpakowywania i pakowania rozwiązań. Możliwości narzędzia SolutionPackager są włączone do interfejsu wiersza polecenia platformy Power Platform. Polecenie pac solution zawiera wiele czasowników, w tym unpack, pack, clone, i sync, które korzystają z tych samych podstawowych możliwości narzędzia SolutionPackager.
Gdzie znaleźć narzędzie SolutionPackager
Narzędzie SolutionPackager jest dystrybuowane w ramach Microsoft.CrmSdk.CoreTools pakietu NuGet. Aby zainstalować program, wykonaj następujące kroki.
- Pobierz pakiet NuGet.
- Zmień rozszerzenie nazwy pliku pakietu z .nupkg na .zip.
- Wyodrębnij zawartość ze skompresowanego pliku (ZIP).
Znajdź plik wykonywalny SolutionPackager.exe znajdujący się w folderze <nazwa-wyodrębnionego-folderu>/contents/bin/coretools. Uruchom program z folderu coretools lub dodaj ten folder do ścieżki.
Argumenty wiersza polecenia narzędzia SolutionPackager
SolutionPackager to narzędzie wiersza polecenia, które można wywołać przy użyciu parametrów wskazanych w poniższej tabeli.
| Argument | opis |
|---|---|
| /action: {Wypakuj|Spakuj} | Wymagane. Akcja, która ma zostać wykonana. Akcją może być wyodrębnienie pliku ZIP rozwiązania do folderu lub spakowanie go do pliku ZIP. |
| /zipfile: <ścieżka do pliku> | Wymagane. Ścieżka i nazwa pliku rozwiązania w formacie .zip. Podczas wyodrębniania plik musi istnieć i być czytelny. W przypadku pakowania plik zostaje zastąpiony. |
| /folder: <ścieżka do folderu> | Wymagane. Ścieżka do folderu. Podczas wyodrębniania ten folder jest tworzony i wypełniany za pomocą plików składników. W przypadku pakowania folder musi już istnieć i zawierać uprzednio wyodrębnione pliki składników. |
| /packagetype: {Unmanaged|Managed|Both} | Opcjonalny. Typ pakietu do przetworzenia. Wartość domyślna to "Niezarządzane". Ten argument może być pominięty w większości przypadków, ponieważ typ pakietu można odczytać z pliku ZIP lub plików składników. W przypadku wyodrębniania i wybrania wartości Oba pliki ZIP rozwiązań zarządzanych i niezarządzanych muszą być obecne i przetwarzane w jednym folderze. W przypadku pakowania i wybrania opcji Oba, pliki .zip rozwiązań zarządzanych i niezarządzanych są tworzone z jednego folderu. Aby uzyskać więcej informacji, zobacz sekcję dotyczącą pracy z rozwiązaniami zarządzanymi i niezarządzanymi w dalszej części tego artykułu. |
| /allowWrite:{Tak|Nie} | Opcjonalny. Wartością domyślną jest Tak. Ten argument jest używany tylko podczas wyodrębniania. Jeśli zostanie wybrana wartość /allowWrite:Nie, narzędzie wykona wszystkie operacje, ale nie będzie mogło zapisać ani usunąć żadnych plików. Operację wyodrębnienia można bezpiecznie ocenić, nie zastępując ani nie usuwając żadnego istniejącego pliku. |
| /allowDelete:{Yes|No|Prompt} | Opcjonalny. Wartość domyślna to Monit. Ten argument jest używany tylko podczas wyodrębniania. Jeśli zostanie wybrana wartość /allowDelete:Tak, wszystkie pliki obecne w folderze określonym przez parametr /folder, które nie są oczekiwane, są usuwane automatycznie. Jeśli zostanie wybrana wartość /allowDelete:Nie, żadne operacje usuwania nie będą wykonywane. Jeśli zostanie wybrana wartość /allowDelete:Prompt, użytkownik jest monitowany przez konsolę o zezwolenie lub odrzucenie wszystkich operacji usuwania. Jeśli zostanie wybrana wartość /allowWrite:Nie, żadne operacje usuwania nie zostaną wykonane, nawet w przypadku wybrania również wartości /allowDelete:Tak. |
| /clobber | Opcjonalny. Ten argument jest używany tylko podczas wyodrębniania. W przypadku określenia wartości /clobber pliki, które mają ustawiony atrybut tylko do odczytu, są zastępowane lub usuwane. Kiedy nie zostaną określone, pliki z atrybutem tylko do odczytu nie zostaną zastąpione ani usunięte. |
| /errorlevel: {Off|Error|Warning|Info|Verbose} | Opcjonalny. Wartość domyślna to Informacje. Ten argument wskazuje poziom rejestrowania informacji w danych wyjściowych. |
| /map: <ścieżka pliku> | Opcjonalny. Ścieżka i nazwa pliku XML zawierającego dyrektywy dotyczące mapowania pliku. Podczas użycia tego argumentu w trakcie wyodrębniania pliki, które zazwyczaj są odczytywane z folderu określonego przez parametr /folder, są odczytywane z lokalizacji alternatywnych zgodnie ze wskazaniami pliku mapowania. Podczas operacji pakietu pliki zgodne z dyrektywami nie są zapisywane. |
| /nologo | Opcjonalny. Zablokuj baner podczas działania. |
| /log: <ścieżka pliku> | Opcjonalny. Ścieżka i nazwa pliku dziennika. Jeśli plik już istnieje, nowe informacje o rejestrowaniu są dołączane do pliku. |
| @ <ścieżka pliku> | Opcjonalny. Ścieżka i nazwa pliku, który zawiera argumenty wiersza polecenia dla narzędzia. |
| /sourceLoc: <ciąg> | Opcjonalny. Ten argument powoduje wygenerowanie pliku zasobów szablonu i jest ważny tylko w przypadku wyodrębniania. Dopuszczalne wartości to auto lub kod identyfikatora LCID/ISO dla języka, który ma być eksportowany. W przypadku korzystania z tego argumentu zasoby ciągów z podanych ustawień regionalnych są wyodrębniane jako neutralny plik RESX. W przypadku wybrania wartości auto albo długiej lub krótkiej postaci przełącznika są używane podstawowe ustawienia regionalne lub rozwiązanie. Możesz użyć krótkiej postaci polecenia: /src. |
| /localize | Opcjonalny. Wyodrębnij lub połącz wszystkie resursy tekstowe w plikach .resx. Możesz użyć krótkiej postaci polecenia: /loc. Opcja lokalizacji obsługuje udostępnione składniki dla plików resx. Więcej informacji: Używanie zasobów RESX sieci Web |
| /SolutionName: <nazwa> | Opcjonalny. Unikatowa nazwa rozwiązania do spakowania lub wyodrębnienia, gdy folder źródłowy zawiera wiele rozwiązań w obszarze solutions/*/solution.yml. Wymagane w przypadku wykrycia więcej niż jednego rozwiązania. Dotyczy tylko formatu kontroli źródła YAML. Możesz użyć krótkiej formy polecenia: /sn. |
| /remapPluginTypeNames | Opcjonalny. Po określeniu w pełni kwalifikowane nazwy typów dodatków plug-in są ponownie mapowane na podstawie zestawów zawartych w rozwiązaniu. Opcja domyślnie włączona w formacie kontroli źródła YAML. Możesz użyć krótkiej formy polecenia: /fp. |
Formaty plików kontroli źródła
SolutionPackager obsługuje dwa układy folderów podczas wyodrębniania i pakowania rozwiązań.
Format XML (starsza wersja)
Oryginalny format. Metadane rozwiązania są przechowywane w Other\Solution.xml i Other\Customizations.xml, a wszystkie pliki składników są wyodrębniane do płaskiej hierarchii folderów wraz z tymi plikami. Ten format jest formatem domyślnym podczas eksportowania pliku bez dodatkowej konfiguracji.
Format kontroli źródła YAML
Wprowadzony wraz z integracją usługi Dataverse z usługą Git ten format przechowuje metadane rozwiązania jako pliki YAML dystrybuowane w hierarchii folderów strukturalnych. Jest to format napisany podczas zatwierdzania rozwiązań przy użyciu natywnej integracji git w Power Apps.
Zalety w porównaniu z formatem XML
- Tworzy bardziej czytelne różnice poszczególnych składników w kontroli źródła
- Obsługuje wiele rozwiązań w jednym folderze repozytorium
- Pliki
.msappaplikacji kanwy i nowoczesne przepływy są obsługiwane tylko w tym formacie - Ponowne mapowanie nazwy typu wtyczki jest domyślnie włączone
Wymagana struktura folderów
<rootFolder>/
├── solutions/
│ └── <SolutionUniqueName>/
│ ├── solution.yml (solution metadata)
│ ├── solutioncomponents.yml (paths to all component files)
│ ├── rootcomponents.yml (root-level components)
│ └── missingdependencies.yml (dependency info)
├── publishers/
│ └── <PublisherUniqueName>/
│ └── publisher.yml (publisher definition)
├── entities/ (entity components, if present)
├── workflows/ (classic workflows, if present)
├── modernflows/ (Power Automate cloud flows, if present)
├── canvasapps/ (canvas app .msapp files, if present)
└── [other component folders]/
Ważne
Format YAML jest automatycznie wykrywany przez obecność podfolderu zawierającego solutions/*solution.yml pliki.
Jeśli pliki manifestu YAML (solution.yml, solutioncomponents.ymli tak dalej) są umieszczane w katalogu głównym folderu, a nie w obszarze solutions/<SolutionUniqueName>/, narzędzie nie wykrywa formatu YAML. Narzędzie wraca do ścieżki XML i zgłasza mylący błąd dotyczący brakującego Customizations.xmlelementu . Zobacz Rozwiązywanie problemów , aby uzyskać informacje na temat rozwiązywania tego problemu.
Więcej informacji: Dokumentacja formatu YAML dla systemu kontroli wersji rozwiązania
Formatowanie reguł automatycznego wykrywania
| Warunek | Używany format |
|---|---|
solutions/*/solution.yml found — dokładnie jedno rozwiązanie |
Format YAML, w którym nazwa rozwiązania jest wywnioskowana z folderu |
solutions/*/solution.yml znaleziono — wiele rozwiązań |
Format YAML, w którym /SolutionName argument jest wymagany |
Brak solutions/ podkatalogu |
Format XML (starsza wersja) |
Pakowanie folderu formatu YAML
Następujące polecenie pakuje folder formatu YAML.
SolutionPackager.exe /action:Pack /zipfile:MySolution.zip /folder:C:\repos\myrepo
Pakowanie z folderu zawierającego wiele rozwiązań
Następujące polecenie pakuje określone rozwiązanie w folderze z wieloma rozwiązaniami.
SolutionPackager.exe /action:Pack /zipfile:SolutionA.zip /folder:C:\repos\myrepo /SolutionName:SolutionA
Używanie argumentu polecenia /map
W poniższym omówieniu przedstawiono szczegółowo użycie argumentu /map w narzędziu SolutionPackager.
Pliki utworzone w zautomatyzowanym systemie kompilacji, takie jak pliki .xap Silverlight oraz zestawy dodatków, zazwyczaj nie są ewidencjonowane w kontroli źródła. Zasoby internetowe mogą już być obecne w kontroli źródła w lokalizacjach, które nie są bezpośrednio zgodne z narzędziem SolutionPackager. Dołączając parametr /map, można przekierować narzędzie SolutionPackager tak, aby odczytywało i pakowało takie pliki z lokalizacji alternatywnych, a nie z wnętrza folderu Extract, jak byłoby to zwykle wykonywane. Parametr /map musi określać nazwę i ścieżkę do pliku XML zawierającego dyrektywy mapowania. Te dyrektywy instruują program SolutionPackager do dopasowania plików według ich nazwy i ścieżki, oraz wskazują alternatywną lokalizację, w celu znalezienia dopasowanego pliku. Poniższe informacje w takim samym stopniu dotyczą wszystkich dyrektyw.
Można wymienić wiele dyrektyw, w tym te, które będą zgodne z identycznymi plikami. Dyrektywy wymienione na początku pliku mają pierwszeństwo przed dyrektywami wymienionymi później.
W przypadku dopasowania pliku do dowolnej dyrektywy należy go znaleźć w co najmniej jednej alternatywnej lokalizacji. Jeśli nie zostaną znalezione żadne pasujące alternatywy, narzędzie SolutionPackager wyświetla błąd.
Ścieżki folderów i plików mogą być względne lub bezwzględne. Ścieżki względne są zawsze sprawdzane względem folderu określonego przez parametr /folder.
Zmienne środowiskowe mogą być określane przy użyciu składni %variable%.
Symbol wieloznaczny folderu "**" może służyć do oznaczania "w dowolnym podfolderze". Można go używać tylko jako ostatniej części ścieżki, na przykład: "c:\folderA\**".
Symbole wieloznaczne w nazwach plików mogą być używane tylko w formatach "*.ext" lub "*.*". Inny wzorzec nie jest obsługiwany.
W tym miejscu opisano trzy typy mapowań dyrektyw oraz przedstawiono przykład ich stosowania.
Mapowanie folderu
Poniżej zamieszczono szczegółowe informacje na temat mapowania folderów.
Xml Format
<Folder map="folderA" to="folderB" />
Podpis
Ścieżki plików zgodne z folderem "folderA" są przełączane na "folderB".
Hierarchia podfolderów w poszczególnych elementach musi być dokładnie dopasowana.
Symbole wieloznaczne folderów nie są obsługiwane.
Nie można określać nazw plików.
Przykłady
<Folder map="folderA" to="folderB" /> <Folder map="folderA\folderB" to="..\..\folderC\" /> <Folder map="WebResources\subFolder" to="%base%\WebResources" />
Mapowanie pliku do pliku
Poniżej zamieszczono informacje na temat mapowania pliku do pliku.
Xml Format
<FileToFile map="path\filename.ext" to="path\filename.ext" />
Podpis
Każdy plik zgodny z parametrem map zostanie odczytany z poziomu nazwy i ścieżki określonej w parametrze to.
Dla parametru map:
Należy określić nazwę pliku. Ścieżka jest opcjonalna. Jeśli nie zostanie określona ścieżka, może nastąpić dopasowanie plików ze wszystkich folderów.
Symbole wieloznaczne nazw plików nie są obsługiwane.
Symbol wieloznaczny folderu jest obsługiwany.
Dla parametru
to:Należy określić nazwę i ścieżkę pliku.
Nazwa pliku może się różnić od nazwy w parametrze
map.Symbole wieloznaczne nazw plików nie są obsługiwane.
Symbol wieloznaczny folderu jest obsługiwany.
Przykłady
<FileToFile map="assembly.dll" to="c:\path\folder\assembly.dll" />
<FileToFile map="PluginAssemblies\**\this.dll" to="..\..\Plugins\**\that.dll" />
<FileToFile map="Webresrouces\ardvark.jpg" to="%SRCBASE%\CrmPackage\WebResources\JPG format\aardvark.jpg" />
<FileToFile
map="pluginpackages\cr886_PluginPackageTest\package\cr886_PluginPackageTest.nupkg"
to="myplg\bin\Debug\myplg.1.0.0.nupkg" />
W powyższym przykładzie pakietu NuGet plik cr886_PluginPackageTest.nupkg nie jest nadpisywany, jeśli plik już istnieje w określonej lokalizacji.
Mapowanie ścieżki do pliku
Poniżej zamieszczono szczegółowe informacje na temat mapowania pliku do ścieżki.
Xml Format
<FileToPath map="path\filename.ext" to="path" />
Podpis
Każdy plik zgodny z parametrem map jest odczytywany z poziomu ścieżki określonej w parametrze to.
Dla parametru map:
Należy określić nazwę pliku. Ścieżka jest opcjonalna. Jeśli nie zostanie określona ścieżka, może nastąpić dopasowanie plików ze wszystkich folderów.
Symbole wieloznaczne nazw plików są obsługiwane.
Symbol wieloznaczny dla folderu jest wspierany.
Dla parametru to:
Należy określić ścieżkę.
Symbol wieloznaczny folderu jest obsługiwany.
Nie należy określać nazwy pliku.
Przykłady
<FileToPath map="assembly.dll" to="c:\path\folder" />
<FileToPath map="PluginAssemblies\**\this.dll" to="..\..\Plugins\bin\**" />
<FileToPath map="*.jpg" to="%SRCBASE%\CrmPackage\WebResources\JPG format\" />
<FileToPath map="*.*" to="..\..\%ARCH%\%TYPE%\drop" />
Przykładowe mapowanie
Poniższy przykładowy kod XML prezentuje kompletny plik mapowania, który umożliwia narzędziu SolutionPackager odczytywanie dowolnego zasobu internetowego i dwóch domyślnych zestawów wygenerowanych z poziomu projektu zestawu narzędzi deweloperskich o nazwie CRMDevTookitSample.
<?xml version="1.0" encoding="utf-8"?>
<Mapping>
<!-- Match specific named files to an alternate folder -->
<FileToFile map="CRMDevTookitSamplePlugins.dll" to="..\..\Plugins\bin\**\CRMDevTookitSample.plugins.dll" />
<FileToFile map="CRMDevTookitSampleWorkflow.dll" to="..\..\Workflow\bin\**\CRMDevTookitSample.Workflow.dll" />
<!-- Match any file in and under WebResources to an alternate set of subfolders -->
<FileToPath map="WebResources\*.*" to="..\..\CrmPackage\WebResources\**" />
<FileToPath map="WebResources\**\*.*" to="..\..\CrmPackage\WebResources\**" />
</Mapping>
Rozwiązania zarządzane i niezarządzane
Skompresowany plik rozwiązania (ZIP) usługi Dataverse może być eksportowany w jednym z dwóch typów, jak przedstawiono poniżej.
Rozwiązanie zarządzane
Ukończone rozwiązanie gotowe do zaimportowania do organizacji. Po zaimportowaniu nie można dodawać ani usuwać składników, chociaż mogą one opcjonalnie zezwalać na dalsze dostosowywanie. Jest to zalecane, gdy programowanie rozwiązania zostanie zakończone.
Rozwiązanie niezarządzane
Otwarte rozwiązanie bez ograniczeń, które można dodać, usunąć lub zmodyfikować. Opcja zalecana podczas projektowania rozwiązania.
Format skompresowanego pliku rozwiązania będzie inny w zależności od typu rozwiązania: zarządzanego lub niezarządzanego. Narzędzie SolutionPackager może przetwarzać skompresowane pliki rozwiązań dowolnego typu. Jednak narzędzie nie może przekonwertować jednego typu na inny. Jedynym sposobem na konwersję plików rozwiązania na inny typ, na przykład z niezarządzanych na zarządzane, jest zaimportowanie pliku ZIP rozwiązania niezarządzanego na serwer usługi Dataverse, a następnie wyeksportowanie rozwiązania jako zarządzanego.
Narzędzie SolutionPackager może przetwarzać pliki ZIP rozwiązań niezarządzanych i zarządzanych jak połączony zestaw za pośrednictwem parametru /PackageType:Oba. Aby wykonać tę operację, konieczne jest dwukrotne wyeksportowanie rozwiązania jako każdego typu, nadając plikom ZIP nazwy zgodnie z poniższym opisem.
Niezarządzany plik ZIP: dowolna_nazwa.zip
Zarządzany plik ZIP: AnyName_managed.zip
Narzędzie przyjmie obecność zarządzanego pliku ZIP w tym samym folderze, w którym znajduje się plik niezarządzany, i wyodrębni oba pliki w jednym folderze z zachowaniem różnic między składnikami zarządzanymi i niezarządzanymi.
Po wyodrębnieniu rozwiązania jako niezarządzanego i zarządzanego będzie możliwe spakowanie obu typów w jednym folderze lub każdego typu osobno, korzystając z parametru /PackageType w celu określenia, który typ ma zostać utworzony. Podczas określania obu plików zostaną utworzone dwa pliki ZIP zgodnie z powyższą konwencją nazewnictwa. Jeśli brakuje parametru /PackageType, podczas pakowania z folderu zawierającego zarówno pliki zarządzane, jak i niezarządzane, domyślnie tworzony jest pojedynczy plik ZIP niezarządzany.
Rozwiązywanie problemów
Komunikat wyświetlany podczas używania Visual Studio do edytowania plików zasobów
Jeśli używasz Visual Studio do edytowania plików zasobów utworzonych przez narzędzie Solution Packager, podczas ponownego pakowania może zostać wyświetlony komunikat podobny do następującego: "Failed to determine version id of the resource file <filename>.resx the resource file must be exported from the solutionpackager.exe tool in order to be used as part of the pack process." Dzieje się tak, ponieważ Visual Studio zastępuje tagi metadanych pliku zasobu tagami danych.
Rozwiązanie
Otwórz plik zasobu w ulubionym edytorze tekstu, a następnie znajdź i zaktualizuj poniższe tagi:
<data name="Source LCID" xml:space="preserve"> <data name="Source file" xml:space="preserve"> <data name="Source package type" xml:space="preserve"> <data name="SolutionPackager Version" mimetype="application/x-microsoft.net.object.binary.base64">Zmień nazwę węzła z
<data>na<metadata>.Na przykład taki ciąg:
<data name="Source LCID" xml:space="preserve"> <value>1033</value> </data>Zmienia się na:
<metadata name="Source LCID" xml:space="preserve"> <value>1033</value> </metadata>Dzięki temu narzędzie do tworzenia pakietów rozwiązań może odczytać i zaimportować plik zasobów. Ten problem zaobserwowano tylko w przypadku korzystania z edytora zasobów Visual Studio.
Błąd: "Nie można odnaleźć wymaganego pliku ...\Other\Customizations.xml" z folderem YAML
Ten błąd pojawia się po uruchomieniu pakietu SolutionPackager (lub pac solution pack) względem folderu zawierającego pliki YAML, takie jak solution.yml, ale te pliki są umieszczane w katalogu głównym folderu, a nie wewnątrz wymaganego solutions/<SolutionUniqueName>/ podfolderu.
Przyczyna: Narzędzie wykrywa format kontroli wersji YAML, wyszukując solutions/ podfolder zawierający *solution.yml pliki. Gdy ten katalog jest nieobecny, narzędzie w trybie dyskretnym wraca do formatu XML (starsza wersja) i oczekuje .Other\Customizations.xml Wynikowy komunikat o błędzie odnosi się do pliku XML i nie wspomina o YAML, co jest mylące.
Naprawiono: Zorganizuj na nowo folder, aby pliki manifestu YAML znajdowały się w odpowiednich ścieżkach.
<rootFolder>/
solutions/<YourSolutionUniqueName>/ ← move solution.yml here
solution.yml
solutioncomponents.yml
rootcomponents.yml
missingdependencies.yml
publishers/<YourPublisherUniqueName>/
publisher.yml
Jeśli folder został uzyskany podczas procesu zatwierdzania integracji Git lub pac solution clone, struktura folderów powinna być już poprawna. Folder zawierający tylko pliki YAML najwyższego poziomu bez podkatalogu solutions/ reprezentuje niekompletny wyciąg i nie można go bezpośrednio spakować.
Ostrzeżenie: składnik zadeklarowany w rootcomponents.yml nie ma plików źródłowych
Pojawia się ostrzeżenie, gdy składnik, taki jak aplikacja kanwy, jest wymieniony na liście rootcomponents.yml, ale nie ma odpowiednich plików źródłowych w oczekiwanym folderze składnika (na przykład canvasapps/<schema-name>/).
Efekt: działanie narzędzia nadal kończy się powodzeniem (kod zakończenia 0) i tworzy prawidłowy pliki .zip, ale zadeklarowany składnik zostanie pominięty w spakowanym rozwiązaniu.
Przyczyna: Folder został utworzony w wyniku częściowego wyodrębnienia lub pliki źródłowe składnika nie zostały uwzględnione w repozytorium. Na przykład tylko pliki manifestu rozwiązania zostały zatwierdzone, a nie sama aplikacja kanwy.
Naprawić: Upewnij się, że wszystkie składniki zadeklarowane w pliku rootcomponents.yml mają odpowiednie pliki źródłowe obecne w folderze. W przypadku aplikacji kanwy plik .msapp musi istnieć w canvasapps/<schema-name>/. Jeśli brakuje jakichkolwiek plików, ponownie wyeksportuj pełne rozwiązanie z usługi Dataverse i rozpakuj je, lub użyj pac solution clone , aby uzyskać pełne wyodrębnienie.