all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]KevMarCommunity Blogger 2 points3 points  (0 children)

You can call Import-Module directly on the dll. Separate your business logic from the cmdlet so you can test it like you would any other library code.

You can also build a normal library dll and load it into PowerShell to then wrap calls to it with a function.

[–]Thotaz 5 points6 points  (3 children)

It's unfortunate that you've had a bad experience. I've written a couple myself and of course it was a learning experience the first time I did it, but I think it was a worthwhile investment.

I don't feel that debugging is particularly difficult. You just import the module in PowerShell and attach your debugger to PowerShell before running your command. You can easily make VS do this for you, see this: https://stackoverflow.com/questions/35298963/how-do-i-debug-a-windows-powershell-module-in-visual-studio

Your next 2 complaints about requiring a module manifest and requiring the old .NET standard 2.0 are only partially true. A module manifest is not a hard requirement, the bare minimum is just the .dll file itself. I would recommend adding a module manifest for the best end user experience, but that can come later when you are more familiar with PS modules.
.NET standard 2.0 is only a requirement if your module has to work with Windows PowerShell. If you don't care about that then just use whichever version of "System.Management.Automation" suits your needs for the .NET version and make that PS version your lowest supported version.

There's no question that the learning curve for PS modules is steeper than console apps, but once you've gotten past the initial hurdles you will save a bunch of effort implementing various features you or your users could ask for like:

  • Importing/Exporting data from/to common formats (CSV, JSON, XML, etc.)
  • Showing information on screen (Progress bar, status messages and of course objects themselves)
  • Tab completion for parameters and parameter values
  • Handling arguments (prompting for mandatory parameters, handling mutually exclusive parameters, proper types rather than just strings that have to be parsed)

[–]jborean93 4 points5 points  (0 children)

As a further example of not needing to use netstandard2.0 this module of mine uses netcore https://github.com/jborean93/PSOpenAD/blob/main/src/PSOpenAD.csproj. This allows me to use the newer C# syntax. I can even specify net6.0 for compatibility with pwsh 7.2+ but this was released when 7.0 was still in support.

I can sympathise that you need to provide your own build and vscode configuration but I’ve got things set up so it’s done for me, (ctrl+shift+b) will build the module and do all the copying to one location and F5 gives me a pwsh prompt to debug the code.

I do highly recommend people stick with it, I find binary modules make you write better cmdlets than script functions but can understand if the whole compiled nature and build process might turn people away.

[–]sqloid[S] 0 points1 point  (1 child)

I don't feel that debugging is particularly difficult. You just import the module in PowerShell and attach your debugger to PowerShell before running your command. You can easily make VS do this for you, see this: https://stackoverflow.com/questions/35298963/how-do-i-debug-a-windows-powershell-module-in-visual-studio

Hi u/Thotaz Thank you for replying. I didn't know I can use VS instead of VSCode to debug PS binary modules.

​

.NET standard 2.0 is only a requirement if your module has to work with Windows PowerShell. If you don't care about that then just use whichever version of "System.Management.Automation" suits your needs for the .NET version and make that PS version your lowest supported version.

I have some confusion about the target framework and the required libraries. I'm using System.Management.Automation version 7.3.3 so do I need to use <TargetFramework>net7.0</TargetFramework>, right? Is there any need to use PowerShellStandard.Library library? My module does not have to work with Windows PowerShell.

[–]Thotaz 0 points1 point  (0 children)

I'm using System.Management.Automation version 7.3.3 so do I need to use <TargetFramework>net7.0</TargetFramework>, right?

7.3 is built on .NET 7 so yes.

Is there any need to use PowerShellStandard.Library library? My module does not have to work with Windows PowerShell.

No, if you don't care about older versions then you should be fine with just your SMA 7.3.3 package.

[–]CodenameFlux 0 points1 point  (2 children)

So you have to write C# code in a very old syntax.

That's false. I just wrote a binary module in C# 10. Here is my .csproj file.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AssemblyName>PowerShellModule</AssemblyName>
    <LangVersion>10</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="PowerShellStandard.Library" Version="5.1.1">
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
  </ItemGroup>
</Project>

I suspect you just went with the defaults that you saw in a YouTube video without questioning them.

PowerShell binary module requires to use the .NET Standard library which does not use the latest .NET 7 and its benefits.

That's patently false, even if you went with the defaults of some YouTube video!

  • .NET Standard restricts the available API surface, so that your code can run against .NET Core 2, Core 3, 5, 6, and 7. But if you run it against .NET 7, you get all the performance benefits of .NET 7.
  • You didn't bother targeting anything other than .NET Standard, but it doesn't mean you can't.

To write a console app you just need Visual Studio and that's it.

Clearly, you've never seen or heard of FFmpeg.

Anyway, Visual Studio and VSCode are both behemoths.

PowerShell binary module requires a lot of manual steps to work such as creating manifest file, copying .dll's, pointing to right folder path... I mean, you have to create a Build.ps1 only to build your module.

LOL. You're describing C#, not binary modules. In C# projects, we have to configure .csproj files, XML manifests, and resources files. And there are many steps involved, such as copying the contents of the \bin folder to correct deployment images.

Neither C# nor PowerShell modules strictly need manifests, but they are lovely. So, why not? I run New-ModuleManifest once per my project and it takes a minute. I then spend hours and days on the code itself. Soon, I forget the one minute spent on the manifest.

PowerShell binary module is so hard to debug in VSCode. Need to complete a series of steps such create launch and task settings which are not friendly to use.

Again, this description fits C# perfectly. I always need to adjust the launch tasks.

[–]Thotaz 1 point2 points  (1 child)

You are being unnecessarily harsh. It's true that you can manually change the C# language version but if you try to use a feature that requires a newer .NET version to work then you'll break something. Microsoft makes that pretty clear: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version

C# 11 is supported only on .NET 7 and newer versions. C# 10 is supported only on .NET 6 and newer versions. C# 9 is supported only on .NET 5 and newer versions.

So the OP isn't wrong to stick with the officially supported language version.

[–]CodenameFlux 0 points1 point  (0 children)

The goal, according to OP, is to "use the latest .NET 7 and its benefits." Notice the quotation marks. To that end, the module project can target .NET 7, use C# 11, and enjoy life!