When I do throw exception I have added the exit, but after that the exe file is removed. is it a known problem? (in VS2010)
Neither Application.Exit nor Environment.Exit will remove the executable from disk.
It sounds like some other process is trying to delete the executable. As soon as the application exits, the file will no longer be in use, and the .exe could be removed.
Depending on what you're doing, this could, potentially, be from a virus scanner. I would check your Virus Scanner logs to see if there is an issue there. This should be very unlikely if this is a completely managed (C# only) application - but if you're using native code that is "questionable" according to the scanner, it may be removing the executable.
Otherwise, I would check for other processes that may be trying to remove the executable.
No this doesnt sound right. Do you mean the .Exe Application file is been removed from Disk? That cannot/Should not happen on Exiting. Can you send mroe details on what you are trying to do, What kind of application, etc. I tried with a simple C# Console application and it wouldnt seem to happen in VS 2010.
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.
Let me layout the scenario.
We have a 3rd party application (say, app.exe installed to C:\App). It actually cannot run directly, it needs a configuration file passed to it as an argument: "C:\App\app.exe config.ini". Everyone already has shortcuts that contain the necessary arguments.
This application supports plugins, of which we have developed a few. In order to distribute said plugins, they need to be copied to each users C:\App\Plugin\ folder, so when a change is made I have to travel around to everyone's desk and make sure the update gets applied.
This was cumbersome, so I developed an application that will scan a network folder and compare it to it's internal db of files. If there are any changes, it copies the files over to the proper destination folder.
This wasn't seamless though, as the user would have to make sure app.exe was closed - run my updater, and then rerun app.exe. So I renamed the original app.exe to app_launcher.exe, and my updater to app.exe. I modified my updater application to support arguments and pass them through to app_launcher.exe when the update was done. Once app_launcher.exe has started the updater program closes.
I should note - the above actually works.
The problem comes from users who have the app shortcut pinned to the taskbar. Once the real app finally starts it gets it's own new icon on the taskbar instead of being grouped with the original shortcut. This actually makes sense as they are technically two different applications. The users however, don't like this.
I have done some research on this, and found some 3rd party programs that can allow you to group multiple programs (Bins/Fences). I DO NOT WANT THIS.
More research revealed something called the AppUserModelID, which intrigued me. After some playing around, I got my updater to set it's own AppUserModelID. The original app.exe didn't set it's AppUserModelID (found that out via ProcessHacker), but I was able to get the updater to start it with the same ID it was using via the CreateProcess method found in kernel32.dll.
This did NOT work. The updater started under it's own pinned icon, and the original app started a new icon. I tweaked the updater to stay open until the original app was closed to see if that made a difference. This time it started under it's own pinned icon, the original app started it's own, and then the updater window switched to be grouped with the original app under the new icon. So AppUserModelID did group them together, but not how I wanted.
I am using C# for the updater application, and cannot make changes to (or have changes made to) the original app.
How can I get these applications to group under the pinned shortcut? Is it even possible?
I think I may have found a solution, though it's a bit of a hack.
The problem comes from having the final application not matching the shortcut being run.
So rather than replacing the EXE and running the real one when done, I made sure the updater application would always run before the real exe.
The only caveat is that it also runs for EVERY exe on the system (via HKCR\exefile). The first parameter is now the path to the true executable, which if it matches the application it runs the updater. Once the updater finishes or if it is any other app, it runs it.
Not an ideal solution (as it could be detected as malware), but it should work for us.
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.
I've written a shell extension using EZShellExtensions.net. It works great in my development environment when I'm logged in as me, as well as any other system when logged in as me. For all other users, the copy-hook I've created never appears. I've used NirSoft's RegDLLView to verify that the DLL is registered, but no luck.
What can I check to see why this is occurring?
FYI
I'm happy to send a copy of my code to whomever wants to help out with this. EZShellExtensions.NET has an evaluation period of 30 days.
UPDATE
ProcMon Output when using the vendor's registration tool now available as a CSV/PML file if anyone's interested.
RESOLVE
I wound up adding console output to the dll for debugging. turns out that a timer wasn't kicking off when running as any user but me (no idea why). This has since been fixed.
That indicates that the shell extension got registered in the HKCU\Software hive instead of HKLM\Software. Only the latter hive makes extensions available to all users. This commonly happens because UAC prevents writing to HKLM\Software unless the program that does the writing is elevated.
If this library comes with a dedicated registration program, they usually do, then be sure to run it from an elevated command prompt. Start + All Programs, Accessories folder, right-click the Command Prompt link and click "Run as administrator". Rerun the registration tool.
If you still have trouble then SysInternal's ProcMon tool can show you exactly where stuff gets written. And don't hesitate to use the vendor's support channels.
I am invoking an external process by using System.Diagonistics.Process and passing two filenames as parameters. Now some time this process terminates due to exceptions and it seems that files handle are not being released by the process. How can i release the resources occupied by the process.
What is making you think that file handles are not being released? Since you are starting a process which is external to your application you don't have much control over what the other process is going to do when it terminates abnormally.
This application is WMVAppend.exe (available with Microsoft Media SDK). Even when we restart the machines, it report the error dialogue and work fine for the next run. The issue with only media appending which is not done by our process. I also checked the source files and they seem perfect but they are not appended perfectly and files are not available to use.
Or It might be possible that process is not terminated at all, but i am using Process.WaitForExit() which should return only the process is terminated. The error dialog on restart suggests me this case could be possible.
How are you detecting that file handles are not being released by the dying process?
All resources should be released by a process that dies for any reason. If they aren't, then it is a bug that should be filed with Microsoft.