I have my Business Objects in a separate DLL from my Application Exe. One of the problems I've always had in installing Updates , where if there are any users actaully using the application, they need to logout before the update is done (as the .EXE will be In Use). A lot of the time, the only reason for an update would be a change in the business rules, and the Application.exe would not have changed, but the BusinessRules.DLL would have.  In my innocence, I thought that this restriction might not be there for the .DLL, but having tried to over-write a DLL with he application in use, it would not let me. If somebody could confirm that, no you cannot overwrite a DLL if the exe that uses it is open, or perhaps there is another way of over-writing a DLL if the Exe is in use. It would make life a lot easier for updates if even the Dll's could be over-wriiten (if not the Exe).

I'm not an expert but here's what I think is happening. When you start your application, .NET starts up a Win32 process and loads your application into it. This includes the exe and any referenced assemblies and any assemblies they reference, etc. This locks those assemblies in the file system. 

The typical update scenario is to do when the application starts. At that time you check for updates and then do them. Typically you have to start the application via another exe, which then loads the actual application dynamically (so the files aren't locked). Or it could start up another update process and close itself down.  There are third party tools to get this done and MS tool, ClickOnce does it as well (but there are limits to using ClickOnce).  You can search the forums for installation you'll see a number of topics on this subject.

There is also Shadow Copying, which I think is new as of .NET 3.0. This allows assemblies that are loaded into an application domain to be updated without unloading the all AppDomains using it, handy if the app must be up at all times.  Here is the MSDN article on that.

Shadow Copying Assemblies

Hi Gerard,

As far as I know, you cannot overwrite a DLL or any other file which is in used unless using a setup program which will force you to reboot and then overwrite the file when not in use.

With the help of AppLife Update, I have been able to automate my update process giving my customer a much more pleasant experience.  With AppLife Update you setup some properties and when the user initiate the search for update, if one if found then the user have the option to download and install the update, AppLife Update will close the application, apply the update then open the application again for the user to continue working.  It can be setup to handle from simple to super complicate process, I even deployed .Net 4 runtimes using AppLife Update without user intervension and many other goodies like adding/deleting files, registry keys, etc.

Edhy Rijo

Hi Edhy.

With ApplifeUpdate, if you want to do an upgrade (Say a few DLL's have chnged as well as the Exe) and there are 10 users on a LAN using the App, are you saying that this can be done for say 1 user without requiring the other 9 users to exit from the App. Do the other users also get updated ?

How is your application installed on a network?

1. On a shared path?
2. On each workstation and database on a server?
   

The setup I use is to have the application installed and run from each workstation, not LAN sharing other than the connection to the database, so with this in mind, one user update is totally isolated from the others in the same network.

What I do is have a setup table in which I save the current application version and compare this with the main EXE file version and if different, then call AppLife Update to update that workstation, so after one workstation have been updated, all other workstations will check their version with the setup table and will also be updated on the first try of use of the application.

About AppLife Update, there are many features I am still not using, so if you have an specific question, feel free to contact Brian Haas directly since he can give you a more detail answer on specifics needs and he is very responsive with excellent support which may include sample code if needed. 

Edhy Rijo

Hi Edhi

Am just starting to roll out a few apps now (Dot net ones) . Historically, always just had one Exe on a shared drive, just means one exe has to be updated. I can see the benefits of having it on local pc, but in a lot of our sites this may cause a problem as there are lots of users logging in using Remote Desktop. Database would be on a central server.

Hi Gerard,

I see.  I know that there were issues before running .Net applications from a shared path due to security configurations, I believe that changed with version 3.5 but I have not tested that configuration.  I used to do that with my Visual FoxPro applications, but due to the .Net security limitations when I started with it, I got used to just install on each workstation.

Again, check with Brian since he will be able to give you an specific on how AppLife Update may help you in your configuration, but almost for sure, if many users are sharing a file (any file) and you want to replace it, they will have to stop using it so it can be replaced. 

In my setups I have two versions to control the application and the database, and I force the application to be updated if the database version has changed to avoid errors with the BO library.  So far this has been working very stable with no reported issues for over 6 months on a 10 user network and many minor updates using AppLife Update.

Edhy Rijo