An error in PowerShell Community Extensions and the fact that they add their snapin to PowerShell profile cause PowerGUI to exit if extensions v1 or 1.1 are installed.
This is an acknowledged issue which is already fixed in the extensions but has not yet made into their release.
The symptoms are pretty straight-forward. You run PowerGUI on a computer which already has PSCX installed, PowerGUI displays a message “Object reference not set to an instance of an object” or “The invoked member is not supported in a dynamic assembly” and exits.
The reason is that PSCX has an issue that throws this exception and the exception is thrown in asynchronous code so it escapes PowerGUI catches and just happens after PowerGUI startup even if you don’t use any PSCX functionality in PowerGUI. The worst part about that is that this happens even if you don’t want to use PSCX in PowerGUI at all. Normally, if you want to use a PowerShell snapin (like PSCX, AD cmdlets, or any other library available on the market) you would execute
Add-PSSnapin in the PowerShell command prompt or go to File/Snapins in PowerGUI and select the snapin there. Unfortunately, PSCX is doing something which is pretty bad: they are adding PSCX load code to PowerShell profile – and this makes their libraries load automatically without user consent – this is similar to applications adding themselves to a Startup group in Windows.
PowerGUI uses PowerShell profiles and gets this unhandled exception as result.
- Cmdlet creators, please, don’t load your libraries in the profile. This is a pretty bad practice which can affect other applications even if they are not using your code.
- PSCX is still a great effort and once the guys will fix the issue you will be able to use their cmdlets in PowerGUI.
- Meanwhile you can either uninstall PSCX or remove the code loading the library from your PowerShell profile.
For more information see these discussion threads: