When I try to build my project, it returns the following error:
Error 1 Unexpected error creating debug information file 'D:\Documents\Lance\Documents\School\Capstone\GG\GG\obj\Debug\GG.PDB' -- '' GG
I've recently had the misfortune of having my PC restart on me, due to sudden power supply problems (maybe). This is while the project was building, before this problem started.
When the PC came back online I've noticed that the changes I've made to the program prior to the sudden power down was not saved. And, it won't build anymore.
This worked for me:
Shut down VS.NET
Browse to the project in Windows Explorer
Delete the /obj/ folder.
Delete the project outputs (.dll and .pdb) from /bin (not sure if this step is necessary)
Can't hurt but might help: delete the project outputs from any other project /bin folders in the solution that is having issues (wasn't necessary for me)
Restart VS.NET
Rebuild
http://weblogs.asp.net/ssmith/archive/2003/08/12/23755.aspx
As requested, my comment as an answer:
Try cleaning the solution (under the Build menu in VS).
Since the build was interrupted half-way through by your power failure, the file isn't locked -- the build system is probably just in an inconsistent state (which a Clean Solution should fix).
This happens once in a while in my environment and the problem probably has to do with the PDB file being locked (i.e., I'm guessing the last part of the error message is missing in your post). This is how it looks on my machine:
Unexpected error creating debug information file 'c:\dir\obj\file.PDB' -- 'c:\dir\obj\file.PDB: The process cannot access the file because it is being used by another process.'
In my case, cleaning the solution does not solve the problem and restarting is an overkill, so I usually just copy the full name of the pdb file (from the error) and execute this on the command line:
ren c:\dir\obj\file.PDB *.old
This worked for me: Close Visual studio and open visual studio using Run as Administrator and problem was solved.
Not need to restart or delete the file.
Just rename the file and that is enough. If you try to delete the file it will give an error. Better just rename it & it will work. :)
If you are having this problem with a web application, this can happen in the unusual situation that you have used DebugDiag and created a rule that listens on your project's app pool. Deleting the rule prevented this problem from recurring.
This might happen, for example, if you followed these instructions for diagnosing a stack overflow exception in IIS.
If you are working on VM with two user, make sure the other user has not attached all the process while debugging.
Cons of restarting VS:
Clipboard will be lost
Redo/undo will be lost
Files open will be lost
You will loose the tempo
Solution:
Give your Assembly a new name. No cons. Except you will have to rename your assembly back to its original name when you are ready for final deployment. And I think anyone can find how to make it work for the last time :)
Sometimes all the files from \bin folder are used by a running process, i.e. web site on IIS or windows service run automatically after build. In such cases turning off the service or stoping IIS app pool for specific site should also help (like in my case)
Sometimes I run into this problem, when compiling the same project for (very) different targets:
VS2008 and net35
VS2017 and net462
dotnet core 2.0
My guess is, that either bin and/Or obj directory are used by the compiler, but the outputs are not compatible (of course). Solution clean from VS indeed helps.
Often we specify different dll names for the output (e.g. mylib.dll, mylib35.dll) and the issue never happened on those projects.
Related
I'm running my .NET 4.0 (C#) project in debug mode after I start VS2013. It runs just fine.
The second time I start it from VS, I get the Dialog box that says "Error while trying to run project: Unable to start program C:\path\to\file.exe"
The process is still alive in the Taskmanager when I dismiss the dialog box.
From Windows Explorer, I can run the program just fine. And after closing it, the process is gone too from the Task Manager.
A rebuild doesn't help.
Is this a common problem with a known solution?
I had an issue similar to this and I had to clear the component cache instruction can be found Here.
Hope this helps.
For my case, it cause by Platform target, you could force choose it to x86 or x64 which your project is:
Each Project's Properties > Build > Platform target
As I pointed out also here, the only solution that worked for me was to disable the ConEmu integration:
ConEmu → Settings → Integration → Default term → disable Force ConEmu as default terminal for console applications
Some users reported that it was enough for them to disable the Aggressive mode in that same settings tab; that wasn't the case for me though.
The topic is old, but this might help someone else.
So in my case I made a file in Visual Studio with .cp extension (accidentally deleted the last 'p') this made visual studio just "include" the the file and not mark it as a compilation unit, thus not compiling it, I looked the *.vcxproj file in a text editor and found out about this, so if you open the project file in a notepad or something just find your file at the bottom usually and change from <Item .../> to <ClCompile .../>
I was getting similar errors. I just had to restart visual studio. Sometime couple times a day.
I had a similar error and resolved it by cleaning the solution. Right-click the solution name in Solution Explorer and choose Clean Solution.
I found a solution here:
Please check "Use Managed Compatibility Mode" under Tools|->Options->Debugging->General.
I'm Brazilian, I don't speak English very well. I did this translation on google translator.
I know the topic is old, but it can still help someone.
I had this same problem in the following situation, I have a dual boot computer (linux debian 11 and windows 10). Inside debian, on my NTFS D disk, I created a folder to perform programming tests. After accessing that same folder with windows, I created a new project in visual studio inside that same folder that I had created in linux. The creation of the project went without problems, however when I tried to run the project (F5), I received the same error from this topic. I tried all the solutions I found on the internet, and nothing worked. I gave all permissions to my admin user and it still didn't work. Then I realized that even going straight to the folder where the application's executable was and clicking directly on it, I still received the access denied error message. So, I took the project out of the folder I had created in linux, and it worked. So, what I could conclude, is that because the folder where my project was was created in linux, for some reason, my windows didn't trust this folder, so it didn't allow running executables from inside that folder, even this one executable having been created by visual studio from within windows.
Just simply create a folder name as "projects" in c drive and copy paste the newly created project in it. Run the project by doing clean & Build or Rebuild method . It will work
open the folder which contains the solution in visual studio.
again, open your *.sln file by double clicking it inside the solution explore once opened try running the solution or rebuild the solution. once rebuild gets completed, it will open without error from next time.
My way of solving the error : error while trying to load project : Unable to start program and c:\Path\to\file.exe was simply by
First restart Visual Studio
Click the build icon
Select the rebuild option
Run the Program or Debug the Program
This was a weird one. Going to put what happened to me here because it might happen to someone else. Everything was fine with the app until suddenly after some fairly insignificant code changes I suddenly started getting this error. Visual Studio was compiling the executable just fine. But, the moment I tried to run it (either from Visual Studio or directly) the executable file would be automatically deleted right out of the Debug folder. Super odd--never seen anything like it. I began to get suspicious that perhaps an anti-virus or the OS was somehow identifying a checksum or some signature in the executable as "dangerous". Or perhaps some obscure compilation bug was corrupting the executable. So on a hunch I made another innocuous change (added a couple of lines of code to color code some text in a rich text box) and the problem went away.
I'll give you 2 versions of my problem to describe it, first the short version.
When I try to build my application it does that perfectly and my app works but when I try to rebuild it, that fails and gives an error message saying that 2 files are missing (bin/debug/MusicPlayer.exe and bin/debug/MusicPlayer.pdb). When I then try to build normally, it fails to with the same error.
Now the longer version:
The way this happened was quite out of nowhere, I program on 2 different locations (both in Visual Studio 2010 sp1) but to always have the recent version in the right place I copy the entire solution folder to a usb stick, this folder I copy over again on the other PC and use it to continue were I left off, I've done this many times without problem. Yesterday however, I got an exception while testing the app. But instead of showing this in my code, it was complaining that it could not find the program.cs file (it was there, but apparently it had a different checksum (md5) and it asked me to use this one. After a while I found what part of my code caused the exception and fixed it. Since then I haven't got that error anymore. But when I later tried to rebuild instead of build, it gave me the error described in the short version. I have tried to fix it, but apparently I was not very successful.
Basically, what I think it does is delete the files in the debug folder that need rebuilding and then gives me the error of missing files (the files that it deleted) and thus failing to rebuild succesfully because these deleted files the normal build option won't work to.
(What I then do is re-copy them from my usb to make the normal build work).
Don't know if it's important, but I program in C# and I'm still learning.
Also when I copied it to my usb I believe I had no errors and the app was working fine (except the part I fixed later, which I could not test at that location). And when I build the entire solution it gives some warning ==> "Assembly 'bun/debug/MusicPlayer.exe' is incorrectly specified as file" and this for 5 files.
Does anyone know how to fix this rebuild problem and if necessary the warnings?
Thanks in advance
(and sorry for my bad English)
OK it seems like you might be confusing yourself with your directory structure here. If you want to add Content or Resources (Images, Text Files, etc.) you should place them in a folder within your project (not called bin or obj). All your build files will go here. Instead place the Content in another folder and Right Click -> Properties and Set the build action to "Content" or "Resource" and set the Copy to Output Directory (bin folder) to "Do not Copy" or "Copy if newer."
The project is failing because you have the built executable "MusicPlayer.exe" in your project. So Visual Studio is trying to build an executable file in adding to the project. Restructure your directories or remove "MusicPlayer.exe" ever time your build your project.
Do you have any anti-virus software running? They can go way too aggressive on removable drives. You are actually continuously deleting and creating a runnable program on usb stick by recompiling.
Just a guess tho...
Sounds to me like you have a pre- or post-build event with a hardcoded path in it. Fix that using variables and it should be ok.
I've got a C# webforms app, that until today had been working just swimmingly.
Now today, all of a sudden, every time I try run the app, I get a file locking error:
Unable to copy file "obj\Debug\MyProject.exe" to "bin\Debug\MyProject.exe". The process cannot access the file "bin\Debug\MyProject.exe" because it is being used by another process.
Googling the error doesn't come up with anything beyond the obvious, i.e. VS thinks the file is locked. And it is definitely Visual Studio itself that locks the file, because when I close VS and reopen it, the project executes fine - the first time. When I try to run it a second time, I get the file locking error.
Closing VS and reopening every time I want to run the app is not a viable workaround! How do I find out what's locking the file, and stop it from getting locked?
EDIT: Another interesting discovery: I don't even have to run the app. Just compiling it once causes the file locking; I cannot compile twice in a row!
This problem is specific to one project in my solution. All other projects work fine and can be executed as many times as I like. It's only this one project that gets itself locked up.
I have found a simple solution which works for me. It goes like this:
When the problem occurs, just change the building configuration at the top (if in “Release” to “Debug” and vice versa), build and then change back to previous configuration and build again.
I suppose that changing the configuration releases the vcshost and devenv.
Well, I solved the problem myself - though I still have no clue why. I decided to isolate the problem by removing all files from the project, then re-adding them and determining that way which file was the source of my trouble. So, one by one I reintroduced files to the project, compiled & cleaned each step of the way... until... I added the last one...
... and everything still worked fine.
I did a compare to the source control of my original .csproj; no real differences. And even when I tried reverting to the previous version of the .csproj, it still worked.
Black magic. If it works, sometimes it's better not to ask why - just accept it and move on...
EDIT: The problem is a recurring one, and I believe I've isolated it to when I have the form designer open of an abstract/generic form at compile time.
Lesson learned: Make sure the Form Designer of any abstract or generic forms or controls is closed before you compile! If not, you have to close VS and reopen!
What we have discovered here, is the following:
In the project properties page, Debug tab, uncheck the "Enable visual studio hosting process".
I am unsure what this property is for, but it does the work once unchecked.
Solved by closing all instances of MSBuild.exe in the windows task manager
Actually you should want "Enable the Visual Studio hosting process" checked. At least for VS2010 anyway. And I also have:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
in the pre-build options. This problem has dogged me for a very long time and it wasn't until John W. mentioned this check box that I even took notice that it existed and low and behold it was already unchecked.
Also notice that -app-vshost.exe runs in the background even when not debugging. Which is what makes it successfully build and run every time I guess. It wasn't running before. And I also tried cleaning out the debug and release folders and changing the target type constantly and nothing worked except as described above. My solution before was to just wait 5 minutes between builds, which got super annoying and time-consuming to get anything done. I haven't seen any change in behavior where it mattered what tabs where open or XNA vs windows form or designers being opened. This issue occurred in 32-bit or 64-bit builds and didn't matter if I killed an app with ALT-F4 or killing it with task manager, which would, in theory, not allow the app to close or release resources. At first I thought it was a garbage collection issue.
I have overcome this problem by renaming the locked file (using Windows Explorer). I was not allowed to delete the file, but renaming the locked file works!
Little late to answer, but I solved this by going to the properties of the project > tab "Debug" > unchecked "Enable the Visual Studio hosting process" option.
I solved this by deleting the folder bin\Debug and, possibly, restarting VS
Run this command from the Run box:
net stop iisadmin /y
and then
iisreset
worked for me.
vs 2003
For me, it was a Windows Service that was installed and running. Once I stopped it, the build was successful.
I had a similar error but during the deployment of the UWP application. Finally, I found out the process that used a file that caused this error and stopped it. Credits to this link. Copy-pasted version is below.
How to Solve the Issue?
One of the easiest ways to handle locked files or folders is to use Microsoft Sysinternals Process Explorer.
Identify what program is using a file
Using Process Explorer there is a simple way to find the program:
Open Process Explorer (running as administrator).
On the toolbar, find the gunsight icon on the right.
Drag the icon and drop it on the open file or folder that is locked.
The executable that is using the file will be highlighted in the Process Explorer main display list.
Identify which handle or DLL is using a file
Open Process Explorer (running as administrator).
Enter the keyboard shortcut Ctrl+F.
Alternatively, click the “Find” menu and select “Find a Handle or DLL”.
A search dialog box will open.
Type in the name of the locked file or other file of interest.
Partial names are usually sufficient.
Click the button “Search”.
A list will be generated.
There may be a number of entries.
And then kill this process.
Unfortunately none of the answers worked for me. This is what solved it:
Win Key + R and run resmon.exe. There you'll find the EXE process that VS claims to be using the file. Right click and end the process. Although you might get an Access Denied error message, it will be suspended and you'll be able to build again.
Recently ran into this problem when attempting to build a solution I am working on (not just a winforms proj).
In addition to build failure, I noticed that cleaning projects would quietly fail (checking the bin folder showed that the files had not actually been erased) and closing the Visual Studio did not end the devenv process - rather, it caused it to crash. Windows recovery process would then restart the Visual Studio.
After some trial and error, I found the problems only happened to me when I opened the solution from the "Recent" menu on starting up VS.
Opening the solution from File >> Open >> Project/Solution found it working as per usually.
Currently no idea why - will keep looking into this but for now, at least I can work!
Just check the references and remove the self-reference to the project.
Explanation: My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
I literally removed the whole source code regarding the custom control and the problem still remained, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
I had the same issue on my Xamarin application in visual studio and it was resolved by unplugging my test mobile device. The application was closed and the debugger was stopped but the error was still happening when trying to build or rebuild the solution. It only stopped after i unplugged the device because i had to receive a call.
Just to throw in my 2 cents. My issue was solved by opening Task Manager and killing the application. It was running in the background without any indication that it was running at all (no item in the task bar, no ui, nothing), but I am not sure why this happened. Obviously the debugger was not running and I only had a single instance of VS opened at the time. It amazes me that this is still happening in this VS 2017.
Perhaps I can add a build step that looks for the application running the background and kills it before starting the new one.
I had the same issue and could not rectify by using any of the methods mentioned in previous answers. I resolved the issue by killing all instances of "SSIS Debug Hist (32 bit)" in task manager and now working as normal.
I had this issue (and its an issue I have seen in other places not just VS).
It's caused by Dropbox (in my case). After editing some code and hitting run, sometimes dropbox immediately locks the file (so it can process it).
Solution 1.
Just hit run again
Solution 2.
Pause dropbox. (not good if your using dropbox as your cloud backup)
Solution 3.
Remove the build folder from dropboxes sync list.
Deleting Obj, retail and debug folder of the .NET project and re-building again worked for me.
This got me stuck for over two days, had to reclone the project and save the project folder in a different name, but today I found the solution from a microsoft dev forum.
solution:
Create a pre-build action in your project by going to project properties (right-click on the project in the solution explorer, and select the Properties option), select the Build Events tab. Add this code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This code will copy the file to a different name, and allows the build to continue successfully.
How is your web app configured? Does it run under Cassini (the tray web server) or IIS?
This shouldn't happen normally though. I think ProcessExplorer can tell you what files a process has locked. If not process explorer one of the other sysinternals tools.
One thing to try before even downloading one of the SI tools is to stop the Cassini web server, and seeing if that frees up the file.
What worked for me was restarting IIS
i had this same problem as well. changing the debug/release config didn't do the trick. at least not without building in between.
in my solution (winform) it was solved by opening the mainform of the winform in the designer. switching to code (F7). Then closing the code, closing the designer of the winform and rebuild all (ctrl-shift-B). This worked for me.
seems like some kind of handle from within the winform app (which runs a backgroundworker) still had a file handle on some of the other libraries used.
I had two instances of Visual Studio opened the same solution.
In my case there were some vstest processes running (with various names but all containing the string vstest). I had to terminate them in taskmgr.
Same error, solved by updating Google Nuget support packages
When I ended the process .Net Core Host, everything built fine. I didn't have to close Visual Studio or do change anything else.
For those who are developing in VS with Docker, restart the docker for windows service and the problem will be solved immediately.
Before restarting docker I tried all the mentioned answers, didn't find a msbuild.exe process running, also tried restarting VS without avail, only restarting docker worked.
One more solution: when the files get locked, blocking process is reported (something like "ServiceHub.Host.CLR.x64 (7764)") with it's id in parentheses.
To get rid of the process, open PowerShell (x + Win + I) and type: "Stop-Process -Id idNumber".
I recently ran into the issue when deploying to Service Fabric. The error is implying a 'file' is in use, however, I found that the port was being used by another IDE. By stopping a running service which was already hosting on the port, I was able to stop this exception from occurring.
I am working on a gui app written in C# using visual studio and I am running into a really annoying bug where when I make changes to the application, it debugs correctly the first time I try to debug it, but when I try to debug the application again I get an error say that it can't copy an exe file from the obj directory to the bin directory.
Restarting visual studio fixes this.
It's really annoying to have to restart all the time though. There seem to be a number of posts online about this, but no one seems to have found the solution. Has anyone here been able to resolve this?
try VSCommands 2010 extension.
When you get the error again righ click on the message in error list and click 'Apply Fix' from context menu. This will tell you which process sits on the file and allow you to terminate it.
In a longer run, it may be that you have a background thread running which doesn't terminate when application finishes.
I have the same problem. I found in another thread (can't remember which) that for some unfathomable reason, you can change the assembly version declared in your AssemblyInfo.cs files from
AssemblyVersion("1.0.*")
into
AssemblyVersion("1.0.0.0")
Or some other explicit version, and the problem goes away. This worked fine for me. However, I would like a solution that would allow me to use the wildcard version as well. Or an explanation of why the assemblyversion causes the file to be locked.
is this a service? you may have to installutil -u prior to recompiling
In my case it was the Anti Virus software Avira antivir. When I added the publishing folders in the exceptions the problem went away.
Avira usually takes a long time to scan stuff in the background, apparently locking exe files before they can be overwritten. After the scan the file is unlocked. When my develop/test cycle is less than 30 seconds (which it often is) it will trigger this error after retrying 10x.
I'm working on a moderately sized WebForms project. Due to the peculiarities of management here, I have to upload the site to a remote server in order to test (no localhost testing). I'm using the 'Publish' command in Visual Studio 2008. Sometimes, it even works. Most of the time, I inexplicably get a "publish failed" in the bottom left corner, with no further details.
The few googled articles/forum posts I read suggested making the target local folder for the publish operation readable/writable for everyone. Doesn't help.
Is there are way to get further details as to WHY a publish fails in VS2008, and if not, is there a better way of doing these deployments? I'm spending more time building/pushing to the web server than actually debugging.
It's worth checking the output window. I've just had a publish fail because I had deleted an image outside of VS so VS was complaining that the image couldn't be found, but this information was only displayed in the output window.
See this link for more information:
http://ericfickes.com/2009/08/find-out-why-visual-studios-publish-fails/
It happens to us when there is an error in markup (!). Bad thing is that VS will just swallow the error and just tell you Failed.
What I suggest is to run your publish from command line using MSBuild. It's not that straightforward but it works (once you get into it).
I've since discovered that the reason for these particular publish failures was due the "Delete Existing Files" option being checked. Using Visual Studio 2008 under a non-administrative account on Windows Vista could cause a permissions error while attempting to delete the existing files. The publish would fail silently after encountering a file that Visual Studio had insufficient access to delete. Once the files were deleted manually outside of Vidual Studio, the publish functioned normally.
I have not had this issue with Windows 7; I assume the UAC changes in Windows 7 fixed the problem.
I mostly work with Web Forms, and I encounter this problem daily.
It seems to me that publish fails when it fails to delete a file it is trying to replace. Even if I don't have any files open, it still fails sometimes. Not sure why.
Not only VS publish fails very often, it is painfully slow as well.
I just publish to empty local directory and use separate FTP client to upload files. It's more work, but works.
This is probably not the case for you, but I've seen this happen when I'm publishing a web site. If the app_offline.htm file is not excluded from your project (if you use this file), the publish will fail.
Same happened to me.. what I did was include images files that was not included in the project and delete images that were not used.
After struggling with a similar issue for about 30 mins with no clue as to what was causing it closed down VS and reopened my project. Started working fine. No idea why but it worked.
You should always stop the IIS instance running on the machine your are publishing to. Google the word "iisreset". Other hosting providers like DiscountAsp and Arvixe offer you tools to "Stop" and "Start" your app pool on their IIS remotely. This is very necessary because IIS may have locked some files as "in use", so your publish fails when it tries to write over them. When your publish is complete, then just restart IIS (or press "Start" from a web tool if you're using a 3rd party hosting provider).
When all else fails, check your "Output" window (the tab to the right of your "Error List" at the bottom of Visual Studio). Scroll through all of it after a failed publish and look for anything that says "Unable to add". If you keep seeing the same "Unable to add" errors on the same publish, then ftp into the folder, delete the the problematic files manually, and try publishing again.
I got this when my ProjectName.Publish.xml file was read-only. Once I checked the file out of source control, I no longer got the error and could publish.
Just to add to this thread, I found that, for some bizarre reason, only the Mercurial files were being published to the server, everything else just wasn't being copied across.
Another strange thing was that only the Debug configuration was available; Release was nowhere to be seen.
After reading other threads around S.O., I found that there were many for VS 2010 and 2012, but not much to cover the same problem with 2008.
The fix, I found, was to delete the [solution].suo file and then attempt a publish. That seemed to do the job, though it took a long time to complete.
What I found and work in my case. It is to use a different version of VS.
I recently had the problem, the solution works perfectly in VS2015 build, compile and tested.
However, when I try to publish was failing silently.
So, I closed the solution and open it with VS2017 that use the same file structure for the projects/solutions. Then rebuild it and publish without any problems.
I believe it could be VS related and it is complicated to debug.
This is a workaround if you work with multiple Vs instances in your local machine.