My Program.cs file was working fine this afternoon. I closed Visual Studio (VS2013 Express) and shut down my computer. Then this evening I turned the computer on again and Program.cs now looks like this:
f£óö'ûRÏ>•]|êêlÇPš—·õGÉ+s
qÖY®ÓÇNŽ9¯€8ï,? óQwÕ®Åy„Ùrsb^ ƒoÏEl?Qäº6z¹ Ü -³‡kwÎR®Q| €s᪠å²!dKË*:ÀyÉÿ?l
Ã&Š‚Ëð.Š›ï,²©“Óü#q:VªÐMãҟ岂¡ËÀÌ<öò§-ž‹66‚j$+”tVeÃÛSVÿ Ïr£pÉ'äûèk0Iœ¾Y/HÅ;vþ
DãjÊÕIÿóõ‘>¤¶ËLw¬,‚ÓHï’$t‡³Ywõ2ŽHíg3É·HVß{fÄèÄKõ™>§ïä ŽíC}r^— x èd’—X÷§º~qXPk#
etc.
Any ideas on how to recover it? I tried running Recuva, but that didn't work. There is no copy in the Backup Files folder for this project.
EDIT: I've confirmed that this is happening every time I exit VS2013 and then re-open any project. I was able to use dotPeek to recover the file by decompiling the project's .EXE. However, the file decompiles in a format that requires substantial editing in order to do more work on it, e.g.,
xlApp=new Excel.Application()
becomes
Program.xlApp = (Application) Activator.CreateInstance(Marshal.GetTypeFromCLSID(new Guid("00024500-0000-0000-C000-000000000046")));
I need a more practical long-term solution than repeated decompilation. I'll get started with source control, but I'd ideally like to fix whatever problem is causing VS2013 to corrupt the file.
EDIT: This is now happening with other files, in the same project and in other projects in the same solution. In reference to EBrown's comment about encoding, I checked the encoding and the affected files are in "Unicode (UTF-8 with signature) - Codepage 65001" (as are the unaffected files). I am able to restore to the last committed version using git checkout HEAD, but this issue is making my work very inconvenient. I'm hoping to find a solution other than reinstalling VS2013.
Related
I use the latest Visual Studio Community 2017 (15.4). And since i installed Visual Studio (never worked in it before). I have ALWAYS despite version had this issue. After compiling a couple of times i start to see:
Unable to copy file "obj\Debug\afile.exe" to "bin\Debug\afile.exe".
The process cannot access the file 'bin\Debug\afile.exe' because it is
being used by another process.
I searched around and tried just about everything. Nothing works for me. It can be fine for some time but after a while it starts to show again and i can´t compile.
I run on a Windows 7 OS. I have Avast installed and Comodo Firewall. The project is under SourceTree sourcecontroll. I have excluded the obj and bin path in programs.
I have tried changing AssemblyVersion and AssemblyFileVersion. I have tried uninstalling Avast. I have tried "ProcessExplorer" to find what process is accessing the files (0 match).
I really don´t know what more i can do? This is getting really frustrating when you are testing the code you wrote a couple of seconds ago.
I have seen old threads about this issue. Is there nothing i can do to fix this?
When I had this problem, I solved killing the process VBCSCompiler.exe and everything came back normal.
But after the latest updates of the Visual Studio I do not have more this issue.
To finalize the process, you need execute the command taskkill /F /IM VBCSCompiler.exe in cmd, or search the process in manager process of the Windows.
For anyoneelse who have this problem.
Check that your files in Debug and Bin (exe file) is not locked. That is because of another problem. Antivirus software tends to lock files. If they are locked, find out what process is using them.
If they are however not locked (like in my case). This article helped me:
https://www.codeproject.com/Questions/296249/Visual-Studio-Access-Denied-Errors
"Solution 9":
Turn on windows service :- Application experience
Computer (right-click) -> manage -> Service & Application -> service -> Enable Application experience
So far that has worked for me. Never had the error since i started "Application experience.
Check also that it starts automatically.
While this might be an old thread, I want to second the fact that you should double check on the .exe file being closed. I ran into this issue and tried the other methods before realizing an .exe version was still open in the processes in the background. Double check for a ghost copy still running behind the scenes.
Not one to jump on an old thread like this, but if you are setup using IIS on your local machine, IIS will sometimes keep that folder locked. An IIS Reset from the command line will take care of that, but it usually gives it up after a few minutes.
What worked for me
Saved the contents of the file that I couldn't save in a different file
Deleted the file that I couldn't save
Renamed the new file to have the old file name
When I am trying to debug (F5) in visual studio the compile hits 100% and sits there and takes forever to start my program that I want to debug. Also when the program does start it takes just as long for the program to close and the Visual Studio to start responding. Does anyone know why this happens?
Project is C# wpf, I use to have a silverlight project that did the same thing. I moved all the code to a new project and now my silverlight project works better now.
No special debug option, the same options that come with a new project.
The project is on the local C drive hooked up to TFS 2010.
No Static Analysis or ReSharper that I know of.
My Solution has 14 projects in it. 1 wpf and the rest are dll's and tool exe's.
No Anti-malware, and I disabled antivirus just to make sure it wasn't eating my lunch.
I unplugged my network cable and that did not help any of the network timeouts.
Disable any symbol servers Did not help.
I have found out that if you delete the .SUO file that things get fast it has been removed. It is next to your .sln file. My .suo file was 4.5 mb.
From Google all I can find is that the .suo file is some kind of user settings file but doesn't seem to do any harm when deleted, it just gets recreated.
Found that when doing an import on settings you can get your .suo file to go up in size... the size of the .suo file might not be the issue however a corrupted one might be the issue. I imported setting and made my .suo file go up to 5.7mb and my compile works ok, I deleted it however again because I don't want it to get corrupted.
We're creating WCF services (.NET 3.5) via Visual Studio 2010. When I make a change to the .svc.cs file, save, clean, rebuild and copy to GAC (using WSPBuilder, which recycles the various IIS processes) I still get cached data. Only drastic things like checking in all my files and running a gated checkin build, or restarting the computer clear this 'cache'.
The upshot of this is that the development->testing cycle is extremely slow. But it need not be! Here's my question. Where is the cache that VS2010 or Windows is keeping for WCFTestClient? I can add debug breakpoints and the symbols show up in the debug (so that means on some level I'm using the new assembly) but key things like watches will show old, cached variable values.
Is there a cache somewhere for this data? Looking at the list of .dll files in the output that the WCFTestClient is using when I run debug(F5) shows that it uses the correct .dll (and my observations during debug confirm this.)
I just need to be able to remove (manually if needed) this cache between rebuilds of my assembly. Otherwise, I can't actually rectify problems in the code.
If I'm missing something obvious here, let me know.
Try deleting your solution .suo file.
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.
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.