Is there a way to force install4j auto updater to update the current version? - auto-update

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.

Related

REQUEST_INSTALL_PACKAGES issue detected by google even though we don't have one

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.

"One or more projects are incompatible with UAP,Version=v10.0" Issue [UWP]

I've been developing UWP app until I got this error (picture below). I've searched for solution but I couldn't find anything. It doesn't even say which package is the incompatible. How can I find the incompatible package in my solution? Also is there any way to re-create project.json by automatically? I ask it because I changed something on project.json and broke it more.
Also I'm using VS2017 and I'm able to run project without issue. I just can't update package.
Thanks.
(github link for project if you want to look at it.)
I used your GitHub https://github.com/almorax/dota2-handbook-uwp project to troubleshoot the problem and looks like the problem is with the way the nuget package is referred in "Dota2Handbook" project. In other projects, you have used "PackageReference" way to refer the nuget package however in "Dota2Handbook" project you are using project.json to refer nuget package. When I changed "Dota2Handbook" project to use the "PackageReference" way then I was able to get the latest package.
Note: You will notice that "Dota2Handbook.Infrastructure" project already use the new way to refer Nuget packages
More details on PackageReference : https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
What happened to me is that I have UWP projects that were made in VS 2015 and initially targeting Windows 10 RTM. These projects where updated to VS 2017 and to target Creator's Update. All worked fine, and all projects still used the original project.json style.
Then I tried to create a new Windows Runtime Component project and target Creator's Update initially. Targeting Creator's Update in VS 2017 causes the project to use the new PackageReferences project style. This produced the errors shown in the above question when I referenced the WinRT component from the UWP app.
Rather than converting the all of my legacy UWP project files to use the new format, I target the new UWP or WinRT Component library to Anniversary Edition (which uses the older project.json project style), then retarget to Creator's Update.
Of course, at some point updating the project file may be appropriate, just know that it will no longer be supported by VS 2015. Conversion steps are illustrated here.

IE BHO - Auto update management

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.

How targeting .NET 4.0 with Mvvmcross?

I want to use Mvvmcross to make application for several platforms.
I use Profile 104 for PCL library like Mvvmcross, but this profile target .NET 4.5.
I want to target .NET 4.0 to use my application on Windows XP.
To do that, I add the xml files
MonoAndroid, Version = v1.6 +. Xml
and
VSMonoTouch, Version = v1.0 +. Xml
in the profile 143 which allows me to target. NET framework 4.0.3.
However, I have a compilation error because it can not find the ICommand interface.
This interface is not in the same library between version 4.0 and 4.5, is it why it doesn't work ?
Or should I recompile all Mvvmcross libraries with profile 143?
thanks,
This is a Portable Class Library limitation.
See the table on: http://msdn.microsoft.com/en-us/library/gg597391.aspx
Model-View-View Model (MVVM)
Only 4.5
This means that if anyone wants to use MvvmCross on earlier .Net platforms then someone has to build and maintain a non-PCL version.
Since the maintainer of Mvx (me!) has decided to only maintain PCL versions of MvvmCross, then any non-PCL support will have to be created by the community.
For WPF this shouldn't be too large or difficult a job - but it might be...
Alternatively, somebody might be able to do something funky to get the ICommand working... I've retagged this question with portable-class-library to try to lure in some of the MS experts.

Adobe AIR Update Framework: How to check for updates upon AIR application install?

-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.