It would be fine if this happens, but it doesn't.
On a standard Win7 workstation, If I do not build the application to use the v2 script engine I get a Windows system message that the executable has stopped working and another dialog asking if I want to send more information to Microsoft. I am trying to avoid the possibility of a user getting this message, as it is an "application has crashed" message.
Basically, I want to trap any such error and present a more user friendly dialog, saying that this application cannot be run on that computer.
With the executable built using the v2 script engine it runs just fine, other than reporting the wrong PS version. I get no message that the minimum PS version is v3, despite the first line of the code being #requires -version 3
As I said, if that happened it would be acceptable, but it doesn't do this.
I do understand what you are saying about PSS setting the PS version as v2 (as per your previous post), but the thing that really confuses me is that on the workstation where PSS is installed (a Win7 VM with PowerShell v5 installed), if I run the test version check executable on that machine it reports the correct version of PowerShell. If I run the same executable on a virtually identical VM it reports v2.0 as the PowerShell version.
I cannot see any logic to this, and it's why I am so confused.
In an ideal world I would not have mixed PS versions in the network, but this is the real world and I do.
Only the workstations that are configured to do remote user management will have the PS version upgraded to v5.x
What I need to deal with, gracefully, is a user copying this application to another workstation and trying to run it.
So... as I mentioned earlier, I need a reliable way to check the PS version and to be able to deal with the application being run on a workstation with the wrong PS version.
Is there any way to do that?