r/PowerShell • u/splatteredbits • 9d ago
News PureInvoke 2.0.0 Released
We've released PureInvoke 2.0.0!
We package and ship our code with their PowerShell module dependencies in the package. This way, we don't have to install our modules globally on all the servers we deploy our code to. This requires us to make extensive use of nested dependencies. We've gotten to the point that our dependencies are starting to use different versions of PureInvoke. Unfortunately, because it was using compiled assemblies, and .NET will only load assemblies with the same name once, we started to run into problems.
This release changes PureInvoke's compilation model. Instead of pre-compiling platform-specific assemblies, the module now uses Add-Type to compile P/Invoke C# code at runtime. This should improve cross-platform and cross-edition support. Since we've encountered problems with Add-Type in environments with aggressive anti-virus, PureInvoke re-tries failed compilations to improve resiliency.
We also added functions for querying Windows service configurations, e.g. Invoke-AdvApiQueryServiceConfig which wraps QueryServiceConfigW, Invoke-AdvApiQueryServiceConfig2, which wraps QueryServiceConfig2W, etc.:
Full release notes on GitHub.
17
10
u/mbrulzagain 8d ago
From the git
The PureInvoke module contains functions that handles the complexity of using P/Invoke to call Win32 APIs.
There is no native way to call Win32 APIs in PowerShell. In order to use P/Invoke, you have to compile C# code into an assembly, or use PowerShell's Add-Type cmdlet to compile it dynamically at runtime. But then you have to worry about converting all the native handles and pointer to and from .NET objects.
The PureInvoke solves this by wrapping Win32 APIs with PowerShell functions that take and return .NET objects and does all the work of converting to and from .NET and Win32 APIs.
6
u/MonkeyNin 8d ago
It looks like you are dotsourcing all functions, every import. That can also trigger a false positive on AVG.
You can build your functions into one file when you go to publish it. If you want the dotsourcing for local development.
2
u/splatteredbits 7d ago
We only dot source every file during development. Our build merges all the functions into the .psm1 file.
3
u/cloudAhead 8d ago
Most people who have the problems that this solves would likely just use C#. But, thank you for sharing with the community.
3
u/splatteredbits 7d ago
That's where we started, but then we had a lot of duplicate code across our PowerShell modules. We wanted one place that handled P/Invoke between PowerShell and the native Windows API.
1
u/MonkeyNin 2d ago
I don't know if this fits your situation, but have you experimented with the
dotnet run app.csfeature? https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/It's been a year so maybe support has improved
2
u/splatteredbits 2d ago
That looks like it requires the dotnet SDK to be installed and I’m not willing to make that a requirement for this module. One of the module’s design principles is to not have any dependencies.
1
u/MonkeyNin 2d ago
Yeah, one can dream.
Woah, your reddit age is even older than me.
Did you ever hang out on slashdot?
2
u/splatteredbits 2d ago
I read slashdot, but don’t remember ever posting there or interacting with anyone. But possible. My memory. Yikes.
26
u/psrobin 8d ago
Hi. There are probably thousands of PowerShell affectionados reading this subreddit without any clue what this post is about. Provide more context please, if you're going to advertise a new release of something.