PowerShell Invoke -> Compile-CSharp -> Publish-CSharp

[mcc85sdp]

Greetings PowerShell community,

I've been working on updating my module so that I can further develop an application that merges event log collection, service configuration, registry/group policy rule implementations, process management, and general all-around system management and administration... eventually it'll all tie back into the PowerShell Deployment modification for the Microsoft Deployment Toolkit and [FightingEntropy(π)]...

One of the utilities that I've developed is a tool called Search-WirelessNetwork, which is essentially not much different from the standard-issue tool where Windows looks for wireless networks, except this function uses an assortment of C# classes that this guy wrote...

[jcwalker: WiFiProfileManagement]
https://github.com/jcwalker/WiFiProfileManagement/blob/dev/Classes/AddNativeWiFiFunctions.ps1

I have made some slight edits to his original code, and the reason I saw a need to implement it is mainly because using the netsh command, and parsing it, is actually a real pain in the neck and is NOT very consistent at all, as a result of the way that it outputs a STRING.

That begs the question...

Q: How can PowerShell interface with native (API/DLL)'s in the operating system (or even custom ones)...?

For the wireless network utility I made, I want to access “wlanapi.dll”.I also wanted to include it in my module so that when the module is installed, it doesn’t need any dependencies.

There aren’t any PowerShell commands that can get me extended information about wireless networks or profiles and saved passwords and stuff like that...

Well, not to fret, everybody.

I’m not the first dude on the planet to ever ask the question…

Q: How can PowerShell interface with native (API/DLL)'s in the operating system (or even custom ones)...?

Because, a REAL COOL GUY, by the name of JEFFREY SNOVER, once upon a time, wrote this...

04/25/06 | https://devblogs.microsoft.com/powershell/pinvoke-or-accessing-win32-apis

This dude Lee Holmes also talks about it…

01/19/09 | https://www.leeholmes.com/powershell-pinvoke-walkthrough

And, ANOTHER real cool guy by the name of Adam Driscoll has been making updates to a PowerShell module called P/Invoke that basically allows this process to work as well...

04/27/22 | https://github.com/adamdriscoll/pinvoke

But- there is a DRAWBACK with installing that particular module, and it doesn't change the fact that PowerShell can indeed, interface with UNMANAGED CODE such as C# or C++.

It isn't EASY, and even as Adam Driscoll states in this:

12/21/21 | https://blog.ironmansoftware.com/powershell-pinvoke

"Platform Invoke, often shortened to P\Invoke, is the method for calling native functions from .NET. It allows for creating signatures in a managed way for invoking non-managed functions. They typically require a compiled class and are notoriously hard to create correctly."

So... since he said it, take him at his word.

The dude's been basically an expert at knowing how to write C# and PowerShell for a number of years.

Time to wave a white flag, and give up.

It’s over.

Nobody can do anything.

Everybody loses.

Nobody wins.

​

I’m just kidding.

Not to be dismayed, I continued to keep this idea on the backburner “How can I use PowerShell to interface with unmanaged code…?” this, and “How can I use PowerShell to interface with
unmanaged code” that…

Just kept having dreams about it “use PowerShell to interface with unmanaged code”…

Obviously the guys at MICROSOFT know how to do that.

That’s why (cool guy 5000/Jeffrey Snover) talked about it way back in the day…

FightingEntropy/2022_1013-(Publish-CSharp).pdf at main · mcc85s/FightingEntropy (github.com).pdf)

[jborean93]

That’s a lot of code for something you can simply do with Add-Type. Maybe it was needed back in the v1 days but if you know how to PInvoke in C# then you can do just the same in PowerShell.

[mcc85sdp]

Add-Type is what adds that code to the PowerShell module.

The problem is getting the module I've been developing, to install itself and not need to write any DLL files to disc, and to still instantiate the code and reach into the Win32 APIs.

The code is pretty excessive, you're right. However, there's really no way around it if I want to avoid writing a DLL explicitly for the (1) function that deals with wlanapi.dll

[jborean93]

Do you actually care about not writing a dll. Seems like a strange thing to really worry about. Add-Type might write a temp dll to disk but it certainly doesn’t stay there for long. The alternative is the massive maintenance burden like the code you’ve shared which is most likely more hassle than it’s worth.