In an IE BHO written in C#, how can I add auto update functionality? If we release a new version of the same BHO, how can the client update the BHO? In FF/Chrome/Safari I found the way. Is there any solution available for MSIE BHOs?
I don't think there is a standard way of doing this in IE that is analogous to FF RDF's
<em:updatelink>
or Chrome manifest's
"update_url":
I would suggest that you poll your web server from the BHO periodically (monthly?). If you find a new version of your BHO, download it and ask the user to install it. Bear in mind that an updated BHO is a different program and should have a different GUID, meaning that your registration of the new BHO needs to remove the previous, and now useless, BHO.
Related
App build with ActionScript3/Harman SDK but we don't even have REQUEST_INSTALL_PACKAGES declared in our xml.
Also, I already checked the APK via Android Studio, the AndroidManifest doesn't contain also REQUEST_INSTALL_PACKAGES.
Any fix or advice for this? Thank you.
We checked our SDKs/ANE DISTRIQT and none of them that we are using is using the REQUEST_INSTALL_PACKAGES.
Check all of the available APKs for your application.
Google will check all available versions of your application so even if your update doesn't have the permission an older build may have. When updating you may have an older version available for different users.
Go through and disable or remove all older versions as part of the update have this permission before releasing.
I've been iterating versions of my application trough beta and install4j auto-updater was updating successfully trough versions (2.1 -> 3.0b0 -> 3.0b1 -> 3.0b2). Now I've published version 3.0 and auto-updater is refusing to recognize the new version.
Now, I know that there is an option that allows you to customize update scheme but it's too late now since I didn't know that when I was publishing older versions.
I've played around with it and it updates to 4.0 and 3.0b3 but fails to recognize 3.0, 3.1.
So, is there a way to force auto updater to update by manipulating the new update.xml file?
EDIT: I have version 4.2.8 of install4j installed.
Unfortunately not. install4j 5 will correctly update from 3.0b2 to 3.0, but in install4j 4 you would have to modify the updater logic, so you would first have to release a 3.0b4 to do that.
I have a web server running Windows Server R2 Standard, and am experiencing the issue described in this blog post: http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx
In short, .Net is failing to recognise IE10 and is treating it as a downlevel browser without javascript support - if I understand the issue correctly.
I tried the following popular solutions:
Installed both hotfixes for .Net 2 and 4.
Manually updated the browser definition files in the .Net framework config folder and ran aspnet_regbrowsers.exe.
Put the new browser definition files in the App_Browsers directory.
Finally I upgraded to .Net 4.5 which solved the issue for .Net 4 sites running on the server, however .Net 2 sites are still experiencing the issue.
Because this is a live web server it has a lot of windows updates that have not been installed. I thought maybe there was an update that would address the issue. So I've taken a look at the updates but none of the descriptions seem to address the issue, so I cannot justify installing them and potentially causing more problems.
Does anyone have any other solutions or possible reasons why this issue just won't go away?
I have the same problem, and I haven't been able to figure out why none of the fixes work. However, I did find a workaround that might work for you: Setting the Page.ClientTarget attribute to "uplevel" overrides .NET's browser capability detection. Have a look at http://msdn.microsoft.com/en-us/library/system.web.ui.page.clienttarget.aspx for more information.
Have come through many microsoft hot fixes, they were working in local environment, but in the live server there was no result.
Setting up Page.ClientTarget = "uplevel" (preferably in a header or footer page) has really solved the issue. I think this the best solution, as your .net application may not detect any other browser in future. But then we may have to wait and see, if this fix has any side effects.
So i am working in a chrome extension which won't be hosted on the google webstore, thus i will need to add the auto-update functionality to it, however i need it to be a little more dynamic, i will try to illustrate what i am trying to accomplish by a little scenario so it won't seem pointless.
Scenario
I need to have an extension that's kinda have different editions for each version, i.e. each version have a free edition and a paid (feature rich) edition, and whenever a new version is released the extension will be updated according to it's edition.
In other words, the server should be able detect the user's edition and provide the crx file according to it "i.e. dynamic".
What i tried / think of
1.I tried to set a cookie with the extension edition, so when the auto-update occurs the server can check it and generate the xml file, unfortunately i found that cookies don't get sent in the auto-update headers sent by chrome.
2.I can make the extension talk to the serve when chrome start-up, so it will send it's edition, so the server will store it along with the ip and when the auto-update occurs the server will check the request ip and match it with the edition to provide the xml, i think this could work but it's kinda lame method.
3.I can use native apps to modify the manifest file to point to a different xml file according to the edition, i guess this will work too but i am not in favor of using native apps.
4.I tried to find a way to modify the get-request parameters (i.e. to add custom parameters like the edition), but it seems that there is no way to do so.
5.I can separate different editions to be different extensions (i.e. free edition will be a in different package than the paid one), however i am interested to make it all in one, so the user can upgrade/downgrade their subscription without installing/removing the extension they already have.
I guess that's it and i hope some one would have a better idea on how i can accomplish what i am trying to do.
P.S. I know the title is kinda vague but i couldn't find a better one, so if you came up with better title please let me know.
Why not make the free edition version 1.* and the paid edition version 2.*? Then make your update page generated dynamically by a simple PHP page, that gets the app id and version (see the autoupdate docs).
Put "update":"http://www.mysite.com/update_app.php in your manifest. In your PHP script, read $_GET['version'], and serve an XML update document to match the major version number (1.* free version, 2.* paid version). Basically, keep two XML update files on your server (and two CRX files) and have the script decide which one to serve.
It doesn't have to be PHP, of course; any server-side language will do.
-How can I check for a new version of my application upon installation?
I feel like I remember installing an AIR application and during the install being alerted that there is a new version, and a prompt as to whether or not I wish to update.
-How do I alert the user, via textfield, that there is an update for the application and to run the "Check for updates" option?
I do not want to force the check for updates, ApplicationUpdaterUI, I want to notify users that there is a new version, and then allow then to bring up the ApplicationUpdaterUI.
Currently, upon initialization the application is popping the "Check for updates" dialog box. I would greatly appreciate some insight on either of these two questions.
I would like to note that I am developing using FlashDevelop3 RC2 and Flex 3 SDK which contains the AIR SDK and the AIR Update Framework.
Brian Hodgeblog.hodgedev.com
I don't think you can check for updates during installation. What you could do is install a basic shell app that always loads in the actual application as a swf file. You could even download this swf file the first time the app is run. After that you can always check for a new version of the app (swf) and download/update accordingly.
Hope this helps... During install - NO - you really can't run anything if you're using the standard AIR installer. You can move to a custom installer - but that's a much more work.
However, when you're first invoked - when your application starts - you can check then (and you can check as often as you want thereafter ).
The guy you want to see is ApplicationUpdater instead of ApplicationUpdaterUI. Using ApplicationUpdater you can get all of the checking / downloading / etc... But then display ANY or NO UI - of your own.
For example - you can check for updates, download them of you determine they are needed and on next 'start' of your application - you can literally 'install' all without asking the user.
I don't recommend this... But it's possible.
Fitting the scenario you asked above - you can check for updates, determine if the update is needed (comparing version or whatever) and then notify the user any way you want - as subtle as you want - to ask the user to update.
You can also do this with ApplicationUpdaterUI - you just need to turn all of the UI stuff OFF (which sort of defeats the purpose of using the UI guy) and just catch the events and display your own UI --- like:
_applicationUpdater.isCheckForUpdateVisible = false;
_applicationUpdater.isDownloadUpdateVisible = false;
_applicationUpdater.isDownloadProgressVisible = false;
Hope that helps.
I think your best bet here is to either:
a) Make sure the .air package that people are installing is always the latest version (this may not be possible if you're distributing an app on solid media, like CDs)
b) Make the update process the first thing that happens in the application (i.e. don't show your primary UI until you've checked for an updated version / shown them the update UI)
However, if you contact Adobe, you can get permission to use a bundled installer which can install both AIR and your application in a non-standard way (e.g. through InstallShield). With this method, you could do pretty much anything you wanted when the app installed, including running a simple script which would check whether they have the latest version.
You can check out http://www.adobe.com/devnet/air/articles/distributing_air_in_enterprise_02.html for a bit more info about bundled installation.