Imagine I have an AIR application to update: the preceding version number is 0.0.1, the current one is 0.0.2. Now, the preceding app is installed on many different pcs. I want to update ONLY some clients, based on a particular ID. Is it possible to skip update process for some clients?
The short answer is yes, it is possible. You can do just about whatever you need if you write your own code to check for updates, download updates to a local file, then call System:Updater.update() or Air.update:ApplicationUpdater.installFromAIRFile() The old AIRUpdater.js example from AIR 1.0 can get your started.
The problem is you'll have to update all of your 0.0.1 clients with new code before they can make a decision on 0.0.2. And if you don't have a good way to ensure they've all been updated before deploying your next version, you'll probably want to change the location of the update descriptor file in your intermediate version. Otherwise you may end up with straggler 0.0.1's that skip the intermediate version and update to 0.0.2 without your ID checking.
And I haven't tried this yet, but it might be even easier to use the newer Air.update:ApplicationUpdater class from AIR 1.5 and put your ID checking in the updateStatus event.
Related
I know that you can upgrade the versions, remove the old the installation and install the new version.
and I know you can also support two installations of the same software on the same machine.
Is there a way to create a GUI installation which let's the user choose if he wants to upgrade or keep the old version and install the new instance in addition to old the ones?
Yes, but it's not simple.
Basically you start with two upgrade table entries. One that is fake and would never detect a product and one that detects your previous versions but has the DetectOnly attribute set.
Next you need to create a custom dialog with a radio button ( install new, upgrade existing ) and a list box to contain the entries of previously detected products. You will use a custom action to populate the ListBox table with temporary rows to reflect the previous qualifying products to be upgraded.
If the user selects Install new, you just carry on. If they select upgrade existing you parse out the product codes from the Detect Only upgrade action property and put them into the "fake" action property. Now remove existing products will have something to remove.
They are all kinds of business rules you'll want to come up with and enforce, cover the silent installation story and also have a way of mutating the INSTALLDIR so the products can be side by side.
That's the basic pattern but you'll have to come up with all the details around it. I've done this several times with very favorable results.
I need some advice about how to clean up an old Wix project that hasn't been managed very well. One problem is that the project currently has multiple entries for the same files, going to the same location. For example, several .wxs files in the project will define a new component for foo.exe, each using a different GUID and each sending this file to the same DirectoryRef. This hasn't yet created any issues, but now I want to use patches (MSPs) in our product and this sort of thing messes with their operation.
I'm wondering about the best way to resolve this without breaking upgrades (since all previous installers have gone out like this). If I simply remove all the duplicate components, we get undefined behavior during an upgrade. I think what's happening is that removing one or more duplicate entries will cause the installer to generate delete operations for that file. Even if the remaining entry for the file is a new version, there is no guarantee in the order of operations during the install. So some of these files will first get updated, then one or more delete operations will remove the updated file. Thus at the end of the upgrade several files will be missing. Running a repair immediately afterwards will restore the files, since the installer knows they are supposed to be there.
I imagine one way to resolve this is to do a one off "hack" in our next release, where we copy these files into a secondary location, then run a custom action post install that copies the files from the secondary location into the primary and delete the temporary directory.
Is there a cleaner way this could be resolved?
What you are likely going to have to do is use validation to identify all the duplicates and fix them. Then change your upgrade to be a major upgrade with the earliest possible scheduling. You may also have to change your install location to a slightly different directory to get around component reference counts breaking.
Once clean you should be able to go back to minor upgrades and start thinking about patching. An alternative would be "fake" patches. I've used an MSI that doesn't publish itself as a hotfix method very successfully. It breaks a lot of rules but can be useful for organizations that don't care about patching rules and just want to make the business happy.
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.
Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.
Lets say I am updating an application and have updated 10 files out of a 100. I made these changes on my test machine and is working but now I want to commit these changes to the production machine. What kind of option do I have.
Ideal scenarios would be.
I save the existing files that I am replacing
I copy new files over the old.
If the changes does not go well, I can reverse the process and restore the old files. What is the best way of doing it. Lets say I am talking about an ASP.NET application. I will also be updating SQL statements, but I can take core of that in separate SQL Script and not worried about that in this update.
I am familiar with Batch scripting but is there a better way of doing it, which has a GUI (Ok I can can create a GUI application and run the batch file from GUI).
Any one who has done something similar?
Your description makes it sound like you want to control your revisions. Use a Revision Control System like SVN or Git (http://en.wikipedia.org/wiki/Git_%28software%29).
At a high level, once you make changes to your code, you check those changes in and get a revision number that specifically identifies the most current state of the files at that time (e.g. revision 17). You could then switch to your production server and update the set of files to revision 17 and then compile/whatever. If all does not go as planned, it is easy to revert to any previous version (say revision 15, which was on the production server before you checked out and built revision 17).
A good RCS will manage all your files so that they are "backed up" and can you can restore the code/binaries/config files/whatever you had at any given time by referring to its revision number.