I'm writing an MonoTouch app that downloads over 1000 individual PDF files and open them as one giant pdf file. I have no problem viewing the document but if I keep close/open the document few times it will throw
EXCEPTION: Too many open files
t System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00275] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.IO/FileStream.cs:310
at System.IO.FileStream..ctor (System.String path, FileMode mode) [0x00000] in :0
I've been using MonoTouch for a couple years now and have not had any issues like this. Could this be a new Xamarin.iOS issue?
I also saw in the forum they fixed this issue by using ulimit -a but how do I apply that to an iPad app?
Anyone?
There's no limit on open files inside Xamarin.iOS itself. However this exception will be thrown when the operating system (iOS in this case) reports too many files are open.
Check your device logs (e.g. Xcode organizer) and you should see iOS complains about the number of opened files.
When dealing with files, even more than other IDisposable, it's important to close them when you no longer require them. IOW do not wait for the GC to automagically do it.
Also you might want to try using Instruments or something like
this to see which files are open - that
should hint you about who opened them. E.g. they might not all be yours (e.g. if you embed many fonts inside your application).
Related
I have found an issue on our SharePoint 2013 farm where files >50MB in size cannot be uploaded to a document library using Chrome. The same files in IE10 upload without a problem.
When uploading, we receive the following error:
"Sorry, something went wrong
An unexpected error has occurred."
In ULS we can see the following:
Application error when access /xxx/xxxxxxx/_layouts/15/UploadEx.aspx,
Error=Maximum request length exceeded.
at System.Web.HttpRequest.GetEntireRawContent()
at System.Web.HttpRequest.GetMultipartContent()
at System.Web.HttpRequest.FillInFormCollection()
at System.Web.HttpRequest.EnsureForm()
at System.Web.HttpRequest.get_Form()
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.IsSignInResponse(HttpRequest request)
at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.IsSignInResponse(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.CanReadSignInResponse(HttpRequest request, Boolean onPage)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
We have checked the following and have been left scratching our heads:
The maximum upload size has been set in the Web Application to 2GB
The 2GB limit is reflected in the web.config file
It affects all document types we have tested
We have tested against multiple users, on multiple machines against multiple site collections
Files less than 50MB will upload through Chrome as expected
IE will upload the same file without error
Due to the number of users, at the moment it would require a pretty good business case to move everyone to a later version of Chrome. Due to this I was wondering if anyone might have any thoughts?
Many Thanks,
Adrian
OK, so finally found an answer to this, and it is a bug within Chrome v27.
On a test machine we upgraded to version 28 and the uploads proceeded as expected without any further amendments.
Unable to find anything online to document this however, it appears as though it is resolved by a Chrome update.
I have a google chrome extension that crashes after you install it from the webstore. When installed from a local copy the extension does not crash. The crash happens when you click the tool bar icon that is added once it has been installed. The icon is supposed to load a table with URLs. Once restarted all you get is the option to recover tabs. I was hoping someone could help identify the issue of the crash or tell me how to access a crash report to see what is causing the problem.
The extension is located here:
Chrome Store App
Any help or direction will be very appreciated. Thank you
I've looked into your issue, and there are two issues here:
Your extension gets disabled, "This extension may have been corrupted."
Chrome crashes.
The latter is caused by a bug that has been fixed in Chrome 40, so I'll only focus on the first issue.
The first issue is caused by Content Verification, an (experimental) security feature in Chrome that ensures the integrity of extensions from the Chrome web store, by disabling extensions that have become corrupted crbug.com/369895. Corruption is detected by verifying the checksum of a file whenever an extension file is accessed by Chrome (for files referenced in the manifest file: at install-time; for other (embedded) files: when the file is loaded).
Unfortunately, there are some bugs in the implementation that causes extensions to be disabled in the following circumstances as well:
crbug.com/439464 - The spelling of a filename in does not match the spelling of the path. On Windows and some Mac systems, the filesystem is case-sensitive, so during development, you may not notice that the spelling of the filename is incorrect. Content verification is case-sensitive, so it will treat "icon.png" different from (uppercase) "Icon.png".
(This discrepancy in checks is unfortunate, but a good thing: if you use an incorrect spelling in the icons field, then the extension would not load on case-sensitive filesystems such as those commonly used on Linux.)
crbug.com/444085 - The paths are not resolved into a canonical form. When you use two "//" instead of "/", then Chrome will find the file, but not its corresponding checksum and disable the extension. To fix this, change "path//to/file" to "path/to/file". Fixing static paths (e.g. in HTML and CSS files) is relatively easy, but if you construct the paths dynamically, then finding the culprit becomes much harder.
To find out why your extension gets disabled, follow the instructions at crbug.com/444085#c25.
The problem was related to a broken url in one of the css files. By disabling all scripts and css we were able to find the problem.
I have a 3rd party executable which I am trying to include in an InstallShield MSI package and I want it to have permissions set in all flavors of Windows, particularly 7 & Vista to be run as Administrator.
I'm not that clued up on the creation or the proper configuration syntax of Manifest files, but I have tried to make one manually as [appname].exe.manifest, and tried the <requestedExecutionLevel level=”asInvoker” uiAccess=”false” /> in the XML, and it didn't run as Administrator, and I want to confirm that is that because the program had not been compiled that way to see that the manifest file was in the same directory, or is it just going to be a case that the manifest file has not got the right syntax.
If there is any other simple ideas, I would love to hear it!
Cheers.
Manifests can either be embedded into an executable (this is preferred) or external, placed next to the file named as you describe. If there is an embedded manifest, an external one is ignored. For launching EXEs, this is all performed by Windows, and is not affected by code in the exe file. For loading DLLs, while this can be somewhat influenced by code you write, it does not change UAC behavior as it is not a process boundary.
As for whether a program not launching as administrator when you place a manifest requesting asInvoker next to it means you created a valid manifest, that depends on what happens when the manifest is not there. Since you mention InstallShield, you can copy a template manifest file such as its <InstallShield>\Support\setupexe.invoker.manifest to ensure your syntax is correct.
Upon re-reading your question, I realize you wanted it to launch as administrator. For that you need to request administrative rights, so you should have requireAdministrator instead of asInvoker, or base it off setupexe.admin.manifest instead.
I am working on many apps that uses RegFree COM Activation, everything works well except that one of the application is ran using an older technology that uses a JIT-type compiler.
To get RegFree COM working, i have to provide a manifest to the launching executable (correct me if i'm wrong) with my dependencies listed. All my other applications are built in-house and i have full control over my manifest (authoring and if i embed it, if i leave it Side-By-Side, etc). But this JIT-compiler (ala Java JRE) isn't mine and it already contains (embedded) a manifest.
I've extracted the manifest (using MT with -inputresource and -outfile), modified it and re-embedded it. It works like expected. However, having no ownership over this executable, i am worried about the legality of such a manipulation (modifying a third party's executable and redistributing it!) and would like to avoid having to do such a thing.
Also, i am worried that at some point this executable may be signed by the third-party and thus modifying the embedded manifest is going to break the signature.
Is there a way to have the sxs-loader look for another manifest first? It seems that if it finds one embedded, it takes it by default (which under most cases is fine).
Can i provide a configuration file or anything that would skip the embedded manifest and go for my side-by-side provided one (myExe.exe.manifest, instead of RT_MANIFEST resource inside myExe.exe) ?
You can only do that system wide as far as I know. Add that to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Make sure to trip activation context cache by updating last modified date on your executable, otherwise your manifest changes won't be picked up (renaming and renaming it back seems to work).
On Win XP external manifest is preferred over internal, but since Windows server 2003 Service Pack 1 they changed it to opposite.
We are trying to distribute a basic HTML file with some links to a PDF document in a USB drive for advertising purposes. The idea is that an autorun opens up this HTML in the default browser. However, this might not be a good idea since it would look very amateur-ish and we will have to rely on the default browser's technology (which unfortunately has a good chance on being IE6/7!)
We've explored a few alternatives, but we can't find one that really fits what we are trying to achieve:
Mozilla Prism
Altough it seems like it's designed with offline web apps in mind, the executable creates files in the user's AppData directory and it's hard to configure the default paths. Also, Firefox doesn't have a default PDF viewer, so we will have to depend on the user's default PDF viewer (which might be Adobe Reader)
Mozilla Chromeless
Since Prism is inactive, the idea is still developing with Chromeless, which allows the developer to create the browser interface with basic HTML/JS/CSS. The main issue here is that somehow the build isn't loading HTML, all that's showing is a gray iframe. I'm not sure if it's just me, because there's nothing on the issues page.
Portable App
We could throw in the portable version of Firefox or Chrome and customize the XUL for Firefox or open Chrome in app mode.
Firefox's advantage is that it kind of supports relative paths (resource://), but it doesn't have a built-in PDF viewer. Chrome has a very good and lightweight PDF viewer and the built-in app mode is a very useful feature for us, but I can't find how to open a local path without the usual absolute path (file:///C:/) since we don't know what's the drive's letter.
Has anyone figure out how to handle this kind of issues? Thanks.
This has been asked three years ago, but it's unanswered, listed high in Google, and I stumbled over the exact same problem and can imagine that many others that seek to ship portable web apps that can be run locally and with a minimum of dependencies will encounter this issue, too.
The solution I am now going with is the node-webkit.
You can treat it like a portable version of chrome, however it excepts a relative path to your app's entry point, is about 40 MB smaller, and much more customizable than the --app mode of chrome (which isn't customizable at all if I remember correctly).
Github & Download:
https://github.com/rogerwang/node-webkit#downloads
An extensive guide:
http://thejackalofjavascript.com/getting-started-with-node-webkit-apps/
My usage suggestion for Windows:
First create an app package as explained in the guide linked above
For the node-wekit to load with your app, you need to start it like this:
nw.exe app.package
Where nw.exe is in the root of the zipped folder you downloaded and app.package is a zip file (can have any name) that contains your app data and package.json.
To do this silently, you can use a BAT file containing the (amended) call above and a VBS file containing something like this:
CreateObject("Wscript.Shell").Run "cmd /c launchNW.bat", 0, true
launchNW.bat being the name of your BAT file. Now run the VBS file; a window containing your web app should pop up without the command window appearing with it.
Finish reading the linked guide to learn more about customization options to do things like hiding the browser UI etc.