We Keep Coding

Visual studio 2013 locking PDB files when debugger is attached

I'm working on a project that retrieves a number of Solutions from a team foundation server, to a temporary folder, uses Microsoft.Build.Execution.BuildManager.Build to build a release version for these Solutions, and cleans up the temporary folder with source code afterwards.
The problem arises when running my project with a debugger attached:
during the clean-up I get a system.UnauthorizedAccessException with message
"Access to the path ...\obj\release\CalithaLibrary.pdb denied".
Using sysinternals Process Explorer I found out that the lock was aquired by devenv.exe.
When I build a release version of my project and run it outside of visual studio the problem does not arise.
Any ideas as to why Visual Studio would aquire a lock of a PDB belonging to a project that was never opened by Visual Studio?
Edit: The first answer I received made me think I probably wasn't clear enough about the situation:
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
If I were trying to delete the AutoReleaseService.pdb from my own project, to which I did, in fact, attach the debugger, I'd understand, but the project to which the pdb file that gets locked belongs hasn't even been run on my machine, let alone debugged. I only built the project.

I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
Well, CalithaLibrary looks like a DLL project, which is most certainly being used when you run AutoReleaseService.exe. It is straightforward - when the exe project is run, it uses all of the dll-s which it depends on. Visual Studio (devenv.exe) locks the .pdb files, because they are the link between the source code and the executable when you debug the application, and if you open the executable from outside of Visual Studio - they are not locked, because you do not need them then.

