I am trying to publish an appx on the Windows Store built with electron-builder.
In the repport, I get this error: Failed to extract imported API information for this application
I have no idea about what this is supposed to mean and I found no documentation about it. I contacted Microsoft Developer Support that just sent me here.
I found this link that mention the issue.
After two days of trail and error we nailed it. It looks like it has
something to do with the lenght of filepaths to contents inside the
app package.
Notice the difference between the cause and the error message. This probably means that this error is just a random generic error that is raised when something happens, and doesn't provide any meaningful information about what exactly went wrong...
The issue is that now, I have absolutely no idea about how to move forward. Any help is greatly appreciated.
The issue is that the WACK tool developed by Microsoft to test the packages sent to the store is crashing if any file complete path is longer than 255 characters, and it returns that random error giving you the impression that you did something wrong on the manifest.
The best you can do for now is to measure the full path of all the files that are going to be packaged into your app and try to rename the longest ones, or try to reach the Microsoft support. It's 300$ / request, but you can get it refunded as it's clearly their own responsibility.
Related
I am using a SAME70 Xplained microcontroller for a project I am working on. I program it using an editor made by Microchip called MPLAB X. About a week ago, suddenly I could no longer upload any code to the board as I keep receiving the error
java.lang.RuntimeException: java.lang.RuntimeException: TransferFault
Resetting the board, uploading different code or using other features in the program to interact with it do nothing. An important note is that when I got ahold of a brand new board of the same type and tried to upload to the board, it actually succeeded the first time. But then for some reason later the same error pops up again. It seems the issue is a bit more than downloading code as the function in the program which allow for uploading code or pausing the controller throw the same error. I have been struggling with this issue for over a week now and cannot use the board because of it. I cannot find any mention of this issue on the internet. Has anyone ever encountered this? Does anyone know the specifics of what a transfer fault is and can point me in the right direction?
I have setup a local GraphHopper service on a local server and it works as advertised. I can pass it a set of points via rest, and get back a happy little JSON file of directions and an encoded route. Of course, "out of the box" the routing API is missing a toggle available in the paid Routing API service via graphhopper.com, and that is the optimize=true/false flag. This little addition will not only route between your passed points, but when set to true will also re-order them into the most optimal route.
Now I imagine to get this additional functionality one needs to somehow "bake in" some level of jsprit code. My level of understanding of Java and compiling code however is woefully inadequate here. Looking over numerous jsprit sites the best help I can find is "look at the source code for examples". Is there any sort of guide for building jsprit into the standard graphhopper JAR file, or does anyone know of any pre-built JARs out there with this functionality already built in? it's probably a long shot, but any help would be appreciated.
I've been working with Appcache for quite some time, but I recently took a couple of weeks to develop a different project. When I returned to my offline project, I started getting this error every time I try to download the contents of my manifest:
Application Cache Error event: Manifest fetch failed (9)
This is followed by 2 addresses; the file and line number of the page that calls the manifest (on right of same line), and the relative url of the manifest itself (on a second line). The download of the individual resources does not begin.
Now, other folks work on this project, but I'm the only guy who touches anything that as much as smells of offline. The issue doesn't appear to be related to any of my usual suspects, like a syntax error in the manifest (tried clearing all the files, just to be sure), the manifest being served incorrectly, or something wrong with one of the files being cached. I don't think it's a memory problem, as I have over 30 gigs of space outside of the size of the files I'm caching. Furthermore, this worked 2 weeks ago, so I'm assuming that there isn't something wrong with my setup. However, nobody seems to know what the hell this error is; nobody even seems to be getting this error. I can't find anything online to describe what this issue is. Hence, my question is:
What does Manifest fetch Failed (9) mean?
My browser is Chrome on Windows 7, and is up to date.
GAH. Ok so I figured out the problem, or at least I figured out a solution. 9 might indicate a certificate error, which is what I was experiencing. Lovely, just... lovely.
(9) means that there is a security error. Since cache manifests with invalid certificates allow a man-in-the-middle attack, as explained in the Chromium issue that disallowed this. If you still want to use a cache manifest with an invalid certificate for testing purposes, you can pass --ignore-certicate-errors to Chrome on launch.
I hope you can help me.
I am writing a desktop program that will run in a web browser (in HTML/CSS/javascript in case that wasn't clear). It will be entirely disconnected from the internet and obtain files and data using only FILE protocol. My question is: how can you obtain a listing of the contents of a directory referenced this way?
I've been searching for months and really turned up almost nothing! Maybe I just don't know how to search but there doesn't seem to be much information about how browsers actually deal with File protocol.
For example, when you open a directory in Chrome, it gives you a nice table with hyperlinks of all the parent directory's children. However, when you look at the source code, it's as if Chrome just magically knew exactly what files were in the directory. I feel that if I could understand how it knew that, maybe I'd be able to get somewhere...
Also, I am open to other ideas about how to get a directory listing. I've read about being able to do it with php but it requires running a server. Does anyone know if it is possible to run php code with File protocol rather than HTTP?
Thanks for reading this far and truely any information that could remove me from this standstill is appreciated!
Web Apps do not have access to the user's file system so you will not be able to do what the chrome file browser does with a web app. I believe chrome is using some sort of native code to do this.
I would recommend trying something a little more on the native-side. A chrome app will let you use html, css, javascript while also allowing you access to the file system. https://developer.chrome.com/apps/app_storage#filesystem
Another alternative is you could write some sort of native java application. That would allow you to read/write all the files you want.
We are using the google-api-client gem in our Ruby on Rails project to access the Google Drive API methods and everything has been working great. However, we are sometimes receiving the following error response from the API when calling the drive.files.update or drive.files.insert methods:
{"code"=>500, "message"=>"Unable to read application configuration information"}
This error is not documented in the list of possible errors from the SDK, so I am not sure how I should go about it. Could you please help?
Thank you!
If this error is transient, the best way is to have a retry strategy when that happens (simply retry the request 2 or 3 times before giving up).
It seems like some concurrency issue on the Drive side where a request to read your application's configuration times out. By experience with Google APIs - and web APIs in general - I can tell you that, even though the team will try to fix/improve these (btw I will repport the bug so they can investigate) errors like that will always happen once in a while even with a very low occurrence as concurrency, timeout and reliability issues on distributed, web-scale systems are extremely hard to resolve. The best to have fail-proof code on your side is to retry a few times on every single 500 and 503 errors from external web APIs.
If you really have time on your hands you could even implement an exponential backoff strategy where the time between each of your retries increases each time as described in our documentation.