While using only System.Management.Automation as a dependency for an application of mine (without the entire SDK because I didn't need it), I was getting sometimes a NullReferenceException that was thrown in this line of code:

because type was null.

Digging in the stack trace, I found out that the null reference was originated by the following instruction:

The securityDescriptorCommandsBaseType variable gets passed to the method GetMethodInfo, which contains the return statement with the variable type shown above.

Once you know that the referenced type (Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase) belongs to the Microsoft.PowerShell.Security package, and that the latter depends on System.Management.Automation, it becomes apparent that TypeResolver.ResolveType was being used in place of typeof to avoid a circular dependency at compile time between the two assemblies.
The problem is that the circular dependency still exists and causes the NRE mentioned above when System.Management.Automation is used alone.

Therefore, since I think that probably that dependency can't be broken, I would propose to "loosen" it by adding a null-check that prevents all the code related to the securityDescriptorCommandsBaseType from being executed when Microsoft.PowerShell.Security assembly is not available (which should be lines 4074-4128 or even 4074-4210, I'm not sure).

I'm willing to open a PR to mitigate this problem after receiving your feedback on it, since - unlike me - you know the context and the motivation of the code I mentioned throughout this issue.