I have created an application, where it watches a folder(directory) for any *.* files. The application works when I am debugging through the VS2010 with break points.
The same application doesn't work when I remove the break point.
anything I am missing . . .
This is a common issue with FSW. A debugger helps because it slows down time. When a process generates, say, a Change event, you typically cannot open the file right away. The process still has the file open and has it locked. The debugger helps because your breakpoint gives the process time to close the file.
You'll have to slow down time in your code. Avoid spinning in the event handler, that will make you lose change notifications. The best way to do it is by putting the path of the file in a thread-safe List<> that you try to empty with a timer. This also helps you deal with multiple change notifications. And UI threading problems, FSW generates its events on a threadpool thread from which you can't update a UI (but see SynchronizingObject).
Related
I'm new to c#. Antivirus deleted the mySolutionName.exe file out of the /debug directory and now I cannot execute my code. I'm concerned that anything I do may make the issue worse.
When I press F5 I get an error of:
CS2012 C# Cannot open for writing --> C:\Users\me\source\repos\MyApp\MyApp\obj\Debug\MyApp.exe''
Can someone please tell me how to rebuild the file so that I can continue developing?
after your edit:
Your program is probably still running outside of the debugger.
You need to use the task-manageer to kill all instances of MyApp.exe if this doesnt solve your issue a reboot should do the trick as well
So why is this happening?
Most liky your application is somewhere stuck on a blocking function or in a never ending loop. maybe there is even a seperate thread still operating that you forgot to close. We lack some information to tell yout that for sure. But to find out what is happening you can close your window while running in debugger mode and see if the application properly closes. if it doesnt you can hit pause and see where the program is stuck and resolve this issue by ending the task/loop/whatever in your OnClosing function of your window.
A good way to solve this issue is looking which process currently accesses the file.
A tool to do that is Microsoft SysInternals Process Explorer. It has a feature called "Find handle or DLL ..." which can be accessed by Ctrl+F.
The result will show the process which accesses the file. You can then judge whether it's Antivirus or something else that prevents you from writing to the file. If possible, you can then take an action in that program to release the file.
Example: a program is accessing my powerpoint presentation, which has the term "Schulungen" in its file name.
Process Explorer figures out: it's open in Powerpoint.exe, so I can simply close the file in Powerpoint - problem fixed.
I implemented FileSystemWatcher in a windows forms application. Changed event is working when I open a file (say pdf-1) for the first time. But when I open the same file for the second time within short span of time, changed event is not firing. But it is firing when I open another file (say pdf-2). Again the changed event is firing for the first file (pdf-1) only if I open it after some time (say 1 or 2 hours).
I set the InternalBufferSize to 16KB and the NotifyFilters used are LastAccess, LastWrite, FileName and DirectoryName.
I am unable to find out the issue. Can anyone help me out?
I have seen similar results with FileSystemWatcher for RAID controller disks, SCSI disks and regular IDE disks with write cache enabled.
I also experienced a lot of other errors that may have been caused by thread synchronization problems. Here is another description of this problem.
I am writing a small utility application to monitor my clipboard. This at current works quite well, but a friend has told me that it randomly will stop showing alerts upon clipboard change, and that restarting fixes it.
I couldn't reproduce, but eventually I ran into it myself - the application had stopped recieving WM_DRAWCLIPBOARD events.
How can I tell when my application has been removed from the listener chain?
This is one of the hazards of the clipboard listener chain: One bad application can damage the chain. Instead of using the SetClipboardViewer function, use AddClipboardFormatListener which does not have this problem.
If you are debugging an application that uses SetClipboardViewer and the application crashes or you stop the application in the debugger, or in some other way bypass the restoration of the clipboard chain, there is performance degradation in Windows, to the point that seemingly unrelated features of Windows, such as Alt-Tab, or restoring a minimized window, stop working. They come back if you restart Windows.
An application that inserts itself into the clipboard chain this way should be calling ChangeClipboardChain during Dispose of the main form, or at another appropriate time, to avoid this issue. Dispose isn't called if you stop the app in the debugger.
I have not tried AddClipboardFormatListener; first time I've heard of it; I'm going to try it to see if I can avoid the issue in my own app while I'm debugging.
Question:
I need a DragAndDrop solution to download a file on drop in a folder of Windows Explorer for C# & .NET 4.0. It should not be necessary to have the file on the computer. The file will be big enough that the drag-time won't be enough to get the download done. I have found various questions, even accepted answers, but nothing that works. The very closest thing to something working is this demo project:
http://blogs.msdn.com/b/delay/archive/2009/11/16/creating-something-from-nothing-and-knowing-it-developer-friendly-virtual-file-implementation-for-net-refined.aspx
How to implement this code to download a file as part of the action of putting it to the drop place in Windows Explorer?
Web browsers solve this problem every day. Simplifying their model a little, do this:
Make a little program that performs your download given appropriate command line parameters. This little program should pop up a window with a progress bar and a cancel button.
Spawn this second program whenever the user "drops" something. This program will create the target file immediately and start filling it with data. It will maintain appropriate locks on the file until it is done downloading, at which point the "downloader" will exit.
If you're going to keep the "downloader" threads in the originating program, you will need some kind of download manager so that the user can get appropriate feedback on their downloads.
Okay, as Yahia said in the comments it's not possible without a proper shell extension for the different versions of Windows and .NET. You might have luck with the link I posted, but for me it crashes the Explorer and the developer thinks it works fine.
My honest opinion is with only .NET you can only do it with a FileSystemWatcher via copying special .temp-files, watching where they land, doing your task and replacing the .temp files when your task is done. Sad Windows.
We are in the process of setting up surround scm as our source control program. We created a trigger which will run when changing the state of a file/repository. When we run it on many files the server gets several werfault.exe processes in the process list. I realize its windows error reporting, however, there is no popup. I'm trying to determine the cause of the error... is there a specific log I can check, or a debugging technique I can use? I don't believe it will be possible to debug directly on the server it runs on.
Thanks
WER faults end up in the Event Log, so that might give you a tiny clue, though it's usually not enough info to tell what went wrong. Maybe you want to add more logging to your trigger application, or have it run userdump.exe when it's about to crash (see AppDomain.UnhandledException event) to a specific folder - that way you can open up the crash dumps later to figure out what went pear-shaped.
What was happening was that we set a trigger on certain events and the trigger calls the handling exe simultaneously, which was swamping the server. We're now using an alternate solution with a windows service so we can control the max amount of simultaneous trigger executions.