Assembly.LoadFrom, .NET 2.0

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Since we converted our application to C# 2005 and .NET 2.0 our
"no-touch-deployment" mechanism is broken.

The whole deployment is based on a bootstrapper (NetRun) that loads our main
application using Assembly.LoadFrom.

When a client machine downloads the application for the first time,
everything works perfectly. When we deploy a new version of the code
(strongly named) to the server, the clients do not get the latest version.
The old version trys to run and fails.

This mechanism in .NET 1.1 has worked for at least 18 months with no problems.

I put an HTTP sniffer on the server, and when a client with an existing
version of the app loads up, I was expecting to see a request for our new
exe. There is no request by the client for the new exe. If a clear
temporary internet files on the client and try again, the sniffer picks up
the request for the new exe and the app loads as expected.

It appears as though there is some caching happening on the client...if
there is a version of the code on the client there is no attempt to download
a newer version, as it did in the past.

Any help would be tremendously appreciated.
 
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.
 
Back
Top