I am trying to create an updater for a screenshot application I have.
I've done the main part of downloading the update, but I now need to find a way to rename the new file the same as the existing one -
e.g. "NewFile.exe" > "ScreenshotApp.exe".
Also, I don't want to add another .exe solely for updating, just for the purpose of keeping it light and portable.
Is there any way of renaming a file that's in use?
Perhaps telling Windows to rename it AS SOON AS the application has closed itself?
Option 1:
Have launcher which most likely you want update that will handle updating your application as well as launching.
Option 2:
Have external exe monitoring updates and updating your app.
Option 3:
Cretate batch file that will update your app whenever your done using it.
Option 3 is the one you are looking for but it is the worst. If anything goes wrong the app wont work and if user can live without it, they wont reinstall.
Option 2 is mostly used by bigger players. They either work all the time or are scheduled.
I would do option 3, it is much easier than you think, and if you want single exe, just make your app a dll, you can update it whenever you want but launcher will stay the same. That way you can handle any errors, and fix them if there is need for it.
Option 4 would be to run installer with fresh update that will close app install update. That solution is better to buy. For $250 you can get neat stuff where it would take you a lot man hours to o something even remotely close.
Related
My application updates(running a vba script) an excel shared workbook, and since it is shared, there shouldn't be problems when someone else is using the same file at the same time. But for some reason, sometimes it simply freezes, without any error message, just freezes.
Is there a way to programatically make the application stops/closes automatically when frozen or after some minutes(In normal conditions, this updating process shouldn't take more than 1 minute)?
And, if possible, re-launch the app again automatically after some minutes for at least 5 attempts?
This way would ensure process completes succesfully.
I have had to do this same thing before but because I had an application that would look for updates to it's self on the network and then update it locally. Problem is, you cannot update the exe that is running.
What I did to get around it is to create another program that would wait a second, update the exe, then run the exe again.
Because I did this with a few different apps, I made my "Updater" generic so I could send some command line parameters and it would use those to copy and run.
If you want to try something else, you might be able to accomplish this same thing by creating a BAT file and running it. I'm not real good on BAT files so I can't help you there. But, it is another way to handle it.
When creating Metro applications in XAML/C#, how do I detect when the application is first installed or run for the first time since installation (or potentially upgrade)? I need to use this opportunity to ensure that my database schema is correct and potentially synchronise some base data.
I had hoped that I could pick this up from the LaunchActivatedEventArgs within the OnLaunched method, but there does not seem to be a valid value for the Kind or PreviousExecutionState that I can use.
Thanks.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.localsettings.aspx#Y0
When your app starts, write a setting called "AppHasBeenStarted" or something to LocalSettings. If the setting has not already been written, you know your app hasn't been started before. And you could improve on this, by making it "AppVersion", and writing the app's version. This way your app can detect upgrades by comparing the stored version with its own version.
I have a small VB .Net application that, among other things, attempts to substitute system wide typed text by the user(hotstrings concept). To achieve that, I have deployed 'ahk2exe' and 'AutoHotkeySC.bin' with my application and did the following:
When a user assignes a new 'hotstring':
Kill 'hotstring' exe script file if running
Append new hotstring to the script file (if non exist then create a new one)
Convert edited/new script file to exe (using ahk2exe)
Run the newly converted script exe
(somewhere there I also check if the hotstring has been already assigned)
However, I am not totally satisfied with this method for the following two main reasons:
The extra resources deployed with the application.
Lag: The time it takes for the system to kill the process and then restart it takes a minimum of 5 seconds on my fast computer and more on other computers. That amount of time is much more than the time it takes the user to assign the hotstring, minimize/close the window and then test his/her new hotstring. When the user does so initially with no success they will think the process failed. So this method is not very good for user experience.
So, I am looking for a different method or implementation. May be using keyboard hooks? Or maybe adding a .dll library that achieves the same. Are there any resources you know about that might help (free or commercial)? What is the best way to achieve my desired goal?
Many thanks for your help.
Implementing what Autohotkey does would be a pretty non trivial task.
But I'm pretty sure that AHK supports an "autoreload" option for scripts
googling "autohotkey auto reload" turned up several pages discussing that very concept. IF that worked, all you'd have to do is update the script file and that's it, AHK should automatically reload the script.
I'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.
A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.
I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.
This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.
If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.
Is there an issue with having only one installation of your program? Is it particularly large, for example?
Do you require admin privileges to run your program?
If not, odds are you don't need the Program Files folder.
I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.
If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.
Edit: Just saw your last sentence. ClickOnce can force the user to update.
A couple of things:
If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.
We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.
Cheers !
Edit:
Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.
A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).
One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.
You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)
I am writing a custom xulrunner-based app and I wish to have some files deployed in the user profile the first time the application is run.
I placed the files in my application's defaults/profile directory but they did not get copied to user's profile during the first run of the application.
Should I write some additional code or this should happen automatically?
The thing that gets copied for sure is the application default preferences.
Is there a "standard" way offered by Firefox or some of the many mozilla applications?
Any link to some reading will be helpful.
Any hint is valuable.
Thanks in advance.
Unfortunately the standard way of doing first run code is to use the pref system to determine if you have or haven't done something yet. There are a few gotchas though:
Make sure this code only runs once. If your firstrun code is in an overlay or main browser window, it can be run multiple times (once per window)
after you run the code and set the pref, make sure you flush the prefs, since prefs are written on close and will only be saved when you close.
Components.classes['#mozilla.org/preferences-service;1']
.getService(Components.interfaces.nsIPrefService)
.savePrefFile(null);
You could also use the preferences system in concert with querying for an extensions version number. When the version changes, call your function. That would allow you the flexibility to call the function again later if you want - but only at a version change.