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:
|
return type.GetMethod(method, BindingFlags.Static | BindingFlags.Public | BindingFlags.IgnoreCase); |
because type was null.
Digging in the stack trace, I found out that the null reference was originated by the following instruction:
|
Type securityDescriptorCommandsBaseType = TypeResolver.ResolveType("Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase", exception: out _); |
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.
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
NullReferenceExceptionthat was thrown in this line of code:PowerShell/src/System.Management.Automation/engine/TypeTable_Types_Ps1Xml.cs
Line 51 in 4b9b078
because
typewas null.Digging in the stack trace, I found out that the null reference was originated by the following instruction:
PowerShell/src/System.Management.Automation/engine/TypeTable_Types_Ps1Xml.cs
Line 4072 in 4b9b078
The
securityDescriptorCommandsBaseTypevariable gets passed to the methodGetMethodInfo, which contains the return statement with the variabletypeshown 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 oftypeofto 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
securityDescriptorCommandsBaseTypefrom 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.