Launchers are most common in games. Think of League of Legends, Starcraft II, or almost any MMO out there. Before starting the actual game, you have a small launcher app that takes care of updates and patching.
I want to move this direction with a particular non-game application I am developing. The concept of the launcher makes perfect sense: it checks for updates, replaces the appropriate binaries/libraries, maybe runs an integrity check, and launches the application. However, how do launchers update themselves? This tends to be a rare event, but how is it done? Does the launcher literally just write over the very binary it is currently running from? Or is there some kind of swap step after the download? I need to be able to push out (rare) updates to the launcher (especially if I discover some bug in my launcher).
My particular project will be in C#, but I am interested in conceptually similar C++ and/or Java solutions as well for future reference.
I've never tried, but this is what I would guess (assuming you can't overwrite a file being executed. If you can, this is all simpler)
Updater A checks if its the newest version
If launcher isnt the newest version
Download the differences (to save bandwidth) to file B
Apply the delta to own code into file C
Launch file C.
Close
If file C exists (update happened recently)
Try to delete C (update was previous launch, delete temporary file)
If delete fails (We are C, means A is out of date)
Copy C over A (update launcher)
Note that you can keep going, dont have to restart even though we are C.
If game isnt newest version
Download the differences (to save bandwidth) to file B
Apply the delta to game into file D
delete game
Rename D -> game
Run game
André Caron has shown me that the swap trick is done better with transactional file IO.
Basically the launcher checks to see if there is a newer version of it self, and if so kicks off a task to get the new version and then executes it and then closes.
Given the updater app is small and loads up quick, you can have it detect, download, stick up a dialog to say there's a new version, and barely flicker as the old version closes and the new one runs up.
If you are in the .NET world, there is a deployment strategy called 'Click Once'. This was created to solve the problem you have described...
ClickOnce is a deployment technology that allows you to create self-updating Windows-based applications that can be installed and run with minimal user interaction. ClickOnce deployment overcomes three major issues inherent in deployment:
Source: Click Once
Before embarking on this strategy, I suggest researching its pros and cons because there are avid fans and detractors.
Briefly, you upload new versions to a web site (which the application is configured to know about). At start up time, the application checks the site and if there's an update offers the user a dialog. When the user elects to apply the update, the application is stopped and simultaneously a 'click once' component is activated to apply the changes. The component then restarts the executable and this all appears as a seamless operation to the end user...
Related
we are deploying our application with ClickOnce and we noticed that when we start our application by clicking the ClickOnce desktop icon, the application start slower (it takes at least 30-60 seconds more) than while started directly from the .exe.
I've seen that it's not an unkown issue ( Slow startup of Clickonce winforms application after update ) but it seems it's still unresolved.
I'm wondering why that would happen and how to fix that.
I'm only using one machine so I guess it's not machine-related, not antivirus-related.
I'm noticing different memory management pattern during startup: the ClickOnce deployment takes more time and after a while it deallocates some memory.
We are still talking about 12 MBytes in difference ( 67MB via ClickOnce, 50 via direct .exe).
This is driving me nuts...
Thanks
I guess it's not machine-related, not antivirus-related.
You need to prove that hypothesis by installing the same anti-virus your client has on a dev VM. If you cannot reproduce the slow start up compare ProcMon traces between the machines.
I believe Hans is on the money and the anti-virus is the most likely culprit, as per the correct answer in the QA you refer to in your question:
I have seen very poor performance (minutes vs a few seconds) for a newly deployed first run .Net application is the users are running antivirus software as the antivirus tool checks the newly Jitted assemblies are not malicious.
Make sure you're using .NET Framework 3.5 SP1 or above as "there are significant performance improvements in the area of startup. Particularly with WPF applications" and 3.5 SP1 includes Splash Screens.
A Splash Screen could be a quick (temporary) fix. Alas, not an ideal solution.
ClickOnce is getting pretty old now and there have been a lot of advancements in this field so why not adopt another strategy with a different deployment mechanism, such as Windows Installer and an Update Menu in the app. I detail the steps to make an MSI installer to Install to same path when upgrading application.
If you want to be strict about everyone being on the latest version instead of ClickOnce it would be better to have a web service the app pings on start up and downloads and executes the update when a new version is released.
Also, take tips from Google in this area. You remember the Jeff Atwood article: http://blog.codinghorror.com/the-infinite-version/
If you dont use ClickOnce you can use things like NGEN AND bsdiff, possibly even Google courgette.
There's some other ways to speed up the startup of a ClickOnce application discussed here.
While this may not answer your question directly, hopefully it gives you food for thought on how to identify the root cause and/or use a different more up-do-date method for rolling out updates.
When you publish the build please choose the option of running the app in offline mode. Otherwise the clickonce installer will try to launch the app from your server rather than local exe.
Please let me know if there are any other scenarios need to look into or this helps.
Thanks,
I'm currently running VS2013 Update 3, I'm building an app and i;m trying to mimic the Rate My App that shows up rate message dialog in b/w specified intervals.
My problem is that i've made a setting using ApplicationData.current.loclasettings and it is an integer.
and i want to see the settings number being updated every time i close and run the app to ensure the logic is perfect.
but i'm unable to do it. Every time i deploy the app from vs it replace the original app and thus erasing all the settings that have been previously saved.
I've tried to use attach a process but it doesnt work on windowsphones.
Well after a bit of research and going through the documentation it is clear that there is no way you can attach a process to the app that is already running on the phone.
At least for me there was no other way because Microsoft kept the USB debugging thing a little bit undocumented or not documented at all.
So, who ever are looking forward to first launch the app on a connected windows phone and then start the the connect to a process and select the appropriate device for communication , story it is not possible, at least the build that i;m using doesn't support. may there might be a better solution in the future.
Is there any way to access the time the app was downloaded (or first launched, etc) as this would be of great help in implementing my trial run feature on my app.
I don't remember how does it stand on the Win8 platform, but for WinPhone7.0/7.5 there's a clear warning/guideline in the official documents from Microsoft, saying:
Do not rely on usage time limited trials to protect your app’s value.
Typically, it is best to protect the value of your full mode app by limiting trial access to key code paths. A user may uninstall and retry an app without restriction so a trial design that offers full mode behavior for a limited time provides only inconvenience as a barrier to reuse.
Source: Creating trial apps for Windows Phone
The problem in time-based trials is very simple: when you uninstall the application, the Phone's operating system will erase it completely. This means, that nothing will be left, not a byte. If you write any data to isostorage, it will be purged upon deletion.
So, if you make a time-base trial and store a "installed date", then the user will simply uninstall the application and install it again, and will be happy to get next free-trial period. If it is OK for you, well, then just be aware of that.
To make a true time-trial you'd need to create some internet service that your application will register to with the phone's/user's UUID, and then the app would need to check at the service to determine whether the trial has passed or have been used up by a previous installation..
What's more, Microsoft Phone Appp guidelines state that generally you should not create an application that "turns off some of its features" at some point of time. This irritates end-users and the makes the whole phone/platform "bad" from the user's point of view, because people don't like to lose what they once had.
IIRC, at some early point of time Microsoft even advised to create two separate applications: one free and without the extra features at all, and one paid with all extra features. Later, TrialModes were included in the Market's workflow and Microsoft's App Licensing API introduced a very easy way to determine if an app works in "free trial" or "fully paid" mode, depending on whether it was downloaded from the market for free or not.
I truly don't know which one is most-recent, so let me paste three:
XNA: http://msdn.microsoft.com/en-us/library/dd282459(v=xnagamestudio.30).aspx
SL: http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.marketplace.licenseinformation.istrial
W8: http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.store.licenseinformation.istrial
If you are trying to implement a trial function within your phone application, why not latch onto the libraries that MS provides?
MSDN Creating a trial application
MSDN Sample code for integrating a trial applicaiton
This is only available for WP7.1, WP7.1+ and WP8 (when written for WP7.1)
Microsoft recommends using the WP8 LicenseInformation class, to do
MSDN LicenseInformation class, WP8
Hope this helps!
I know that my question is very general and I don't expect very detailed answer either, just a lead would be great.
Here is what I want to achieve.
I have build two desktop applications using Adobe Air from Flash AS3 files. Both applications are parts of the same project. They're displaying over two screens, each app on one screen, and whatever you do in one it reflects the other, because they are communication each other through local connection class (AS3).
In fact those two applications are One Multi-screen Application. However to install them on the desktop computer you have to first install one Air app and after that the second Air app. The procedure with launching the apps is the same. You have to click on one icon for the first app to open , and than you click on the other icon for the second app to open, and only then you have whole application up and working.
So I'm looking for some solution which would allowed me to "pack" two installation Air files into one package. The user would have to click only on one "instal.exe" icon to fire up installation of those two air apps.
Maybe it needs to be use some external small C++ scrip, or application launcher - I have no Idea
Pease help me with this case, as I couldn't find it anywhere. I would be very grateful even far the smallest lead.
Thanks in advance
Not real sure but could this help ?
http://www.adobe.com/devnet/air/articles/air3-install-and-deployment-options.html
Depending how large / complicated your applications are maybe you could redactor it into one application and use Native window to then launch two windows each one containing the separate app logic.
This may even offer advantages over using the local connection class, and of course help ease development and maintenance of two separate apps.
Can anyone tell me how to create a custom installer to 'install' games. I say custom meaning I don't want the user to have the option where the game is installed. I want it to be a straight forward process, maybe with just one loading bar.
The program I'm developing is a 'center' for game playing, which includes a community and other features, such as a timer that records how long a game is played for. I just thought that installing each game in one place, with a simple installer would make the program easier to use. It also will allow me to do other features as the games will all be installed in one place. No need for the user to specify where the game is installed.
Would this be possible?
I'm presuming your game is developed in C#, rather than requiring the installer be written in C#?
If that's the case, there are plenty of options available to you for installer packages. Probably the most customisable option, whilst still being free, is Nullsoft Install System. The installers are built around some basic scripting activities, and can be as simple or complex as you desire - the installation, and the wiki have plenty of example scripts that you can explore and experiment with.
OT: Install Location
Personally, I'd consider it bad practice to disallow the user from selecting their own install location and, in fact, it gets me pretty frustrated when anything but system-file installations (e.g. drivers) stop me from choosing a directory. Many users will choose to locate certain types of installation and data on a non-default device (e.g. virtually all of my games are housed on a separate drive to my main Windows installation). If you need to remember the installation location so badly, create a registry key for it.
Another system you can use is called Inno Setup - http://www.jrsoftware.org/isinfo.php
If the games already exist your best option would be to call the MSI installers in administrative mode (see documentation for MSIExec). Then you could actually
Set a predetermined location for the games
Remove any UI and replace that with your custom installer UI
Obviously that would only work if the installs are really MSI modules (with some more work also for installers that have MSIs packed into EXE setups). That is true for most, but likely not all games.
Please note that this would be a sizable task and to be honest I cannot see any value in doing what you are planning. But thats up to you.
As start you would have to read into the MSI documentation. I'd recommend WIX (Windows Installer XML) for the beginning.