Do you change the version number and time-date stamp for new versions?
You could also try deleting all local assemblies to remove all possible
incorrect assemblies before trying to load the initial assembly.

Using v1.0 I had problems using LoadFrom on assemblies located on a network
drive. I don't remember all the details but I wound up writing my own web
service that handled the download details and that solved the problem. I was
then able to use Assembly.Load/LoadFrom  from a local drive.

I think the problem is related to the way the fusion layer resolves assembly
references. This is going from memory so I may have it wrong....when probing
for an assembly fusion uses the simple assembly name looking for a match,
and when it founds one it loads it up and compares the actual internal
version number to the expected number. If the numbers don't match it fails
immediately and stops probing. It probably finds the old local reference
first, compares it and finds a mismatch and fails, and never tries to
download a newer version.

You should use fuslogvw.exe to examine the actual reason why it is failing.
It is Assembly.LoadFrom's best friend.