У меня есть пример проекта https://github.com/hagatorn/LunarSolarDate, который является предварительным выпуском, поэтому, пожалуйста, извините за отсутствие финиша.
Если я собираю проект, я могу импортировать модуль в каталог bin:
Import-Module .\SolarLunarName.PoSH.dll
Однако при запуске единственной команды мне выдается ошибка.
Get-Date | Get-SolarLunarName
Get-SolarLunarName : Could not load file or assembly 'RestSharp, Version=106.6.2.0, Culture=neutral,
PublicKeyToken=598062e77f915f75' or one of its dependencies. The system cannot find the file specified.
At line:1 char:12
+ get-date | Get-SolarLunarName
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-SolarLunarName], FileNotFoundException
+ FullyQualifiedErrorId : System.IO.FileNotFoundException,SolarLunarName.PoSH.GetSolarLunarName
Это было относительно легко разрешить, чтобы вставить отсутствующую dll в каталог bin. Затем появилось менее полезное сообщение, но добавление Newtonsoft.Json.dll и Newtonsoft.Json.pdb в каталог bin привело меня к проблеме, о которой я расскажу в отдельном вопросе.
Ручное копирование зависимостей вокруг немного беспокоило меня, поэтому я начал экспериментировать, пытаясь построить и развернуть с помощью nuget, и надеюсь, что зависимости могут быть полностью рассмотрены в этой модели.
Опубликовав модуль и его частную зависимость как опубликованный пакет nuget, я могу сформировать зависимости с помощью следующей команды.
nuget.exe install SolarLunarName.PoSH
Однако в своем начальном состоянии зависимости логически разделены в структуре каталогов, что делает их недоступными для двоичного модуля.
Есть ли лучший способ сделать это как интегрированную часть сборки или установки пакета? Может ли powershell управлять некоторыми пакетами и использовать .deps.json для установки общедоступных зависимостей?
Я видел другой поток, обсуждающий принудительное включение msbuild для включения дополнительных двоичных файлов в вывод каталога bin путем выполнения фиктивных вызовов вложенных зависимостей. Несмотря на удобство этого решения, оно показалось немного неправильным и противоречило логике управления пакетами. Зависимая DLL не копируется в выходную папку сборки в Visual Studio
Также существует следующий поток, который, я допускаю, может быть той же самой проблемой, если управление пакетами действительно работает правильно, и я неправильно понял проблему. Ошибка зависимости сборки двоичного модуля PowerShell .
Наконец, была еще одна причина пометить ваш пакет как «PSModule». Я думаю, что я сделал это на странице пакета свойств проекта Visual Studio. Но, возможно, это не то, как этого добиться?