Fix for issue #418. Change Add-Type to native enum

[garthmccormack]

Hi @rmbolger

I ran into the problem described in Issue #418. After investigating I identified the part causing the error to be the Add-Type call to add the enum for RevocationReasons. I tested replacing this with the native enum keyword which worked. Enum was introduced in Powershell v5 so this should meet your Powershell version requirements.

As it happens the documentation uses RevocationReasons which the new enum matches as well so the only changes are in the Revoke-PACertificate.ps1 file.

[rmbolger]

Ooh, nice find @garthmccormack! The Add-Type was indeed probably a leftover from before I started requiring PSv5 minimum. I still don't quite get why the Add-Type call causes Lambda to break. But if this fixes it and doesn't break anything else, I'll take it.

Give me some time to poke at it and I'll get it in.

[garthmccormack]

I had a quick look at what the Add-Type command actually does in version 7 of Microsoft.PowerShell.Utility and it looks like the issue is in this bit from the .Net dll file:

AddTypeCommand.s_netcoreAppRefFolder = Path.Combine(Path.GetDirectoryName((Assembly.GetEntryAssembly() ?? typeof(PSObject).Assembly).Location), "ref");

The expectation from the above code is that it would resolve the EntryAssembly to somewhere like C:\Program Files\PowerShell\7 on a windows system which then has a "ref" folder under it. However, when running on AWS Lambda the script is wrapped with their own launcher using dotnet6 as the runtime. The entry assembly then sits in /var/runtime which doesn't have the ref subfolder.

Just tested and the EntryAssembly for Lambda is /var/runtime/Amazon.Lambda.RuntimeSupport.dll and C:\Program Files\PowerShell\7\pwsh.dll on Powershell 7.

[rmbolger]

I now recall why I had originally gone with the Add-Type route instead of moving to the native PowerShell enums. With Add-Type the enum becomes available for use directly within the callers scope. But with the native enum, that no longer works which is a known issue with both native enums and classes. The available workarounds to get it into the caller's scope are cumbersome and have caveats.

However, despite the lack of direct access, tab completion of the enum values for Revoke-PACertificate -Reason <tab> works using both methods. And even without it, interpretation of the enum value names without being fully qualified works just fine in both PS 5.1 and 7+.

# this is way easier to type and read
Revoke-PACertificate -Reason keyCompromise

# than this
Revoke-PACertificate -Reason ([PoshACME.RevocationReasons]::keyCompromise)

Since it's unlikely any other software outside of this module is depending on using the enum, losing access to it from outside the module scope is not likely to negatively affect anyone. So I'm going to sneak it in to a 4.x release rather than bumping the major version number.

Thanks again for research and fix.