LiveUpdate logic

outstanding... you rock!

http://www.code-magazine.com/Article.aspx?quickid=0307061

Is that posted online somewhere?

Have you looked in Code Magazine, they had a wonderful article in the Jul/Aug issue. Covered this topic nicely.

The best method depends on the size of the application and the files. I mean, we have our application divided into reasonable components, using reflection to load the assemblies that application automatically downloads the components from the server. Now, you must set up the trust level on .NET to download them, but for a user, they do two different things to update the components, either go to a part of the application that hasn't been updated, and the components will be downloaded. We try to keep the components to less them a 1 MB, or click on a button that updates all of the components. Now, if you are using dialup for access, updating all or different parts of the application can take time, but with the small re-usable components ONLY the dlls that are different are updated. FTP is a much cleaner and faster way to transfer files, but I wouldn't use it for the end user, and I wouldn't build it into the application. If you are receiving files only, nothing is wrong w/ HTTP. It isn't "slower" then FTP, and I think that is a good way to go. It really depends on how often your versions will change and the size of your files. We use reflection to instantiate the first assemblies, and it gets all necessary assemblies from a URL, it is seamless to the user, except for a small wait on dialup, and it doesn't require special firewall configurations that FTP might.

I would assume you are transferring files. HTTP is only when you can't use FTP OR need to transfer only small data. FTP is a cleaner and much faster way to transfer files.

Okay, lets lead this topic in another direction for a moment...what is the best method of transferring files from my server to my desktop? I could use FTP, I suppose could serialize them.. whats the best practice?

You can divide the versions in different levels - major version and minor version. In one of my projects, I had an Excel application talking to Web services and when there was a new version of the Excel App, user gets notified there is a new version available and you must download it. So I had a major version number in web.config or database on the server, which will be updated every time I update the app. Similarily you can apply on any file. Similarily your client application will have a major version number on the client. So every time a user start the client app, first thing, a client app will check the major version. If version matches, no need to do extra work. After that you can assign versions on the assemblies or files or services. When major version is changed, you can look for lower level versions. Keeping the version info in a database or XML files would be a good idea. You can simply have one of your Web service method returing version information (XML document containing major and minor versions) and parse it on the client.

Hmm.. I really haven't thought about that. You could use the Webserver itself, to have all the files on there, then depending upon the HTTP code, I think 302 is unmodified, then it wouldn't need to get anything, if it is different then it would download it. I'm not really sure, because I haven't done anything with files besides assemblies.

Well, here is my thought.. I will eventually have items beyond just assemblies that need to be downloaded to the user's machine. I was thinking of just keeping a master list of files in a database table, and sending those to the user via a Web Service. Is there a better way to go about this? -James

Yeah, .NET was taking this exact situation into mind when doing building the framework. I have experience with this. What type of exact questions do you have about it?

This is for an internal application, to be used by our companies employees. In the past, deployment and updates have been a nightmare. My plan is to create a stub app that will be launched, check for and download updates, then launch the main app. This way the user doesn't get the choice of being a schmoe and not updating their application when they are told to. It really isn't all that hard, and I've got the layout done in my head, I was just wondering if anyone else has written this type of thing into an app before. -James

Now, you want to update them as needed, you meaning as part of the application? Or do you want to update them using a service which will poll the webservice for new assemblies so often? Like the "windows auto update" does? Or something built into the application, so when it starts it will get the latest assemblies? Morgan