My company has a .NET Powershell module, written in C# to allow advanced users to automate tasks in our product. Currently it targets Powershell 5 using .NET 4.6.1. We would like to allow customers using other operating systems to use it as well, and as it has no OS-specific code, porting it was straightforward.
However, I cannot find documentation on a debugging workflow that should be followed. In standard .NET Powershell, this was quite simple and required a one-time setup procedure:
However, this doesn't work for Powershell Core. Because the project depends on NuGet packages, the module registration fails with a dependency error. I was able to figure out another workflow but it's a bit more obtuse:
dotnet publish -f netstandard2.0 -c debug
Import-Module ./bin/Debug/netstandard2.0/publish/MyModule.dll
$pid
to find the PIDThis works and I have debugged a few issues with this method, but it's not the most pleasant or efficient way to do it. I believe that there must be a better way that is just not well documented.
I originally came up with a script based approach that you can see in this post's history, but what I didn't know at the time was the CopyLocalLockFileAssemblies
property which makes the debug directory look like how it used to look when working on .NET Framework. You just need to add this to your .csproj
in a <PropertyGroup>
:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Then, the debugging setup is just the same as any other .NET module loaded into a third party application:
C:\Program Files\PowerShell\6\pwsh.exe
-NoExit -Command "Import-Module C:\dev\my-module\bin\Debug\netstandard2.0\my-module.dll"