I have been using autoupdate ( http://developer.chrome.com/extensions/autoupdate ) with Chromium application and it seems to work great. However,I haven't been able to figure out how to automatically restart application after the update. The application is designed to run 24/7.
I think this should do it:
chrome.runtime.onUpdateAvailable.addListener(function () {
chrome.runtime.reload();
});
Add that to your background page, as described here.
Related
I'm looking to automate how my bots are updated. They're hosted on a VPS from GalaxyGate and kept alive using PM2. I use VSCode to develop them, then I push to GitHub and pull the code from there to the VPS to update them directly in production. However, this currently has to be done manually and I always forget the git commands that I'm supposed to run.
I'm looking to have this process automated; ideally the server would periodically run some sort of script to update all bots that are hosted on it. It would fetch GitHub and apply the new changes (if any) and properly restart the bots, so I have a few questions:
Is this possible, and if so, how would I go about doing that?
Are there any risks/downsides with such a system?
Any help would be appreciated
I have a Run configuration which builds an exploded web app, deploys it to tomcat, and opens the home page after that. However, I want to hit a few URLs to set some state in the app before opening the home page (Or after opening the homepage; it does not matter). Is there a way to trigger a few URL hits after the run configuration? This feature would be similar to "before launch." Instead, it would be "after launch".
There is no such feature at the moment, you can vote for the related feature request.
It's not as simple as it looks since it's not clear what would trigger the after event. The app server doesn't exit/terminate, but is still running, therefore it's not possible to use another run configuration with your app server added in its Before launch steps, otherwise you could create a Shell script configuration that would call curl/wget.
For the app server the proper after event would be the moment when the artifact deployment is complete which requires the tight integration with this specific app server so that IDE knows the exact moment when it happens and allows to call some custom action.
This might be possible with the custom plug-in as IDE already knows when the artifact deployment is complete.
A really hacky workaround would be to run some tiny HTTP server and open its URL from the IDE instead of your real app server. This custom server would call the URLs/APIs you need and then open a browser for your real app URL.
Is it possible to trigger the share action from within a metro style app without using the charm bar?
It's not really recommended, but there is an API available.
// javascript
Windows.ApplicationModel.DataTransfer.DataTransferManager.showShareUI();
// or C#
Windows.ApplicationModel.DataTransfer.DataTransferManager.ShowShareUI();
More info located # http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.datatransfer.datatransfermanager.showshareui.aspx
the recommended way is to open a share contract and do it via charm.
one reason to doing so is that if all developers do it via charm. user will know exactly where to find the share feature across all app and it helps to keep the whole windows 8 ecosystem clean
I've deployed an application inside a corporate network and I want the update process to require less attention from users, similar to how Google Chrome install updates - in the background. I don't need to give the user a choice to update.
I've used the System.Deployment library to detect when new ClickOnce updates are available and install them automatically. I'm wondering if its necessary to restart the app after the update is complete. Currently I invoke Application.Restart() at the end of my update script.
But what if (to make the update process more transparent for the user) I performed a 'silent' async update and then displayed an icon prompting the user to restart the app to apply the changes? Would this make the app unstable in any way?
Furthermore, if I ran my custom InstallUpdate() process on a timer, say every 30 minutes, would ClickOnce be stable to continue to update for every new version that was released even thought the user has not restarted (nb: I'm expecting the updates to only apply once the user restarts the app)?
I would think it depends on what your application does at startup, and what it's doing when the update is installed and the application is restarted, and what the update contains. You could try running it and then attaching a debugger to it and see what it's doing and what impact it has.
For example, our application loads a lot of information into memory when it starts up. If the update included a change to one of the data structures, and the app didn't reload the data for some reason, it would cause a problem.
After a few years of doing it like this, we have found that it is possible to silently install updates this way. However there are a few issues to be aware of:
If the thread terminates prematurely during the Update() (eg: the user exits out of the app while the updating is in progress), the install will become corrupt and the next time the user loads the app, the ClickOnce normal deployment will fire off and re-install the app.
The user's desktop icons always redraw (flicker) after an update is installed.
Calling ApplicationDeployment.CurrentDeployment.CheckForUpdate() more than 65536 times causes a System.NullReferenceException Source.
An alternative is not to actually check for an update, I have found that this locks one of my dlls and prevented a form from loading, so use with care:
If ApplicationDeployment.CurrentDeployment.Update Then ' update app
console.writeline("update installed")
' code to inform user update was sucessfull and they need to restart
End If
If your ClickOnce project is 32bit, and you run it on an x64 platform, any file associations your app has will break after performing a manual ClickOnce update. See this MS support case for more details.
I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.
This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.
I get a quick flash of command prompt (the batch file) on the client system and then... nothing...
Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.
I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.
For anyone who has run into this before and got it working, what did you have to do?
We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.
The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.
Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.
The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.
If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.
Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.
I know it only half a solution, but if the application does not change much, it might be a good solution.
I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.
See this link for more information.
http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx
There may not be a way to do it :(
Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.
That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.
Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!
We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.
https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2
We also have a discussion on the MSDN forums covering this issue:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc
Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.
Also maybe check the event logs to see if anything's getting logged when the process fails.