This question already has answers here:
Why does rename a loaded .net assembly work?
(3 answers)
Closed 5 years ago.
We are trying to push updates to multiple servers at once and my manager has found that it is possible to rename running .exe file. Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
I guess I need to clarify, He doesn't expect the old copy to magically update, he just expects them to keep running the old copy until they open the exe again, in which case it will then open the new one that has the name of the old one.
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed. On my machine I have yet to be able to get it to work even in a loop.
My first and main question is this: Is it ever acceptable to do this. Should renaming a running executable ever be a valid scenario?
Secondly, if it is a valid scenario then how could one reliably do this? Our current thoughts are try a bunch of times using File.Move (C#) to do a rename and if it doesn't work then write out to an error log so it can be handled manually.
An airplane mechanic and a surgeon meet in a bar. The mechanic says "you know, we have basically the same job. We take broken stuff out and put new, better parts in." The surgeon says "yeah, but you don't have to keep the plane flying as you're making the repairs!"
Trying to update an application by moving files while the application is running seems about as dangerous as trying to fix an airplane in flight. Possible? Sure. Greatly increased risk of catestrophic crash? Yep.
If the application you are updating is a managed application, consider using ClickOnce Deployment. That way, the next time someone runs the application, if there is a new version available it will be copied down and installed automatically. That's much more safe and pleasant than trying to mess with an application while its still running.
No, this is not acceptable. Do not do this. This is not a valid deployment mechanism. This should have been yours or his first clue:
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed.
And it won't work, anyway. His theory is quite wrong:
Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
Specifically, the copy in memory will not be automatically replaced with the new executable just because it has the same name. The reason that you're allowed to rename the executable in the first place is because the operating system is not using the file name to find the application. The original executable will still be loaded, and it will remain loaded until you explicitly unload it and load the new, modified executable.
Notice how even modern web browsers like Chrome and Firefox with their super fancy automatic, in the background, no one ever notices that they exist, updaters still have to close and relaunch the application in order to apply the updates.
Don't worry about shooting the messenger here. It's more likely that your customers and your tech support department will shoot you first.
See number 1.
In our organization, we solved the problem of Updates by having two release folders say EXE_A and EXE_B. We also have a release folder called EXE which only has links ALL of which points to either to EXE_A or EXE_B from which the user runs the applications.
When we publish a new version of the program, we publish it to the folder that is not referenced in the links and then update the links (EXE). In this way, you do not get into exceptions that users are holding the application / assemblies. Also if a user wants to run the updated version, all he need to do is close / re-execute the link in EXE folder.
If you use Windows Vista/Server2k8 or newer you could use mklink to create a symbolic link to the folder containing your application and start the application out of the "symblic linked folder" and then at the update create a new folder, e.g. "AppV2" and change the SymLink to that folder, so the next time the user restarts the application he starts it out of the new folder without noticing.
Renaming open files is ALWAYS a bad choice!
But in general I would think of a better deployment strategy anyway, because if you need to use such "hacks" it is always a messy situation. I don't know your application, but maybee ClickOnce would be a point to start, because you can configure it to check for updates on every start...
Related
We have an app we wrote deployed onto our terminal servers at work, and keeping it up-to-date is a bit of a pain.
What update mechanisms do people use for app on terminal servers? At the moment we manually copy the new exe + dependencies on witch is just rubbish.
I'm a bit concerned about files being locked by users when trying to update, i cant really just kill the process in case someone is in the middle of doing something. We would like to be able to handle the odd fat client update as well.
Ideally we'd plug something into teamcity/octopus but are open to suggestions
Create a script that copies the exe file to a user specific temp folder, then launches the copied exe. To make the script more efficient, you can have it check the dates of the files. If they are different, then you copy the file over the old one located in the temp folder, else you just launch it.
There are several threads on SO that describe how to check which application creates a file with tools like Sysinternals process monitor. Is something like this possible programmatically from .net?
Background: My program has to remote-control a proprietary third party application using its automation interface, and one of the functions I need from this application has a bug where it creates a bunch of temporary files in %TEMP% that are called tmpXXXX.tmp (the same as .net's Path.GetTempFileName() does) but does not delete them. This causes the C drive to become full over time, eventually failing the application. I already filed a bug to the manufacturer, but we need a temporary workaround for the time being, so I thought of putting a FileSystemWatcher on %TEMP% that watches tmp*.tmp, collects these files, and after the operation on the third-party application finishes, deletes them. But this is risky as another application might also write files with the same file name pattern to %TEMP% so I only want to delete those created by NastyBuggyThirdPartyApplication.exe.
Is this anyhow possible?
This kind of things is possible, but maybe a bit tricky.
To know who created the file, look at the user that owns it. Therefore you might need to create a specific user, and that application will run under this specific user. In order to do that, you need to create a small application that will start your buggy app by impersonating another user, so anything done within the app will be under this user so as file creating...
I don't know how to monitor and get triggered when a file is created, but nothing can prevent you from setting a timer that wakes up every five or ten minutes, then checks if any file in the directory is owned by the application user and closed, so it deletes it.
Maybe if they react fast for this bug fixing, you won't need your app very long time. So another solution, if possible might just to change the Temp folder into another drive, which has lots of space...
One solution is that you use a FileWatcher to automatically delete all the files but before deleting you should check if the file is not currently locked or used by other process, for example the Sysinternal Suite has a tool called handle.exe that can do this. Use it from the command line:
handle.exe -a
You can invoke this from a c# program (there might be some performance issues though)
So what you would do is when a file is created you verify if it is in use or locked (for example u can use the code provided in Is there a way to check if a file is in use?) and then delete it.
Most of the time when an app is using a temp file it will lock it to prevent just what you fear, that you might delete files from other processes.
As far as I can tell there is no sure way to identify which process created a specific file.
I have the following strange behaviour in my Windows phone 8, C# App.
I am saving a Setting with:
private void SaveProperty<T>(T property, string propertyName)
{
if (IsolatedStorageSettings.ApplicationSettings.Contains(propertyName))
IsolatedStorageSettings.ApplicationSettings[propertyName] = property;
else
IsolatedStorageSettings.ApplicationSettings.Add(propertyName, property);
IsolatedStorageSettings.ApplicationSettings.Save();
}
When the app runs, I can read all settings I stored in IsolatedStorageSettings.ApplicationSettings.
But when I re-open my app (open it from the app list), the IsolatedStorageSettings.ApplicationSettings-Dictionary contains Zero (0) Keys and Values.
Am I missing something?
I used the ISETool.exe to take snapshots of the IsolatedStorage of my app (thanks to chepene).
I saw this behaviour: when I wrote the Settings (that means after the SaveProperty<T>() function finished), and the app is still running, I have the Settings saved in _ApplicationSettings. This agrees with my Observation that I can read from the IsolatedStorageSettings.ApplicationSettings when the app is running.
The _ApplicationSettings-file also exists when the is tombstoned or not running (when I can Access it by Holding the back-button of the phone and when the app is closed with the back-button).
But when the app is opened again (via the app list), the _ApplicationSettings-file is gone...
I also see that, when I'm writing a file into the IsolatedStorage with:
SharedStorageAccessManager.CopySharedFileAsync(
Windows.Storage.ApplicationData.Current.LocalFolder, fileName+"orig",
Windows.Storage.NameCollisionOption.ReplaceExisting, fileID);
and when I then don't read this file, it is gone when I open the app the next time.
By the way, to avoid confusion: I am not reinstalling the app each time I open it.
If you need more Information please ask.
Any help appreciated.
With AppSettings, I've seen something similar on WP7/7.5, but it happened only when my property-value's type was a class that was not known to the serializer.
Are you sure that there were no exceptions:
during Save
during App Exit (since the App may dump the settings at that point)
during the time that App loads the settings for the first time after launch?
Note that this doesn't necessarily must mean the app crashing. I mean, any exceptions, those internally silenced or user-handled too. Please check the VisualStudio's Output panel for "first chance exceptions" log. If any I/O or security or serialization exception shows up, then investigate there. If i remember well, there's even a whole set of isolated-storage exceptions that are easily interceptable from debug/exceptions menu.
However, the issues I had with unknown or nonserializable types does not explain at all why your extra non-appsettings files would evaporate.
Another thought: maybe some additional tool performs something like 'clean deploy' for you? I don't remember exactly, but I think that VisualStudio's deployment cycle was quite plain:
rebuild
remove/uninstall old app from device -- so probably purges isolatedstorage
install new app onto device
So, maybe that's the cause? Hm.. on afterthought and re-reading your question again, you've said about running the app from the applist, so that rather is not the case. Be sure to check firstchance exceptions then!
Thanks to quetzalcoatl I found the solution:
I am storing all my files in the root Folder of my app. At the start I am then reading all my files (via a DataContractSerializer) and casting it to my model. Since it happens sometimes that my files get corrupt, I delete every file which throws a SerialzationException. But as I read every file, and since _ApplicationSettings is not castable to my model, I am deleting _ApplicationSettings automatically.... So I learned that the ApplicationSettings are,just a file in the root folder, which I am allowed to read and delete. So the quintessence is to never write into the root Folder.
I have some code that I wrote to basically clear out the directory every time the program runs through this point. I didn't want to bother enumerating files. If this is a bad way to do this, please tell me.
My main question, however, is about how to deal with the following: one of the files in the folder appears to be in use when it is most certainly not. The program runs on a ButtonClick event, and it exploded the first four or five times, but it worked after I confirmed that nobody was using the file on the server. There is only one person besides myself that would have been using it, and he confirmed that there was nothing running on his side that would be touching the file. Any ideas for what would cause this error/how to avoid it/how to handle it?
I am also having trouble reproducing the error...
string directory = #"\\server\directory\folder\";
DirectoryInfo di = new DirectoryInfo(directory);
if (di.Exists)
di.Delete(true);
Directory.CreateDirectory(directory);
If you are using Windows XP, this may help : http://msdn.microsoft.com/en-us/library/dd997370.aspx#remove_open_handles
Just an extract from the top of this page :
"If you are running Windows XP or earlier, a delete operation on a file or directory that follows an enumeration could fail if there is an open handle that remains on one of the enumerated directories or files."
You may also use a software like Unlocker to identify the process locking your file.
If the file is in use, then someone is most certainly using it. :)
If you can access the server the files reside on, you can use a tool such as Process Explorer to find out which process has opened the file.
How Would I find another exe's path by knowing its name in .net?
Would I add name to the OS environment variable?
Would the other application have to 'register' itself somewhere else?
I need App A to start-up App B and call some WCF services on it.
Thanks!
To answer your question: you cannot know the path simply by knowing the name. An exe can reside anywhere on the file system. There can be multiple instances of it that don't know about each other. Multiple exe files that are completely different can have the same name.
You could take one of several approaches to get round this, depending on the exe you are targetting:
get the user to browse for the exe using a normal file browse dialog
search the file system
see what traces the target exe leaves on the system (filesystem, registry, environmental variables, etc) and use those traces to locate the exe
For either of these options you save the result so you don't have to execute it again when your app is run the next time.
Searching the filesystem could take some time, you are not guaranteed to find the exe (depending upon the user level your app is running as) and you may get false positives, especially if the app is called something dumb like setup.exe.
Getting the user to locate the exe the first time you run is possibly the most reliable way of locating it, but then you have to decide what to do if your app runs but the target exe is no longer at the specified location, or the user has chosen the wrong exe.
If you have some control over App B (i.e. it is your product), then you could consider adding some info to a known spot in the registry when App B gets installed, so that App A can locate it easily. You still need to have a plan B though in case the info is missing.
Reference a path to a shortcut of the exe in the config setting, that way if the exe ever moves around the shortcut will still be up-to-date. Try it, make a shortcut to a exe, then cut and paste the exe somewhere else, then double click the shortcut and you'll see it points to the exe's new location thus will not require changes to app A if the location app B changes.
Really, just make the App B a windows service and start it up when needed.
UPDATE:
Another suggestion would be to create a hard link to the AppB's EXE:
mklink /H AppB-link.exe path_to_actual_exe
Or a symbolic link to whole directory where App B resides:
mklink /D virtual_directory path_to_actual_directory