I need to update my application from a central server.
The application checks always if it is a correct version, against the server installation.
So when it is not, I need it to update itself.
So how can I copy the EXE if it is running? What solution do I have?
I rename the current running exe to MyTempExe.exe, copy the new exe to the correct location (request elevated privileges if necessary) and then run a separate app to restart the main app. On start up I check for MyTempExe.exe delete it if it's there.
The reason I use a separate app for the restart is I don't have a set time frame for the app to close down and need to wait for it to finish whatever it's doing, on shutdown it writes information to disk about its current state that the updated app will use to resume where the old one left off.
I don't know if it's the best solution but it's the one I use.
As you can see by all the answers there is no set way to do this, so I thought I would add the way we have successfully done this.
We never run an application directly from the network.
We run the application from the local machine and have it copy from the network on startup.
We do this using an application launcher. It downloads an XML file that contains CRC and Version Resource Values for the application files. The XML File is created during the deployment process, in a FinalBuilder Script.
The application then compares the XML File to local content, and copies down needed files. Finally we then launch the application in question. This has worked well for deploying an application that serves around 300 local users. Recently we switch from a file copy to an HTTP download as we found problems with remote user disconnecting drives.
We still still build installations (With Innosetup) to get the basic required files deployed.
Package your app with an installer such as Inno. Download and execute the installer. Have the installer search for and kill your app, or instruct the user to close it. The setup will replace your .exe, and if the app can't be killed or the user is non-cooperative, it'll issue a re-start notice.
Download new EXE to TEMP
Create Batch from EXE, content:
taskkill /PID %process id of running EXE%
copy %new EXE% %running EXE%
%EXE%
all values in %...% are placeholders
execute batch from the running EXE
delete batch
I use TMS TWebUpdate myself, for software updates. The advantage is that there a bunch of extra actions you can put into the script, if you need anything other than plain EXE updates.
I have two components at work the application executable itself and a web-service (SOAP) which provides version details and file downloads.
The application calls a method on the SOAP service to ask for the number of files in the project (project is identified by using the application.exename usually).
The soap service gets its info from an INI file, which has entries like:
[ProjectName]
NumberOfFiles=2
File1=myapp.exe;1.0.0.1
File2=mydll.dll;1.0.0.2
You just update this file at the same time as uploading your new files.
The process of updating the application this:
Get number of files available on the web service
For each file, the application asks for the name and version number from the SOAP server.
The application compares this information to its own version info and decides if the file needs updating, building a local list of files that need updating.
For each file that needs updating the application downloads the file to filename.ext.new
Finally, the application renames all filename.ext to filename.ext.old and renames filename.ext.new to filename.ext and then restarts itself. (No real need for an external app to restart your own program).
Note 1, that you may have to ask for elevation to replace files, depending on where you install your files.
Note 2: be kind to your users, think carefully before you force updates on users.
Note 3: You cannot delete a running exe, but you can rename it and then restart the new version.
Edit===
For some reference data files which cannot contain version information resources, you can have entires like File99=MyDataFile;1.1.2011 the 3 elements to the version number indicates to the client that it should check against the file date/stamp.
You could have a separate update executable whose task is to check the server version, download an updated executable if necessary, and then run the local executable.
Or you could have one executable running in two different modes: 1. on startup, check for an update, if there is one, download the executable to a download directory, run it and quit.
2. The new executable would check if it's running from the installation directory, if not, it would copy itself there, overwriting the old version, start the copy from there, and quit.
My way is the other way round: If a new version is online, promt the user to update. If he want's to (or is forced to...) I end the app and start a new exe (updater). this updater loads the update and replaces the old exe (not running). then it starts the new exe. ready. (You can of course replace other files too.) BUT: Using an Installer like InnoSetup gives you more possibilities and doesn't mix up with the regular uninstaller, so it is really better...
You can do this without running another application. Push the updates to the client from the server while running, storing in a temporary directory on the client. When you want to upgrade move all your running files to another temporary directory, move the new files into the original application directory, and just restart the application using the standard executable name on shutdown.
I upgrade client applications running on unattended machines automatically this way.
Related
C:\share is shared folder.
C:\share\electron-v13.0.1-win32-x64, \\192.168.1.10\share\electron-v13.0.1-win32-x64 and Z:\electron-v13.0.1-win32-x64 are same folder.
Electron app is launched correctly when I execute C:\share\electron-v13.0.1-win32-x64\electron.exe command.
However, electron app is not launched correctly when I execute Z:\electron-v13.0.1-win32-x64\electron.exe command.
According to the task manager, electron processes are running.
However, electron's window is not shown.
Can electron run correctly on shared folder?
Should be safer to use it locally (from the C:\share). The mapped drives behave very differently compared to local filesystem. And their implementations can differ in their settings as well:
https://wiki.samba.org/index.php/Time_Synchronisation
https://www.truenas.com/community/threads/issue-with-modified-timestamps-on-windows-file-copy.82649/
https://help.2brightsparks.com/support/solutions/articles/43000335953-the-last-modification-date-and-time-are-wrong
If I understand you are just mapping back your own shared folder, and overall the Windows server cofigurations felt to me more consistent, however the protocol changed over the time as well:
https://en.wikipedia.org/wiki/Server_Message_Block
I do not understand the network sharing protocols well to give you exact answer why you have the problem, but I know enough to tell you that the mounted shared folders are not like your own local filesystem. In many cases the differences do not matter and it gives great user expierence, but in some cases these minute differences break things in misterious ways, even if they are mapped/mounted almost like a regular/local drive. This is not exclusive problem to Electron.
And that is a problem with a lot of things through SMB (mainly binaries/tools), the shared folder might be running a different filesystem, different permission and privileges (or run a completely different structure of permissions underneath if it's a completely different filesystem). Remote folders might have issues with inotify getting events on file updates, might miss changed file (like touch on Linux is meant to update date on the file), so through shared folder the date updates might be delayed/rounded. I think at one point even Makefiles were misbehaving as it was depending on the access-date to work the way it would locally.
Other problem with tools is the sharability, can it handle run multiple instances from the same location? Is it saving something into a ./tmp or some other file which could conflict with other user running it at the same time?
Overall with shares I tend to use them for data (and few times had issues with them as well), but have shared remotely applications only if they are known to not cause troubles.
I'm developing an App using the latest version of Electron-builder (using AutoUpadate).
Is there any way to know that the App is running for the first time after installation?
Ps: I have tried using electron-config but the user data files are not deleted after uninstall, and I needed to do some things with every installation (even if it's on the same machine).
Check for the squirrel-firstrun flag:
var cmd = process.argv[1];
if (cmd == '--squirrel-firstrun') {
// Running for the first time.
}
(you don't need to install anything for this to work)
Ref.
Your app could, in case that it doesn't exist, write a folder/file (with filename based on a timestamp?).
When app starts, always look for the file.
If there is no file, means its first time, do what you want and write file.
If there is a file means it's not the first time.
Don't know if there is something at Electron API!
I have task to deploy my grails application on remote office. It was far from my current location and it would be waste of time to travelling there to send update.
But I got another problem, we have slow, unreliable and limited quota for internet connection (3rd world country problem). 1 war file is about 55-60 MB.
I also don't want to send my code to them and let them compile and run it.
Could we use SVN/GIT just to send the update of compiled class to them ?
if yes, how to do that ?
If your application is having <Context reloadable="false" /> then
You can simply replace the class files(which are changed) in the location
apache-tomcat/webapps/applicationName/WEB-INF/classes
You could use something like rsync (or robocopy if you're on Windows) to copy to your remote office. That way, for each update, only the changed parts need to be transferred over the network and you should have less data sent. You could rsync the WAR file itself, or a directory which is the WAR file exploded (uncompressed). One might be more efficient with network traffic than the other, but you'd have to test that yourself if you wanted to go that far.
Also, don't forget that Groovy is compiled down to Java class files. So even if they don't have your source code they can decompile the class files and get source out of it (even though it won't be as pretty). This is worth remembering if you have any "secrets" (database password, etc.) in your source code.
I have a windows service which downloads some files from SFTP and uploads it to database and generates PDf's from that data. So now when i should give the executable files to my client i think he need to change the app config file like sftp details and the pdf paths. So i am just thinking about a program like a windows forms or a console which reads the input and save those in app config file. Is it possible like and by the way i have created a setup project for the windows service where he gets 2 files .msi file and setup file. Is it possible to achieve the above problem in this case ?
If I understand correctly, you're wanting some kind of UI application that allows the user to configure the operation of the Windows service. This is certainly possible as I've been doing it for several years now. However, you don't want to do this via the app.config file. The app.config file is read by the Windows service when it starts up, so any changes made to it would go unnoticed until the service restarts. A better course of action would be to communicate the changes to the service via the Windows Communication Foundation (or some other ICP mechanism, e.g., pipes, sockets, shared memory, etc.). I've managed to use this successfully, although to be honest, I'm using ordinary sockets now. In any case, the service would basically "listen" for incoming configuration messages, "read" those messages, and then "configure" itself accordingly, perhaps even saving the changes in its app.config file so the changes are preserved for when the service restarts later.
HTH
I'd been working on a plugin when I discovered this. I can't say for sure if this behavior happened before or not on my machine (it doesn't on our test server, a Linux box), but after attaching a file, I can't delete it until the server restarts. I can't delete through the UI or by manually navigating to the server directory and trying to delete from there.
Has anyone ever encountered this before? Could it be something environmental on my box??
Most probably it's a permission issue in that folder, which allows your JIRA user (a user under which privileges JIRA instance runs) to create files, but not to delete them (or something even more fun) :) Try deleting the temp folder (where your uploaded attachments reside) and recreate it again, adding your JIRA web user to the access list for that folder.
The workaround to delete files, when some other process is holding a lock on the file, without having to terminate that process, is to use Unlocker. But be warned, when Unlocker unlocks a file it does that in a way which does not notify the lock holder that the file has been unlocked by force. That means that the lock holder still thinks it holds the lock on the open file which it doesn't (the file handle is invalid). That means that some applications might crash due to unexpected state of the supposedly open file. Btw, I've been using Unlocker since forever and it rarely caused any crashes, but it's better to be warned.