tags:

views:

157

answers:

8

I would like to be able to do an "inplace" update with my program. Basically, I want to be able to login remotely where the software is deployed, install it while other users are still using it (in a thin client way), and it update their program.

Is this possible without too much of a hassle? I've looked into clickonce technology, but I don't think that's really what I'm looking for.

What about the way firefox does it's updates? Just waits for you to restart the program, and notifies you when it's been updated.


UPDATE: I'm not remoting into the users' PC. This program is ran on a server, and I remote in and update it, the users run it directly off the server through remote access.

ClickOnce won't work because it requires a webserver.

+1  A: 

ClickOnce and Silverlight (Out of browser) both support your scenario, if we talk about upgrades. Remote login to your users machine? Nope. And no, Firefox doesn't do that either as far as I can tell..

Please double-check both methods and add them to your question, explaining why they might not do what you need. Otherwise it's hard to move on and suggest better alternatives.

Edit: This "I just updated, please restart" thing you seem to like is one method call for Silverlight applications running outside of the browser. At this point I'm fairly certain that this might be the way to go for you.

Benjamin Podszun
It's not a website, it's a winforms application.
Malfist
I'm not sure if that is really a problem for ClickOnce. That excludes Silverlight of course (Winforms vs. WPF). You need to find a way to make new versions available for your deployed apps anyway (how else could they update themselves). What are the requirements here and why is a webserver a deal breaker?
Benjamin Podszun
+3  A: 

I had some example code that I can't find right now but you can do something similar to Firefox with the System.Deployment.Application namespace.

If you use the ApplicationDeployment class, you should be able to do what you want.

From MSDN, this class...

Supports updates of the current deployment programmatically, and handles on-demand downloading of files.

Austin Salonen
That requires ClickOnce, is there a way to do that without using ClickOnce?
Malfist
I commented on your question update. You don't *need* a web server for ClickOnce.
Austin Salonen
+2  A: 

Consider the MS APIs with BITS, just using bitsadmin.exe in a script or the Windows Update Services.

kenny
+1  A: 

Some questions:

  1. Are the users running the software locally, but the files are located on a networked share on your server?
  2. Are they remoting into the same server you want to remote into, and execute it there?
  3. If 2. are they executing the files where they are placed on the server, or are they copying them down to a "private folder"?

If you cannot change the location of the files, and everyone is remoting in, and everyone is executing the files in-place, then you have a problem. As long as even 1 user is running the program, the files will be locked. You can only update the files once everyone is out.

If, on the other hand, the users are able to run their own private copy of the files, then I would set up a system where you have a central folder with the latest version of the files, and when a user starts his program, it checks if the central folder has newer versions than the user is about to execute. If it does, copy the new version down first.

Or, if that will take too long, and the user will get impatient (what, huh, users getting impatient?), then having the program check the versions after startup, and remind the user to exit would work instead. In this case, the program would set a flag that upon next startup would do the copying, only now the user is aware of it happening.

The copying part would easily be handled by either having a separate executable that does the actual copying, and executing that instead, or the program could copy itself temporarily to another location and run that copy with parameters that says "update the original files".

Lasse V. Karlsen
all files are on the server. Yes, they're running the program from the server I remote into, not locally on their machines. The program really doesn't handle files, just the database.
Malfist
+2  A: 

While you can design your code to modify itself (maybe not in C#?), this is generally a bad idea. This means that you must restart something to get the update. (In Linux you are able to replace files that are in use, however an update does not happen until the new data is loaded into memory i.e. application restart)

The strategy used by Firefox (never actually looked into it) is storing the updated executable in a different file which is checked for when program starts to load. This allows the program to overwrite the program with the update before the resource is locked by the OS. You can also design you program more modular so that portions of it can be "restarted" without requiring a restart of the entire program.

How you actually do this is probably provided by the links given by others.

Edit:: In light of a response given to Lasse V. Karlsen

You can have your main program looking for the latest version of the program to load (This program wouldn't be able to get updates without everyone out). You then can remove older versions once people are no longer using it. Depending on how frequent people restart their program you may end up with a number of older programs versions.

he_the_great
+1 This is called "Bootstrapping" and is the only way that I know of to update the core elements of a binary executable (shared objects, dlls and services still need to be controlled before they can be utilised). The real trickery lies in the UI to let the user know that the application is being unloaded (or to do it without their knowledge behind the scenes).
James
A: 

ClickOnce doesn't require a webserver, it will let you publish updates while users are running the software. You can code your app to check for new update every few minutes and prompt the user to restart the app if a new version is found which will then take them through the upgrade process.

Another option is a Silverlight OOB application, but this would be more work if your app is already built as WinForms/WPF client app.

Nate Bross
A: 

Various deployment/update scenarios (for .NET applications) are discussed with there pros and cons in Microsoft's Smart Client Architecture and Design Guide. Though a little bit old I find that most still holds today, as it is describing rather the basic architectural principles than technical details. There is a PDF version, but you find it online as well:

Deploying and Updating Smart Client Applications

0xA3
A: 
Is this possible without too much of a hassle?

Considering the concurrency issues with thin clients and the complexity of Windows installations, yes hot updates will be a hassel without doing it the way the system demands.

fupsduck