如何在 Powershell 二进制模块 (.Net Standard & Nuget) 中处理公共和私有依赖项和打包

Question

I have a sample project https://github.com/hagatorn/LunarSolarDate which is pre-release so please excuse the lack of finish.

If I build the project I can import the module in the bin directory:

Import-Module .\SolarLunarName.PoSH.dll

However, when run the only command I am presented with an error.

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 

This was relatively easily resolved to pop the missing dll in the bin directory. A less useful message then appeared but adding Newtonsoft.Json.dll and Newtonsoft.Json.pdb to the bin directory moved me onto a problem I will deal with in a separate question.

Manually copying dependencies around worried me a bit so I began to experiment trying to build and deploy with nuget and hope dependencies may be dealt with completely in this model.

Having published the module and its private dependency as a published nuget package I can form the dependencies with the following command.

nuget.exe install SolarLunarName.PoSH 

However, in their initial state the dependencies are logically separated in a directory structure that renders them inaccessible to the binary module.

Is there a better way of doing this as an integrated part of the build or package installation? Can powershell do some package management and use the .deps.json to install the public dependencies?

I have seen another thread discussing forcing msbuild to include extra binaries in the bin directory output by making dummy calls to nested dependencies. Despite the convenience of this solution it seemed a little wrong-headed and contrary to the logic of package management. Dependent DLL is not getting copied to the build output folder in Visual Studio

Also there is the following thread which I which I admit could be the same issue if package management is indeed working correctly and I have misunderstood the problem. PowerShell Binary Module assembly dependency error .

Finally there was another lead regarding tagging your package as "PSModule" I believe I've done this in the visual studio project properties package page. But perhaps this isn't how to achieve that?

Answer 1

This problem was caused by a lack of a concrete target framework and a dependency which was not written in .Net Standard and had various different packages it would present when finally compiled to a target framework.

A newer version of Rest Sharp may have been released which does not have this problem however some SQLite drivers and ORMs still have this limitation.