Command Objects and No FileLoadException?

GlennMiller posted on Tuesday, March 25, 2008

It was our understanding that the BinaryFormater will throw a FileLoadException if your Client side DLL did not match the Assembly Version of the Server side .NET Remoting Host (we are using CSLA 3.0).

Our CSLA Business Objects do. But our Command Objects don't do that. Infact they will still execute fine and return data back to the Client regardless of Assembly Versions (unless we change method signitures).

So, our question is why Command Objects don't throw FileLoadException? I would of assumed that they use the BinaryFormater as well.

The reason we are asking is if our code throws this we kick on some fancy update logic. So, if for some reason the user is in a middle of something and we do a publish... We gracefully update our ClickOnce App on the Client.

Thanks!

ajj3085 replied on Tuesday, March 25, 2008

Well, I'm not sure as to your problem, but how do you gracefully update your ClickOnce app while they are running?  I've had to make sure everyone is out before I can update otherwise the app stops working.

GlennMiller replied on Tuesday, March 25, 2008

Well maybe gracefull is not exactly what I would call it. Technically you could dynamically update it by unloading and reloading dlls... Our solution for now is on every Factory method in a fetch we catch FileLoadException and re-throw our own Exception. Then we do this code:

Do this in a Background worker thread (so you can have a cool UI throbber stating a new version is downloading.
try
{               
    if (ApplicationDeployment.IsNetworkDeployed)
   {
       ApplicationDeployment updateCheck = ApplicationDeployment.CurrentDeployment;
       UpdateCheckInfo info = updateCheck.CheckForDetailedUpdate();

           if (info.UpdateAvailable)
           {
              updateCheck.Update();
            }
   }
}
catch (Exception e)
{
   return false;
 }
    return true;

After that background worker thread is completed do this:

 if (!(bool)e.Result)
 {
           //Show a Message box that the update failed
  }

            Mouse.OverrideCursor = null;                                                      

            System.Windows.Forms.Application.Restart();

            System.Diagnostics.Process.GetCurrentProcess().Kill(); 

We tried Application.Current.Shutdown();  But there were so many cases in our code where we were calling remoting portal stuff on closings of windows...

Ok, so it's not 'graceful'... But it's better than having your App have a scary crash message that the user won't understand. This is our first pass. Later we would like to do dynamic updating of DLL's and reloading them.

Anyway for this to work we are reling on CSLA to throw a FileLoadException. However, Command Objects don't do that... So we might have to throw a version number that is set on Login within the Principle Object. But the problem with that is it junks code up and we will have to Extend base classes... So, if anyone knows of a tweak to get FileLoadException to throw in Command Objects that would be great.

ajj3085 replied on Tuesday, March 25, 2008

Well, I currently kick them all out knowing I'm doing an update.  But your code could help me get around that.  Thanks for posting it!

GlennMiller replied on Tuesday, March 25, 2008

Just one note... We restarted our IIS process and FileLoadExceptions magically started to be thrown in our Command Objects... Go figure... I hope that stays that way... But... At least we were able to give a tip out in the process!