Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have several game servers that use a certain .dll file to run. Sometimes I need to update the game servers but I don't wanna interrupt the games that are already running.

Is there a way to replace the .dll file (it's locked by Windows) so the next instances of the game servers that use that file open the new version, and the old ones keep using the old version of that .dll until they are restarted?

Is it safe to just unlock the file using one of those tools that do that and replace it?

share|improve this question
    
Perhaps not your game. However Chrome does update without interrupting your process. Unfortunately, this is application -specific. (Go to %LocalAppData%\Google\Chrome\Application and you should see folders like 26.0.1410.64 which stores DLLs of different versions) –  Alvin Wong Apr 30 '13 at 3:16
    
Depending on the software in question, it might be possible to install and run two or more distinct instances (in different locations). Inefficient, but perhaps workable. –  Harry Johnston Apr 30 '13 at 5:08
add comment

6 Answers

up vote 4 down vote accepted

Actually, you can and it usually works without any issue (although not always)

What you do is rename the file without moving it and move the new file over it. That will keep the handles to the file valid and working so that pre-existing instances still will be able to access the file properly and new instances (or new handles) wil go to the new file.

Obviously, if a program re-opens the same dll file and expects it to stay exactly the same (for instance, if there is resources to be loaded from the dll and that references to these resources is extracted from code running when the dll is loaded), this will cause issue but this is definitely not the norm.

share|improve this answer
add comment

No. Even though a DLL may be entirely mapped into physical memory while the application runs, there is definitely no guarantee of that. Portions of DLLs (and even executables) can be mapped into RAM while other bits of it stay on disk, and may be read in at a later time.

Changing the file on disk while Windows has bits of it mapped in RAM would not end well. Windows locks it for a good reason.

Edit: I need to clarify something since some people seem intent on blaming Windows for what is actually an application design issue, not an OS design issue.

You can update DLLs that applications use in Windows without terminating the process, but the application must have been written in such a way that it can be signaled to unload the assembly, wait for the update to finish, then reload the DLL. This has nothing to do with the OS you're running. It's an application design issue.

Edit: Also see Stephane's answer for a possible solution that might work, depending on how your specific application responds to its DLL changing. I think he deserves an upvote.

share|improve this answer
    
Is there any way to move that file to a temporary location so it can be deleted later, while putting a new one in its old location (so servers that start after that will use the new dll)? Or is the file handle linked to the file location? –  user54048 Apr 30 '13 at 1:21
    
That entirely depends on how the application is written/how it uses DLLs. Take a look at Greg Askew's answer. If the file handle is open there's not much you can do about it. You can forcibly close the file handle but you'll almost surely crash at least your app, if not the entire OS. –  Ryan Ries Apr 30 '13 at 1:58
    
So what is this “good reason”? So far your answer doesn’t contain a compelling reason why Microsoft doesn’t offer the ability of hot-swapping. –  Konrad Rudolph Apr 30 '13 at 8:41
1  
Linux can seamlessly upgrade dynamic libraries while they're in use. From what I understand, it accomplishes this by loading the entire library into RAM when it's called on, so any running applications will keep reading it, and any newly started program will load the new one. Just about the only possible downside is a gradual and very slow memory leak if some process remains unrestarted for years on end and through several dozen updates. The only "good reason" windows could possibly have to not do the same is "incompetent designers". –  Shadur Apr 30 '13 at 9:27
4  
@Shadur I wish I could downvote your inapplicable and ill-informed comment. Your conflating of OS design and application design just so you get a chance to say "Linux rules" is beyond unhelpful. You can update DLLs that applications use in Windows without terminating the process, but the application must have been written in such a way that it can be signaled to unload the assembly, wait for the update to finish, then reload the DLL. This has nothing to do with the OS you're running. It's an application design issue. –  Ryan Ries Apr 30 '13 at 14:30
show 1 more comment

No, you should not tinker with the existing file handles.

If you can take control of the loading of the assembly, and specify it is opened with FileShare.Delete, then it should be possible to rename it. Existing processes will continue to reference the renamed assembly.

http://stackoverflow.com/questions/7147577/programmatically-rename-open-file-on-windows.

share|improve this answer
2  
In my experience, in most cases (well, more than half the time, at any rate) you can rename (but not delete) a DLL without any tinkering with the application. –  Harry Johnston Apr 30 '13 at 5:07
    
@HarryJohnston: Yeah it seems I can rename the .dll even if it's in use. I guess I'll do that from now on. –  user54048 Apr 30 '13 at 15:45
add comment

No, unfortunately it is not possible.

Sorry, to be exact unless there is late binding, meaning the app uses that dll when runs some part of code in that dll, but it is still not reliable.

share|improve this answer
add comment

You could look at how the asp.net hosted process works and develop something similar.

It takes the whole web application and moves it to a temporary location from which the application is actually loaded. Then it leaves a process to monitor for changes in the original folder, when detected, it spins up a new instance of the application in a new temporary location and starts redirecting new requests to that app. The old app is then torn down once pending requests are finished.

(Nitpicking, yes, it's a simplified view of things, in most cases IIS queues the requests until the new app is able to take over)

share|improve this answer
add comment

About a decade ago, I was a happy user of http://www.eggcentric.com/ISAPILoader.htm which did live IIS ISAPI dll swapping. Mr Egg is still supporting his FOSS solution.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.