I am having again (see old question) problems downloading files using the WebClient class. If I open the App and go directly to a page and start downloading, it works great. But if I first click around for a while and then try to download a file the WebClient downloads the first 1% and then stops, triggering a download complete event without errors. I tried only registering to the DownloadProgressChanged event but the WebClient still stops after 1%. And it is always 1%, not 2% or 3%... The current version of the App "FliteLevelTV" is already on the store and performs the downloads, with exactly the same code, without problem.
I am currently using Xamarin Studio 4.0.8(build2) with Xamarin.iOS Version: 6.2.7.1 (Business Edition).
I first thought that probably my WebClient is being garbage collected before it finishes, but if that was the case it would not trigger the download complete event. In any case, in my App, the whole download system is controlled through a Singleton that has a single instance of the file downloader as class property, which also has a single instance of the WebClient as property, and controls that only one file is downloaded at a time using a queue.So I am not sure how I could architect it differently to be more efficient.
Please help, I really need to push some updates and this issue is holding the whole thing.
Just in case anyone is tripped by this problem.
I implemented the process with the HttpWebRequest and found the problem. One of the events hooked to the WebClient was making a change to a value object that was triggering a change to the UI, which of course won't work, being the WebClient on a background thread. It looks like in this situation the WebClient simply swallows the exception, kills the download thread and triggers the completed event without errors.
Related
My goal is to make sure I have a stable process for handling extension updates. I'm about to release a new extension and have noticed that the background service worker goes stale. Here are the details:
My method of testing this lifecycle is by generating a new build artifact and drag-n-dropping it into the page chrome://extensions. I hope this is the way to test this lifecycle. But if not, I would be happy to hear the alternative.
Once I drag and drop, I open the background console to check for the correct version, but seems it lags behind. The only way to remedy this issue is by removing the extension completely and loading it back, this gives me the impression a regular user would experience the same issue.
The screenshot below describes the situation:
version 0.3.33 is currently installed
drag and drop new build version 0.3.34
after successful drag and drop, notice version is lagging with version 0.3.31
But the chrome.runtime.onInstall release accurately outputs the previous version
Furthermore, I took a look at the unpacked extension directory and the compiled code is accurate with the expected version
What I've done so far to troubleshoot, was to remove the extension completely. It does successfully update after a series of manifest.version updates, but then it goes stale. To be clear, all I do is update the version property of the manifest.json file and that seems to cause this issue
Any help would be greatly appreciated. In the meantime, I'll brush up on the architecture for service workers as it relates to chrome manifest v3. Thanks!
EDIT - Sunday, August 22 2021:
The latest development:
First of all, thanks woxxom for additional details to debug.
I've created an example project that demonstrates the problem with reproducible steps. Hopefully, this helps identify the problem but it does seem to point to a Chrome bug so I'll also report it on crbug.com
Github project: https://github.com/miguelespinoza/-v3-service-worker-update
Ultimately, what I've identified is that loading an iframe causes the service worker lifecycle to go "stale".
Looking at chrome://serviceworker-internals/?devtools, I've noticed that the extension includes two workers, that seems odd because I'd imagine only one should exist, the one in the background. This could mean nothing, but wanted to share that as well. one "Active worker" and one "Waiting worker"
Important Note: Service worker background events stop working. In my case, chrome.commands.onCommand or chrome.action.onClicked
I am trying find a problem with my program that is hooking into a game. This is
vc++. Basically I launch the program and then hook into it using SDL. When I run the code from VS2010, all works fine. But when I try to run from command prompt, my program can launch the game, but after that the game crashes immediately.
I was viewing windows event logs, and it appears that there is an access violation. 0xc000005
How can I log any further details about the program that crashes? I tried "procdump" but that is not useful as I cannot INDIRECTLY target the hooked game from console. Rather it can only target my application that hooks.
Anyway of getting detailed dumps is highly appreciated in this case.
Thanks!
You can perform postmortem debugging by using a combination of the WER registry keys/values to trap any dump that is produced. I’ve used this method to prevent the WER system from collecting the dump file (.dmp). I’ve also written about this in another similar post. To accomplish this, you will need to create a registry key under
Software\Microsoft\Windows\Windows Error Reporting
if one does not already exist. The key should be
LocalDumps\your application.exe
Once that’s done, modify these keys/values to meet your needs:
DumpCount, DumpFolder, DumpType
You’ll need Administrator rights to create and modify the keys, and, you should reset everything you’ve modified when you’re done debugging.
I've searched long and hard for an answer to my question and have found answers only to a class that does not exist in the 3.5 .NET frameworks version (and with CE Windows 5.0.) Also, it's Visual C# with Visual Studio 2008.
When I try the following (using System.Threading)
bool ok;
Mutex myMutex = new Mutex();
ok = Mutex(true,"scanner", out ok);
The compiler complains that the Mutex is a type, but used as a variable. If I use a [STAThread], it also complains that it can't find it and I"m forced to use [MTAThread].
Are the classes for the mobile device type of c# programs the same for console based ones? I'm somewhat new to this and the idea of how to declare, use, lock and everything you wanted to know about a mutex is making my head sore. O.o I suspect it's because the classes are different from the console verseions and the mobile versions.
It seems so simple, create a mutex, check for it's existance, if so then don't start a new exe instance. That is all I want...just run one instance of any exe. This is a mobile device thus it's a standalone and I never have to worry about anyone else using the .exe. Just need to stop the user from tapping the start button 15 times and having 15 instances of the application running (then complain about low memory usage!)
I've read that a good way is to create a thread, lock it then check if the lock was successful to test if an instance of an exe is already running, close it if so else run the exe. Is there an easier way to do this?
One way to approach this would be to open a file for writing. Only one instance of the application could obtain this lock at a time. On startup, try and obtain a file handle for writing, if it fails, there must be another instance already running: exit immediately.
I think you can forget mutexes since we are talking about separate proceses here.
I am attempting to write a simple function using VC++6 to write to the event log. It must be in this version of studio because it is being added to a legacy application. The problem that I am having is that it writes the message similar to below. The only thing that is valid here is the "This is a test" string. I don't need this to be very complicated. I just need to be able to write to the event log for a specific application. Any thoughts? I have seen a few articles but they appear to be a lot more than I need.
The description for Event ID 3 from source Application cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
This is a test
the message resource is present but the message is not found in the string/message table
It's been a very long time, but I seem to remember that you might need to create a *Message Resource Dll" to fix this. Or at least have some message resources somewhere.
This article seems like it might be able to help (and it support VC6): Using MC.exe, message resources and the NT event log in your own projects
Deploying to sharepoint using the object model or STSADM commands sometimes results in one or more packages being in the "error" state in the web control, a redeploy instantly fixes this, usually, even stranger, if i create two apps one which adds and one which deploys then i get no problems, but putting a delay between a single program does not have a similar effect.
If i run the deploy twice for programs which did not deploy successfully it works fine, as long as I do not try to do it programatically in which case it makes no difference.
It is different files and sometimes is none.
I do use stsadm -execadmsvcjobs between add and deploy and even between two of the deploy bunches.
(i'm deploying around 10 wsp files programatically)
Does anyone have any ideas on why this happens? or how to solve it, as when i get to implementations it causes problems.
The problem lies in the fact that sharepoint will perform app pool recycles and / or full iisresets, as well restarts of the SharePoint Timer Service (altough not completely sure about that though). When you try to actually deploy the just installed package sharepoint is still busy getting up and running again, the timer job created to install / deploy is basically waiting for the central admin app pool to be fully running again.
The same thing happens (somewhat reproducably) while retracting a solution. Hit F5 a lot of times on the solution management page while the retract process is underway and if you refreshed fast enough it will hang and display "error" in red.
My solution was to create a WebRequest to at least the central admin (or just do a SPSite = new SPSite("centraladminurl")) in your deployment app or in powershell. Do this after every deploy action as well.
This SHOULD fix the timing issue (basically a kind of "race condition").