So, after checking out the binding context options, you've decided to switch your app to use the Load context. Now, you just need to figure out how to do it.
Maybe it will be as simple as using Assembly.Load(assemblyDisplayName) instead of Load(byte), etc. That will work if the assembly is available in the GAC, the AppDomain's ApplicationBase, or a PrivateBinPath beneath the ApplicationBase. If the assembly is not already in one of those directories, consider changing your deployment strategy.
"I won't use the GAC because I want to have my own shared path outside of the ApplicationBase" is NOT a good answer! Don't be afraid to move away from old habits. You're losing out on all of the benefits of the Load context/versioning and asking for the pain of the other contexts if you don't. If this is what you're doing, I recommend putting these in the GAC instead.
If it's really not possible to deploy those assemblies differently, then creating a new appdomain may be right for you. Create a new AppDomain using an AppDomainSetup.ApplicationBase set to the dir containing the assemblies to load. If you have multiple directories that you want probed, you can set the ApplicationBase to a root directory, and set those as subdirectories to be probed using AppDomainSetup.PrivateBinPath. If that won't work for you, consider creating multiple AppDomains, each with the ApplicationBase set to the appropriate dir for its assemblies.
Once you have created the new AppDomain, you will need to find a way to execute code in it. See my blog entry, Executing Code in Another AppDomain for more info.
Note: you can still call LoadFrom() on these assemblies, but they will now be placed in the Load context (as long as they are the first available by that name in the GAC/probing path). However, if at all possible, switch your call to use Assembly.Load() instead of LoadFrom().