I updated some code in an unlisted extension I am managing, published it to the store as usual, and it has successfully updated the version number.
When I attempt to install it, I get:
Package is invalid: 'CRX_HEADER_INVALID'.
The crx file is created for me, as per the docs here: https://developer.chrome.com/docs/webstore/faq/#creating-a-listing
... I just upload the zip file containing my extension's code, as such I don't know what to do. I checked it is crx3 and it is. I am running Chrome Version 88.0.4324.96. I tried to install the previous version that was on the store, and the same package is invalid pop up appears, so the only thing I can think is that the issue could be down to how this crx file is created from my zip. Not sure how I would go about dealing with this, or if someone else had had this issue maybe they know whats going on?
EDIT: Have tried it on multiple versions of Chrome, same outcome on all. Believe the issue is with the conversion to crx file, but am yet to identify what the issue is.
I had to migrate to Manifest V3 in order to fix this.
The Google documentation "Introducing Manifest V3" did not state anywhere that migration was a required step in order to update an extension that was already on the store.
Related
I may not have the option to simply update to a more recent VC++ version as would be ideal - the project is big and the update could break a lot of things, plus my lead may tell me not to pursue this. I'm wondering if anybody knows of a means by which an MFC app written using VC++08 can check resolution during runtime?
Thank you, #IInspectable for providing the answer I needed. A full update is not needed. DPI awareness can be activated via the app's manifest file. The link they provided was invaluable. Should anybody else have this issue and is using vs2008, if you cannot find the manifest file in the same dir as your exe after building, chances are, vs2008 has embedded the manifest in the exe. You can change this by opening the project's properties, going to manifest tool->IO. If you want to keep the manifest embedded, you can put your additional manifest info in a separate manifest file and provide the tool with the path of this file. The manifest tool will merge your manifest files.
I meet some problems about newly published extensions in this month.
When I download my extensions from Developer Dashboard by this type
I can install extension normally by pushing it into chrome, but now newly published extension cannot install it before version 60 and publish an error:
I don't know how to figure it or if web store did some crx package change?
Can anyone meet this problem?And help me.Tks.
PS: I download crx by other types from Google, this crx file can install normally and MD5 is different from crx file from Developer Dashboard.
Try 1:- change Change ext version in manifist.Json
Try 2:- remove really unwanted config from manifist.Json
Try 3:- remove unwanted
file from directory.
We hold our landing page on Azure and it is for users to download an Android apk file. This landing page is a html file. Here is the markup for users to download:
download here
It all works fine until now. Users start to complain that the app they downloaded cannot work properly. But when we tested, it works fine.
Finally we find out that, although the link is
http://www.[mysite].com/android/[MyAndroidApp].apk
but sometimes when user click it, it goes to
http://101.44.1.131/cloud/223.210.55.28/files/9216...636//www.[mysite].com/android/[MyAndroidApp].apk
This is a buffer and holds an old version of our app!
Can anyone tell me why this happen and how can I prevent it buffer our old version?
How often do you update this apk file?
May be a caching issue, but not sure exactly.
Have you tried using Azure storage? Upload the file on there, and then link directly to it.
Should cost you less in the long run and not cause any buffering/cache issues
I would suggest you try to put version numbers after your filename. This is also a good practice for .js files. A problem is very often that it's cached and the cache not updated correctly. It's a general problem in the web.
So. Try to put version numbers after the file name, and let us know if this works.
Thank you all for your suggestions.
We have found the reason. Looking at the redirect url, it is actually some ISPs cached our apk files. They are doing this so that they can save themselves money and bandwidth. This is a common practice in some countries and is well documented.
How evil it is.
Our solution is thus change the file name very time we deploy a new version.
I am trying to install a package (oForms) with a new Orchard 1.8 installation, but receiving the following error:
"Package installation failed: There was an error installing the requested package. This can happen if the server does not have write access to the '~/Modules' or '~/Themes' folder of the web site. If the site is running in shared hosted environement, adding write access to these folders sometimes needs to be done manually through the Hoster control panel. Once Themes and Modules have been installed, it is recommended to remove write access to these folders."
This seemed rather straightforward, however my host has confirmed permissions are fine (and even added Everyone/Full Control to the folder), so I'm lost and appears to be happening with all modules from the Gallery, not just oForms. I changed the Config/log4net.config file to log everything, and I don't see anything specific in there except where it logs the same message above. Nothing outside of that stands out at all.
Is there a way to see why this is failing? Or, if not, is there a way to get the module and install it manually? I tried to download from the gallery, but it's just a NuGet package so I'm not sure how to take that and grab the raw module files.
You can use a program like 7zip to unzip the nuget package, then copy in the module manually yourself.
As for the permissions, when adding a new permission to the folder use:
IIS AppPool\name of your application pool
I also had this exact error message when installing modules from the gallery, and it took me a while to figure out what was happening. I made new installations, copying over files one-by-one, and eventually found the culprit. For my case anyways...
For me, it was all due to a bad formatting in my custom Theme. Specifically the Theme.txt file. The line where is says Version:, I had it formatted without any "."
Good:
Version: 1.0
BAD:
Version: 1
Yes, doing this simple mistake prevented me from installing Modules.
I want to set auto-updates up for my apps before I release. I'm a budding programmer, so when I looked into node-webkit-updater I was pretty confused. It seems under-documented to me. Can someone explain the overall update mechanism that it helps implement?
As an alternative to node-webkit-updater, I was thinking of creating my own update system. I kinda like how Apple handles extension updates and I was thinking about replicating it. This would involve putting a JSON/XML manifest file on Amazon S3 along with the latest versions of the app for all platforms. The app checks the file at startup and replaces itself with the new version.
Is the latter sound plausible? Am I better off going with node-webkit-updater? If so, can someone explain it to me please? My app is a Mac + Windows project.
This is what we did:
The first script of the page checks a custom "manifest" (.txt file) on the server, which contains some arbitrary text, e.g. version number.
If this value differs from a local version of the manifest, then download a .zip file from server. (The zip contains the latest nwjs website. You could have a separate one for each platform).
Unzip into a local directory (we use 7za command line util).
Set window.location.href to above local directory (index.html).
I know this is a old question, but here is the answer :)
https://www.npmjs.org/package/node-webkit-updater