I have a simple Console Application write with C-Sharp language (Visual Studio 2013):
using System;
using System.Collections.Generic;
using System.Text;
namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.ReadKey();
}
}
}
When I press F5 or click Start button, my project was built, but not launch.
Sometime, Ouput windows says:
Error 12 Could not copy "obj\Debug\HelloWorld.exe" to "bin\Debug\HelloWorld.exe". Exceeded retry count of 10. Failed.
Error 13 Unable to copy file "obj\Debug\HelloWorld.exe" to "bin\Debug\HelloWorld.exe". The process cannot access the file 'bin\Debug\HelloWorld.exe' because it is being used by another process.
but when I write Windows Form Application, my project was built and launch normally ???
Why? and How to solve this problem ?
This is most likely due to windows keeping the process open. Your only option is to try and kill all processes of your app in task manager->processes.
The next thing to try is to simply change the build from debug to release, this should build another executable in the release folder as opposed to debug. By no means is this a silver bullet but, hopefully a sufficient workaround.
Before you try the release build, attempt to try and fix the problem. I've seen windows moan at just having my debug folder open and my exe selected because I suspect the thumbnail was being displayed thus being "used" in windows etc.
I found reason and solve for my problem.
I tried to restart Application Experience Service and the problem was solved.
Please restart yor Visual Studio and then try again. It will work and delete your bin/debug folder again.
I have faced with this issue.
That happeneds when an instance of software is running whether by visual studio or by your self
solution :
you should find your application name in the processes of task manager
your's is :
HelloWorld.exe
select that and click on the end task button
now you can start debugging and running you'r app.
at least worked for me.
Related
I was working on a WPF application in Visual Studio 2015 and all went well until unexpectedly the build dropped me the CS2012 error inform me that it cannot access/update the executable in the /Debug directory.
I tried the following and it didn't work:
Restart
Close VS and open the application again
Build->Clean
I couldn't find any solution in the web so I tried:
1. to move the whole project directory to another location.
2. creating a new WPF project and assembling it file by file with copy/pastes.
The weird thing was that in both cases the application worked in the new location. I continued the experimentation (in the original directory) and i tried to build a "Hello World" Console application in the same directory. The result was that the trivial console application didn't work and produced the same problem as the WPF application (CS2012 error).
Since I haven't noticed any activity of another program (i.e., antivirus) trying to quarantine (or changing the file/folder permissions of) this folder, I assume that this has been done by VS somehow but I don't know why. Perhaps it is a bug.
Is anyone has a logical explanation about this problem? And a way to fix it?
I found that my other running solution was referencing the same < executable path>.
Just make sure that no other process is using the referenced folder/file/dll
Try to close all processes, move the project to a different folder (on a different disk) b restart the computer and everything will work as it should. It worked for me without any problems. Hope this helps someone
I wanted to quickly test something in a .NET Core Console Application Solution and ran into this issue due to BitDefender blocking the resulting binaries.
I've named the app client which actually was the culprit. Renaming my solution fixed this.
Sometimes antivirus softwares can block copying an exe file from a folder to any path. You can manage by settings or the easiest way is to shut down live protection while you are coding and debugging.
:)
Deactivate your anti-virus for a while and try again.
This works for me.
I am experiencing a weird behaviour from Visual Studio 2013. I've got a C# program which writes to the standard output, let's say
using System;
using System.Threading;
namespace CsSandbox
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world!");
Thread.Sleep(10000);
}
}
}
In the Debug tab of the project's properties I have redirected the output to a file, like this:
If I open the file within those 10s when my application is still running, the file does contain "Hello world!". However, as soon as the program exits, the file is cleared. This does not happen when I run the program from the command line.
Is there a rationale why Visual Studio does it? Is there a way to bypass this behaviour?
I believe this is due to the way Visual Studio hosts your application, in order to reduce startup time when debugging.
What happens is that your application (Program.exe) will actually be hosted in another process (Program.vshost.exe), which is started with the same command line arguments. When your application ends, this process is immediately restarted. You should be able to see this within Task Manager - look in the details tab so you can see the PID of the processes, and run your app - you'll see one Program.vshost.exe instance which ends when your app finishes, and another one come up immediately. That's then overwriting your output file.
One fix for this is to give your application a command line argument for the file to write to - and open that file within your Main method. You won't get there until you start running the app again.
Another option would be to simply stop using the hosting process - in the Debug part of your project properties, at the bottom you should see a checkbox for "Enable the Visual Studio hosting process". Uncheck this and I think your problem will go away - but it'll take longer to start debugging.
See this blog post for more information about the hosting process.
I keep getting this error message when I try to compile my app:
Error 1 Unable to copy file "obj\x86\Debug\WpfApplication1.exe" to
"bin\Debug\WpfApplication1.exe". The process cannot access the file
'bin\Debug\WpfApplication1.exe' because it is being used by another
process. WpfApplication1
You still have your application running. Check if there are no processes hanging in taskmgr. If not, close MSVS, delete bin and obj folders, reopen MSVS and try again.
Like it states, some process is using that file. Restarting Visual Studio might not be enough.
This happens to me sometimes because Avast Antivirus tries to scan and do whatever else it does to the exe of my application, and for some reason does not release it later.
One option would be to restart the computer.
Another would be to use something like Process Explorer and use it to release the handle on that file.
Using Process Explorer, you can release the file using this steps:
Find->File Handle or DLL...
In the dialog that opens search for the file and select it
Close the dialog and in the main window on the selected process right click and Kill Process.
Try to close Visual Studio and try again. Maybe you need to close the vshost program using Task Manager.
Sometimes the files get locked, but usually they are freed by closing and reopening Visual Studio.
Also see this question on SO
Try this its work for me just clean your solution and then Build Solution.
I got a break point on the first line of Application_Start(), but Visual Studio wont break on it.
Visual Studio have attached itself to the IIS working process:
Auto-attach to process '[2092] w3wp.exe' on machine 'SRD00510' succeeded.
My breakpoint in the home controller do work.
update
I've tried:
iisreset
restarted visual studio
Rebooted.
Tried to reinstall aspnet (aspnet_regiis -i)
Reading your question, I assume you are using IIS for debugging, not Visual Studio Development Server.
In this case, debugging application start is tricky, because it is only called once when the application pool is started or recycled. When Visual Studio attaches to the process, Application_Start has already been running.
The trick is to make the application pool recycle without killing the process you are attached to.
Do the following:
In Visual Studio (must be run as Administrator) set your breakpoint in
global.asax.cs and start debugging as usual (F5). The page opens in
your web browser, but the breakpoint isn't hit.
Now the trick: With a text editor, open web.config from where it is
served by IIS, change it (e.g. enter a blank line somewhere) and
save it. In contrast to recycling the application pool in IIS, this
lets the application pool recycle (and thus running through
Application_Start in global.asax.cs the next time the web site is
called) without killing the process you are attached to.
In your web browser, reload the page. The breakpoint should be hit now!
That works for me (IIS 7.5, VS2015).
Place this line in your Application_Start().
Debugger.Break();
This will present you with a dialog which will allow you to select a debugger. You might need to restart the application pool.
Application_Start() only runs once, when the application starts. A few things that restart the application are:
web.config changes
recycling the worker process - you can do this in IIS Manager or by running iisreset at the command line.
My solution is to switch to using the 'Visual Studio Development Server' to deal with the application class (Global.asax) issues. When done I switch back to IIS.
I assume you're loading the application by clicking the "debug" button in Visual Studio? That's what I'm doing (in VS 2012) and seeing similar problems. Pressing that button the first time starts the application and correctly hits the breakpoint. But it seems like after I stop debugging the application itself keeps going. So, future attempts to debug just attach to the existing process.
There's a "restart" button next to the "stop debugging" button, so I'd assume clicking that at least would change things.
The debugging app does not show up in IIS manager, so I can't stop it there. Likewise, iisreset doesn't catch it either.
Only thing I've figured out so far is to change a line of code, thereby forcing visual studio to trigger a build and then it kills the existing proc and starts over. Kind of annoying if I just want to step through there multiple times.
I don't consider this a suitable "answer", but it might be a helpful workaround for you until somebody does come in with a real answer.
I've got around this problem before by doing this:
Run a clean on my solution (Right click the solution node and click clean)
Close solution
File -> Exit on visual studio
If you have multiple instances of visual studio running then exit out of all instances. Ensure "devenv.exe" is not listed in the processes in task manager
Delete the user options file (.suo), usually in the same directory as your solution (.sln) file
Recycle IIS worker process or if using the development server, kill that process
Now open your solution and give it a shot. (keep your fingers crossed :))
Whenever you run an application for the first time, or say start an application, there is an ASP.Net Development Server - Port [port number] that starts,
Application_Start() runs once in the course of an application.
If you want the break point to be reached , you have to stop the ASP.Net Development Server Port and run your application again.
if [2092] w3wp.exe is a service that you made, try this :
stop service -> rebuild service project -> start rebuilt service -> try to debug
If using IISEXPRESS is not an option, as #David Perlman mentions, I would go for a Logger. Log4Net or NLog are both good. It's good to have a logger in the longrun, for instance in production environments.
namespace DataService
{
using NLog;
public class Global : System.Web.HttpApplication
{
private Logger log;
protected void Application_Start(object sender, EventArgs e)
{
LogManager.LoadConfiguration("nlog.config");
log = LogManager.GetCurrentClassLogger();
log.Error($"Read this line in the log specified in nlog.config");
}
I get latest from source control and can not build my visual studio solution. I get the following error:
Cannot copy assembly 'XYZ' to file 'C:\myfolder\bin\Debug\XYZ.dll'. The process cannot access the file because it is being used by another process.
I have rebooted the machine but nothing seems to work. please help.
Use ProcessExplorer to determine what other process is holding the DLL open - my bet is that it is Visual Studio itself. Try closing down any open form Design windows (or all code/design windows in VS.Net for that matter) and see if you still get the same problem.
You can use the handle tool to determine what process is using that file:
handle XYZ.dll
From there, you can figure out what started the process and why it's using the file.
Whenever i've seen that error, it was because the program i was trying to compile was still running. You may want to check and make sure any debug sessions are stopped (not just paused, but stopped completely), and that your program doesn't appear in the Task manager under the "Processes" tab.
Try changing the build configuration from Debug to Release and try compiling again.
let's try a simple solution. The DLL in your bin directory is likely marked as Read-Only. Visual studio doesn't check out the DLLs from the BIN directory when you check out source files. So if you keep the binaries in source safe then you need to manually check them out or manually take off the read-only flag in the directory.