I'm starting to become pretty sure there's a bug in MSBuild here somewhere.
Luckily I managed to debug the last part of the application I needed to debug by excluding a few of the builds it was making, so it's now running in Release and does not encounter problems anymore.
Some information on why I think it must be a bug.
My application's workflow was something like this:
Create a temporary workspace on Team Foundation Server
GET a number of solutions/projects from TFS to a temporary folder
BUILD a number of these (configurable through xml but that's beside the point) to a different temporary folder
Clean up the temporary folder with source code
I tried setting MSBuild Options "DebugType" to none and "DebugSymbols" to false, but for some reason it kept outputting the Program Database files which is why I think there's a bug somewhere.
Whenever I skipped the "Building" step and skipped straight ahead to "Clean up" there were no locks on any files.

Slow compile times when Visual Studio 2012 is open

Afternoon all,
I have a very strange problem. When VS 2012 is open, compile times are very slow. This slow compile time is present when building via VS and/or directly via csc.exe from the command line.
To test: Create a folder with the following items:
A batch file (compile.bat) containing:
echo %time%
csc /target:library class1.cs
echo %time%
and a class1.cs containing:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ClassLibrary1
{
public class Class1
{
}
}
Now open a visual studio command prompt. Navigate to the above folder and run the batch command, without VS open. On my machine, this takes approximately 10ms, perfect.
I now open VS 2012, open no solution, do nothing other than open the the application so that devenv is running.
Now repeat the test by running the batch file, compile time is now 10000ms (10 seconds).
I have checked the event viewer for anything that is happening when VS is open but not when it's closed, used procmon and filemon to look for file access and checked to see if VS is enabling any services when it is open, all without success/impact.
I have even tried uninstalling and reinstalling VS, this solved the problem for the first few builds but it then reoccurred. Restarting the machine has no effect. I have no plugins installed in VS.
My colleagues machines do not display this problem and they have the same setup. This is all running on a machine with 16gb ram, 64-bit win 7 and SSD.
Anyone got any clues?

I've figured this out. I believe it was the result of some malware. I diagnosed the problem with the following steps.
Download ProcMon (http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx)
Add a filter to ProcMon on process name: csc.exe
I then ran a compile from the command line, with visual studio open. It took around 10 seconds, way too long! Looking at the output in the ProcMon window, I noticed what appeared to be csc.exe pausing for 5 secs, once towards the beginning of the trace, and once towards the end. See the following screens:
Start:
End:
It appeared that a RegCloseKey to HKLM\SOFTWARE\Wow6432Node\5c28f8fbc6fe942 was causing csc.exe to wait for 5 seconds, twice.
RegKey:
I then decided to rename this entry (added _old to the end), I then recompiled....BINGO, it compiled in less than 30ms!
After studying the entries contained in this key and some googleing it turned out that this reg key was the result of some malware. I used the following guide to remove thte malware and now the problem is completely solved.
http://www.explosiveknowledge.net/main/2012/08/19/browsemngr/
Please be aware that the guide above doesn't contain the correct reg entries, I think the virus must have been tweaked at somepoint, I couldn't find the reg entries mentioned in the guide but simply deleted the ones I'd found.
Please note that the 5c28f8fbc6fe942 part of the reg key seems to be randomly generated. If you have this problem is might be different but the values contain within will still talk about "Browser Manager".
Hope this helps someone!

To understand your query we need to look into the concept of response file.
A response file is a text file that contains a set of compiler commandline
switches. When you execute CSC.exe, the compiler opens response files and uses any
switches that are specified in them as though the switches were passed to CSC.exe on the
command line. You instruct the compiler to use a response file by specifying its name on the command line prepended by an # sign. For example, you could have a response file called
MyProject.rsp that contains the following text:
/out:MyProject.exe
/target:winexe
To cause CSC.exe to use these settings, you’d invoke it as follows:
csc.exe #MyProject.rsp CodeFile1.cs CodeFile2.cs
This tells the C# compiler what to name the output file and what kind of target to create. As you can see, response files are very convenient because you don’t have to manually express the desired command-line arguments each time you want to compile your project.
When you install the .NET Framework, it installs a default global CSC.rsp file in the
%SystemRoot%\Microsoft.NET\Framework\vX.X.Xdirectory (where X.X.X is the version of
the .NET Framework you have installed).
The Visual studio 2012 uses this default response file for compiling the code.
Because the global CSC.rsp file references all of the assemblies.Referencing all of these assemblies could slow the compiler down a bit.

Unexpected Error creating debug information file GG.PDB"--"

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.

EXE not running, accidental change in configuration?

I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".

This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.

I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.

Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.

I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.

MissingMethodException thrown when calling new form in Compact Framework

I'm updating an old mobile device application for better flexibility. I had basically added the ability to configure the address of our SQL server in the case that we want to use our test server as opposed to our production server. I don't think this is causing the problem, but I wanted to state it. I also upgraded the project from a VS 2003 project to a VS 2005 project.
The issue I am having is that when I try to run the program in the VS emulator for Pocket PC, I get an error. It occurs after our "main menu" form loads and the user selects the next form to load. The form is initialized without issue, but when we try to run the .ShowDialog() method, it throws a System.MissingMethodException.
I don't have a lot of experience with the Compact Framework and really have no idea where to start looking for problems. I stepped the debugger through the entire initializing process for the new form and it ran without issue. But, again, when we come to the ShowDialog call, it throws the error.
Any ideas in where to start looking or known issues would be greatly appreciated.

I'm usually getting MissingMethodException for this reason:
I've got at least two files in my project, for instance an .exe file and a .dll file
I make changes to the .dll file's source code, and recompile
VS says it deploys the new .dll file to the device, but indeed it does not (it keeps the old file)
The .exe starts up fine, but when it starts accessing the .dll file the application throws a MissingMethodException, because it can't find the methods in the old dll file.
Fix: Delete the entire application directory from the device and redeploy.

I should have added this long ago. The answer ended up being that the incorrect version of .NET was installed on the Mobile Device.

A possible issue that can cause this situation is that the DLL is not being updated when deployed. It can be caused by the DLL in question being a dependency for more than one executable.
For example let's say executable A is running on the device and it is dependent on the DLL's method callA. You are trying to debug executable B which is also dependent on the DLL but on the method callB that you just added. When Visual Studio goes to deploy the DLL with callB in it, it is unable to do so because executable A is still using it. Visual Studio does not tell you that it was not successful in deploying the DLL. (Liar VS! ;)
To fix it, kill all the executables that depend on the DLL and then deploy it.
#Felix Alcala - You got an up vote from me. I would add this as a comment to your fix because it is directly related. Alas, I did not have the rep to do so. But, I want this answer to be public because I found it helpful

Start looking in the ShowDialog method itself. The error is slightly misleading - it's not ShowDialog which it can't find, but the JIT compiler is probably trying to compile ShowDialog, and throwing that exception (because ShowDialog is trying to call something it can't find). If ShowDialog is in a different assembly, then there may be something static that can't be initialized, which could similarly cause this - but start out looking in ShowDialog itself.
Because of this, one trick to finding the problem (if it isn't obvisou) is to reduce the code in ShowDialog until you find the line causing the problem. I'd start out commenting ALL the code, to confirm my hypothesis. If you no longer get the exception, try uncommenting about half of the remaining code at a time, etc.

You can get this exception when you try to use a regular WinForm class from a compact project.