Бележка
Достъпът до тази страница изисква удостоверяване. Можете да опитате да влезете или да промените директориите.
Достъпът до тази страница изисква удостоверяване. Можете да опитате да промените директориите.
SolutionPackager е инструмент, който може обратимо да разложи компресиран файл с решение от Microsoft Dataverse на множество XML файлове и други файлове. След това можете лесно да управлявате тези файлове с помощта на система за контрол на източника. Следващите раздели ви показват как да стартирате инструмента и как да използвате инструмента с управлявани и неуправлявани решения.
Важно
Инструментът SolutionPackager вече не е препоръчителният начин за разопаковане и опаковане на решения. Възможностите на инструмента SolutionPackager са интегрирани в Power Platform CLI. Командата pac solution има много глаголи, включително unpack, pack, clone, и sync които включват същите основни възможности като инструмента SolutionPackager.
Къде да намерите инструмента SolutionPackager
Инструментът SolutionPackager се разпространява като част от Microsoft. CrmSdk.CoreTools NuGet пакет. За да инсталирате програмата, изпълнете следните стъпки.
- Изтеглете пакета NuGet .
- Преименувайте разширението на името на файла на пакета от .nupkg на .zip.
- Извлечете съдържанието на компресирания (zip) файл.
Намерете изпълнимия файл SolutionPackager.exe в <папката extracted-folder-name>/contents/bin/coretools. Стартирайте програмата от папката coretools или добавете тази папка към вашия PATH.
Аргументи на командния ред на SolutionPackager
SolutionPackager е инструмент на командния ред, който може да бъде извикан с параметрите, посочени в следната таблица.
| Аргумент | Описание |
|---|---|
| /действие: {Извличане|Опаковка} | Задължително. Действието за изпълнение. Действието може да бъде или за извличане на решение .zip файл в папка, или за пакетиране на папка в .zip файл. |
| /zipfile: <път на файла> | Задължително. Пътят и името на решение .zip файл. При извличане файлът трябва да съществува и да се чете. При опаковане файлът се заменя. |
| /folder: <път на папката> | Задължително. Пътят към папка. При извличане тази папка се създава и се попълва с компоненти на файлове. При опаковане тази папка вече трябва да съществува и да съдържа преди това извлечени компоненти на файлове. |
| /packagetype: {Неуправляван|Управляван|И двете} | По избор. Типът пакет за обработка. Стойността по подразбиране е „Неуправлявано”. Този аргумент може да бъде пропуснат в повечето случаи, тъй като типът пакет може да бъде прочетен от .zip файла или файловете на компонентите. Когато извличате и и двете, е зададено, управляваното и неуправляемо решение .zip файловете трябва да присъстват и да се обработват в една папка. Когато е посочено опаковане и двете, управляваното и неуправляваното решение .zip файлове се произвеждат от една папка. За повече информация вижте раздела за работа с управлявани и незавършени решения по-нататък в тази статия. |
| /allowWrite:{Yes|No} | По избор. Стойността по подразбиране е Да. Този аргумент се използва само по време на извличане. Когато /allowWrite:No е посочено, инструментът извършва всички операции, но е възпрепятстван да пише или изтрива файлове. Операцията за извличане може да бъде оценена безопасно, без да се презаписва или изтрива всички съществуващи файлове. |
| /allowDelete:{Yes|No|Prompt} | По избор. Стойността по подразбиране е „Подкана”. Този аргумент се използва само по време на извличане. Когато е зададен /allowDelete:Yes, всички файлове, налични в папката, зададена от параметъра /folder, които не се очакват, се изтриват автоматично. Когато е зададен /allowDelete:No, не се извършва изтриване. Когато /allowDelete:Prompt е указана, потребителят се запитва през конзолата, за да разреши или откаже всички операции за изтриване. Ако е зададен /allowWrite:No, не се извършва изтриване, дори ако е посочен и /allowDelete:Yes. |
| /clobber | По избор. Този аргумент се използва само по време на извличане. Когато /clobber е посочена, файловете, които имат атрибут само за четене, се презаписват или изтриват. Когато не е посочено, файловете с атрибут само за четене не се презаписват или изтриват. |
| /errorlevel: {Изкл.|Грешка|Предупреждение|Информация|Многословно} | По избор. Стойността по подразбиране е „Информация”. Този аргумент показва нивото на информация за регистриране на данните за извеждане. |
| /map: <Път на файла> | По избор. Пътят и името на .xml файл, съдържащ директиви за картографиране на файлове. Когато се използват по време на извличане, файловете, които обикновено се четат от папката, посочена от параметъра / папка, се четат от алтернативни места, както е посочено във файла за картографиране. По време на операция с пакет файлове, които съответстват на директивите, не се записват. |
| /nologo | По избор. Потиснете банера по време на изпълнение. |
| /log: <път на файла> | По избор. Път и име до лог файл. Ако файлът вече съществува, към него се добавя нова информация за регистриране. |
| @ <Път на файла> | По избор. Път и име до файл, който съдържа аргументи от командния ред за инструмента. |
| /sourceLoc: <низ> | По избор. Този аргумент генерира файл с ресурс за шаблон и е валиден само при извличане. Възможните стойности са auto или LCID/ISO код за езика, който искате да експортирате. Когато се използва този аргумент, низовите ресурси от дадения локал се извличат като неутрален .resx файл. Ако auto или се посочва само дългата или кратката форма на превключвателя, използва се основният локал или решението. Можете да използвате кратката форма на командата: /src. |
| /localize | По избор. Извадете или обединете всички низови ресурси в .resx файлове. Можете да използвате кратката форма на командата: /loc. Опцията за локализиране поддържа споделени компоненти за .resx файлове. Повече информация: Използване на уеб ресурси на RESX |
| /РешениеИме: <име> | По избор. Уникалното име на решението за опаковане или извличане, когато изходната папка съдържа множество решения под solutions/*/solution.yml. Задължително е, когато са открити повече от едно решение. Отнася се само за YAML формат за контрол на изходния код. Можеш да използваш кратката форма на командата: /sn. |
| /remapPluginTypeNames | По избор. Когато е зададено, напълно квалифицираните типове имена на плъгините се пренасочват въз основа на събранията, включени в решението. Активирано по подразбиране в YAML формат за контрол на изходния код. Можеш да използваш кратката форма на командата: /fp. |
Формати на файлове за контрол на изходния код
SolutionPackager поддържа оформление на две папки при извличане и опаковане на решения.
XML формат (наследство)
Оригиналният формат. Метаданните на решението се съхраняват в Other\Solution.xml , Other\Customizations.xmlа всички компонентни файлове се извличат в плоска йерархия на папки заедно с тези файлове. Този формат е стандартният при извличане на .zip файл без допълнителна конфигурация.
YAML формат за контрол на изходния код
Въведен паралелно с интеграцията с Dataverse Git, този формат съхранява метаданните на решението като YAML файлове, разпределени в структурирана йерархия на папки. Това е форматът, който се пише, когато комитирате решения чрез нативна Git интеграция в Power Apps.
Предимства пред XML формата
- Създава по-чисти и по-четливи диференции на компоненти в контрола на изходния код
- Поддържа множество решения в една папка с хранилище
- Canvas файловете с приложения
.msappи съвременните потоци се поддържат само в този формат - Преназначаването на типа плъгин е активирано по подразбиране
Задължителна структура на папките
<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]/
Важно
YAML форматът се разпознава автоматично чрез наличието на solutions/ подпапка, съдържаща *solution.yml файлове.
Ако вашите YAML манифест файлове (solution.yml, solutioncomponents.yml, и т.н.) са поставени в корена на папката, а не под solutions/<SolutionUniqueName>/, инструментът не разпознава YAML формата. Инструментът се връща към XML пътя и докладва подвеждаща грешка относно липсваща Customizations.xml. Вижте Отстраняване на проблеми за информация как да се реши този проблем.
Повече информация: Reference за формат за контрол на исходния код YAML Solution
Правила за автоматично разпознаване на форматиране
| Състояние | Използван формат |
|---|---|
solutions/*/solution.yml намерено — точно едно решение |
YAML формат, при който името на решението се извежда от папката |
solutions/*/solution.yml намерени – множество решения |
YAML формат, където /SolutionName аргументът е задължителен |
Няма solutions/ налична поддиректория |
XML формат (наследство) |
Опаковане на папка във формат YAML
Следващата команда опакова папка във формат YAML.
SolutionPackager.exe /action:Pack /zipfile:MySolution.zip /folder:C:\repos\myrepo
Опаковане от папка с множество решения
Следващата команда опакова определено решение в папка с множество решения.
SolutionPackager.exe /action:Pack /zipfile:SolutionA.zip /folder:C:\repos\myrepo /SolutionName:SolutionA
Използвайте командния аргумент /map
Следващата дискусия описва подробно използването на аргумента /map за инструмента SolutionPackager.
Файловете, които са вградени в автоматизирана система за сглобяване, като например .xap Silverlight файлове и приставки, обикновено не се проверяват в контрола на източника. Уеб ресурсите може вече да присъстват в контрола на източника на местоположения, които не са пряко съвместими с инструмента SolutionPackager. Чрез включване на параметъра /map, инструментът SolutionPackager може да бъде насочен да чете и пакетира такива файлове от алтернативни места, а не от папката Extract, както обикновено се прави. Параметърът /map трябва да посочва името и пътя към XML файл, съдържащ директиви за съпоставяне. Тези директиви инструктират SolutionPackager да съпоставя файловете по тяхното име и път и да посочва алтернативното местоположение за намиране на съответстващия файл. Следната информация се отнася за всички директиви еднакво.
Могат да бъдат изброени няколко директиви, включително директиви, които съответстват на идентични файлове. Директивите, изброени в началото на досието, имат предимство пред директивите, изброени по-късно.
Ако файл е съпоставен с която и да е директива, той трябва да бъде намерен на поне едно алтернативно място. Ако не бъдат намерени съвпадащи алтернативи, SolutionPackager издава грешка.
Пътеките на папки и файлове могат да бъдат абсолютни или относителни. Относителните пътища винаги се оценяват от папката, посочена от параметъра /folder.
Променливите на средата могат да бъдат зададени чрез използване на синтаксис %variable%.
Джокерът на папката "**" може да означава "във всяка подпапка". Може да се използва само като крайна част на пътя, например: "c:\folderA\**".
Уайлдкарти с имена на файлове могат да се използват само във формите "*.ext" или "*.*". Не се поддържа друг модел.
Тук са описани трите типа картографиране на директиви, заедно с пример, който ви показва как да ги използвате.
Нанасяне на папка
Следната информация предоставя подробна информация за съпоставянето на папки.
XML формат
<Folder map="folderA" to="folderB" />
Описание
Пътищата на файловете, които съвпадат с "folderA", се сменят на "folderB".
Йерархията на подпапките под всяка трябва точно да съвпада.
Заместващите символи за папки не се поддържат.
Не могат да се посочват имена на файлове.
Примери
<Folder map="folderA" to="folderB" /> <Folder map="folderA\folderB" to="..\..\folderC\" /> <Folder map="WebResources\subFolder" to="%base%\WebResources" />
Нанасяне файл към файл
Информацията по-долу предоставя повече подробности за съпоставянето на файл към файл.
XML формат
<FileToFile map="path\filename.ext" to="path\filename.ext" />
Описание
Всеки файл, съответстващ на map параметъра, се чете от името и пътя, посочени в параметъра to .
За map параметъра:
Трябва да бъде определено име на файл. Пътят не е задължителен. Ако не е посочен път, файловете от която и да е папка могат да бъдат съпоставени.
Заместващите символи за име на файл не се поддържат.
Заместващ символ за папка се поддържа.
За
toпараметъра:Трябва да бъде определено име и път на файл.
Името на файла може да се различава от името в
mapпараметър.Заместващите символи за име на файл не се поддържат.
Заместващ символ за папка се поддържа.
Примери
<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" />
В горния NuGet пример с пакета cr886_PluginPackageTest.nupkg не се презаписва, ако файлът вече съществува на посоченото място.
Нанасяне на файл към път
Следното предоставя подробна информация за нанасяне файл към път.
XML формат
<FileToPath map="path\filename.ext" to="path" />
Описание
Всеки файл, съответстващ на map параметъра се чете от пътя, посочени в to параметър.
За map параметъра:
Трябва да бъде определено име на файл. Пътят не е задължителен. Ако не е посочен път, файловете от която и да е папка могат да бъдат съпоставени.
Заместващи символи за име на файл се поддържат.
Заместващ символ за папка се поддържа.
За to параметъра:
Трябва да бъде определен път.
Заместващ символ за папка се поддържа.
Не трябва да бъде определено име на файл.
Примери
<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" />
Примерно нанасяне
Следващата извадка от XML код показва пълен нанасящ файл, който позволява на инструмента SolutionPackager да чете всеки уеб ресурс и двата генерирани по подразбиране сглобки от проект на инструментариум за програмисти, наречен 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>
Завършени и незавършени решения
Компресиран файл на решение (.zip) на Dataverse може да се експортира в един от двата типа, както е показано тук.
Управлявано решение
Завършено решение, готово за импортиране в организация. След внос компонентите не могат да се добавят или премахват, въпреки че по желание позволяват допълнителна персонализация. Това се препоръчва, когато разработването на разтвора приключи.
Неуправлявано решение
Отворено решение без ограничения за това какво може да се добави, премахне или промени. Това се препоръчва по време на разработване на решение.
Форматът на компресиран файл с решение ще бъде различен в зависимост от неговия тип, управляван или неуправляем. SolutionPackager може да обработва компресирани файлове с решение от всеки тип. Въпреки това, инструментът не може да конвертира един тип в друг. Единственият начин за преобразуване на файлове с решение в различен тип, например от неуправляван в управляван, е чрез импортиране на .zip файла с неуправлявано решение в Dataverse сървър и след това експортиране на решението като завършено решение.
SolutionPackager може да обработва неуправляеми и завършено решение .zip файлове като комбиниран набор чрез параметъра /PackageType:Both и двете. За да извършите тази операция, е необходимо да експортирате решението си два пъти като всеки тип, именувайки .zip файловете, както следва.
Неуправляем .zip файл: AnyName.zip
Управляем .zip файл: AnyName_managed.zip
Инструментът предполага наличието на управлявания zip файл в същата папка като неуправлявания файл и извлича двата файла в една папка, запазвайки разликите, където има управлявани и неуправляеми компоненти.
След като решение е извлечено като едновременно управлявано и управлявано, е възможно от тази единствена папка да опаковате и двете, или всеки тип поотделно, използвайки параметъра /PackageType, за да посочите кой тип да създадете. При посочване на двата файла ще бъдат създадени два файла .zip, като се използва конвенцията за именуване, както е посочено по-горе. Ако параметър /PackageType липсва при опаковане от двойна управлявана и неуправляема папка, по подразбиране е да се генерира един неуправляем .zip файл.
Отстраняване на неизправности
Съобщение, показвано при използване на Visual Studio за редактиране на ресурсни файлове
Ако използвате Visual Studio за редактиране на ресурсни фсилове, създадени от пакетиращия решение, може да получите съобщение при преопаковане, подобно на това: "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." Това се случва, защото Visual Studio заменя метаданните на ресурсния файл с тагове за данни.
Заобиколно решение
Отворете файла с ресурси в любимия си текстов редактор и намерете и актуализирайте следните тагове:
<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">Промяна на името на възела от
<data>на<metadata>.Например този низ:
<data name="Source LCID" xml:space="preserve"> <value>1033</value> </data>Промени на:
<metadata name="Source LCID" xml:space="preserve"> <value>1033</value> </metadata>Това позволява на пакерача на решения да чете и импортира файла с ресурси. Този проблем е наблюдаван само при използване на редактора на ресурси Visual Studio.
Грешка: "Не може да се намери необходимият файл ...\Other\Customizations.xml" с YAML папка
Тази грешка се появява, когато стартирате SolutionPackager (или pac solution pack) срещу папка, която съдържа YAML файлове като solution.yml, но тези файлове се поставят в корена на папката, а не вътре в необходимата solutions/<SolutionUniqueName>/ подпапка.
Причина: Инструментът открива YAML формат за контрол на изходния код, като търси solutions/ подпапка, съдържаща *solution.yml файлове. Когато тази директория липсва, инструментът тихо се връща към XML (наследен) формат и очаква Other\Customizations.xml. Полученото съобщение за грешка се отнася до XML файл и не споменава YAML, което е подвеждащо.
Поправка: Реорганизирайте папката така, че файловете с манифеста на YAML да са под правилните пътища:
<rootFolder>/
solutions/<YourSolutionUniqueName>/ ← move solution.yml here
solution.yml
solutioncomponents.yml
rootcomponents.yml
missingdependencies.yml
publishers/<YourPublisherUniqueName>/
publisher.yml
Ако си получил папката от Git интеграционен комит или pac solution clone, структурата на папката би трябвало вече да е правилна. Папка, която съдържа само най-горните YAML файлове без поддиректория solutions/ , представлява непълен екстракт и не може да бъде опакована директно.
Внимание: компонент, деклариран в rootcomponents.yml, няма изходни файлове
Това предупреждение се появява, когато компонент, като canvas app, е в списъка rootcomponents.yml , но няма съответни изходни файлове в очакваната компонентна папка (например, canvasapps/<schema-name>/).
Ефект: Инструментът все пак успява (изходен код 0) и създава валиден .zip файл, но декларираният компонент се пропуска от пакетираното решение.
Причина: Папката е създадена чрез частичен екстракт, или изходните файлове на компонента не са били включени в хранилището. Например, само файловете с манифеста на решението бяха комитирани, а не самото приложение Canvas.
Поправка: Уверете се, че всички декларирани rootcomponents.yml компоненти имат съответните изходни файлове в папката. За canvas приложения файлът .msapp трябва да съществува под canvasapps/<schema-name>/. Ако липсват файлове, експортирайте пълното решение от Dataverse и го разопаковайте отново, или използвайте pac solution clone за получаване на пълен екстракт.