Beware of [System.Reflection.Assembly]::LoadWithPartialName!!!

If you've been in the Powershell world for any length of time, you will most certainly be familiar with this construct:

[System.Reflection.Assembly]::LoadWithPartialName(...)

This is how we quickly add DLL references to Powershell scripts without having to know the entire name of the DLL in question e.g.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint");

which loads the Microsoft.SharePoint.dll and makes all the SharePoint cmdlets available to Powershell.

BEWARE!!!  In some cases, quickly = lazy = bad.

If you are referencing a DLL that may have more than hone version on the host system, it becomes imperative that you ensure you are actually loading the right DLL.  I recently ran into this kind of thing when a script was trying to execute some TFS 2015 commands.  The script would fail however, apparently without any logical reason.
It turns out, the reason was quite logical after all.  The script was loading the "Microsoft.VisualStudio.TeamFoundation.dll" using the LoadWithPartialName() method.  Even with the TFS SDK installed, the script would load the wrong version of the DLL since the 2013 version of the exact same named DLL was in the GAC.  Since the GAC trumps everything else, the script would load the old version of the DLL from the GAC and then try to use it with newer versions of related DLLs, hence the failure to execute correctly.

If there's ever any doubt, rather use the best practice LoadFrom() method thus:

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\ISAPI\Microsoft.SharePoint");

This way, you're 100% guaranteed the proper DLL is loaded and leveraged in your Powershell script.

Enjoy
C