SQL Server 2012 syspolicy_purge_history Error: “Could not load file or assembly ‘Microsoft.SqlServer.Management.PSSnapins.dll'”

I came across this error recently on a VM with multiple SQL Server instances installed. Initially a SQL 2016 instance had been installed & some time later a SQL 2012 instance was also installed.

From the start, the syspolicy_purge_history on the SQL 2012 instance was failing on step 3 (Erase Phantom System Health Records) with the following error:
A job step received an error at line 1 in a PowerShell script. The corresponding line is ‘import-module SQLPS -DisableNameChecking’. Correct the script and reschedule the job. The error information returned by PowerShell is: ‘Could not load file or assembly ‘file:///C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\SQLPS\Microsoft.SqlServer.Management.PSSnapins.dll’ or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

The file location C:\Program Files (x86)\Microsoft SQL Server\130\ suggested that the job was looking in the SQL 2016 directory for the file which could explain why it was failing due to a newer runtime than it was expecting.

After some Googling to see if anyone else had encountered a similar problem, I found the a question on social.msdn.microsoft.com that suggested that the PSModulePath may need to be updated. Sure enough, on opening the Environmental Variables in the VM’s Advanced System Settings, I found that the PSModulePath was set to %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules\ (note SQL 2016 (130) appears before SQL 2012 (110)).

By changing the variable value for PSModulePath to %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules\;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\ so that SQL 2012 (110) appeared before SQL 2016 (130), the error in the syspolicy_purge_history on the SQL 2012 instance was resolved.

This had no effect on the equivalent job in the SQL 2016 instance, which succeeded regardless of which way the variable value for PSModulePath was set.