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.
Related
Debug (or Release) folder of my Desktop application when copied to another location does not run the exe. It issues no errors, but simply hangs the system for a second or two, but returns to normal straight away, as if nothing had been run.
Does Visual Studio 2015 create dependencies in upper hierarchy of Debug as well? My installer created using Wix was not running the intended exe and i thought it was Wix's problem. But then i tested it by copying the full Debug folder in a temporary subfolder and the app was not running even from there. It can only happen when it has dependencies present in places other than the Debug folder (because system resources (dlls) are accessed from absolute path of C: drive, so they would always be available.
Could there be something wrong in your manifest file or some other settings file? Some relative path pointing to a folder in your source hierarchy? Maybe it is just an image file or some sort of settings file that is missing? Or it might be something completely different.
A I wrote in your other question, one approach for hard-to-debug dependency scenarios is to just bite the bullet and run a thorough procmon.exe session (that is a direct hotlink to the live sysinternals tool share, clicking it will start the download instantly - just so you are aware).
You can see a quick description of how to use this tool in this question: Registering a CPP dll into COM after installation using Wix Msi installer. The key is to set an include filter which will show only events you need to see - basically for your own application.exe should suffice I believe.
Many find this procmon-stuff overkill, and don't want to deal with it - but trust me, it almost always reveals something unexpected (not always useful however).
As before this answer may also be worth a quick skim (on dependencies in general): After creating MSI Installer for WPF app in Visual Studio 2017, EXE does nothing. I would at least try the Dependencies.exe tool - even if it is a bit "beta-ish". You can download from here: https://github.com/lucasg/Dependencies/releases.
And certainly double-check the modules view in Visual Studio which I describe in the linked answer (Debug => Start Debugging, then go Debug => Windows => Modules). It should show whatever was loaded to run your project interactively.
I have a very large solution that contains many projects. I am trying to debug two processes at the same time:
A server and a client.
I compile the code, and then run the server process by pressing F5. All is well.
I now want to run my client process. To do that, I right-click the project, and press "Debug>Start new instance".
This results in the error "CS2012: cannot open '.....GuiUtils\obj\debug\GuiUtils.dll' for writing - ..... because it is being used by another process." However, the server has no dependency upon 'GuiUtils', and this library is also not present in the bin\debug folder of the server.
Not needless to say, I didn't update the source files of GuiUtils, so building it is futile regardless of this problem.
It seems like visual studio is using that DLL and locks it for no apparent reason.
Both projects are C# projects.
Help, anyone?
Thanks!
New to Visual Studio and new to C#. Building a C# windows service called Transactional Messaging in Visual Studio 2017, which is dependent on a project called Outbound Messaging. When I start debugging and try adding breakpoints on the Outbound Messaging files, I get
"The breakpoint will not currently be hit. No Symbols have been loaded
for this document"
From what I can tell, VS is only unable to load the pdb files for: log4net.dll, Castle.Windsor.dll, and Castle.Core.dll. I don't have this issue with adding breakpoints to files in the Transactional Messaging Service. I haven't been able to identify behavior patterns or a permanent fix, so at this point the error seems random. One minute I think I've found a fix, and when I try using that fix on the same error later in the day I have no luck. I am suspicious of a recent power outage that shut my computer down unexpectedly since it looks like pdb files can be cached, but have been told that would be a long shot.
Steps I follow to debug the service:
Stop Transactional Messaging Service via windows services applet
Uninstall Transactional Messaging Service via VS command line using installutil /u TransactionalMessaging.exe in the Debug folder
Clean Transactional Messaging Solution in Visual Studio
Build Transactional Messaging Solution in Visual Studio (at one point a fix was to right click on each aspect of the solution in the solution explorer and build that individually)
Install the Transactional Messaging Service via VS command line using installutil TransactionalMessaging.exe in the Debug folder
Start the Transactional Messaging Service via windows service applet
In VS, Debug > attach to process > Transactional Messaging
Try adding breakpoints to files in Outbound Messaging service which gets me the above error.
Steps I've tried to solve this error:
Debug > Windows > Modules to manually load each module's symbols (pdb files for log4net.dll, Castle.Windsor.dll, and Castle.Core.dll cannot be found)
picture of modules
Completely delete bin and obj folder between steps 2 and 3 above
Project > Project properties > Build > Advanced > Debugging Information: full (for both Transactional Messaging and Outbound Messaging)
I'm not sure if this is a lack of understanding of VS, C#, or the code base. Any insight is appreciated, I'm past the googling stage and posting a new question as a last resort.
I usually get this message when I have changed code in a project A and forgot to compile it.
The other project B, which references project A, has the up-to-date source code of A on the screen, but started with an outdated assembly of A. So it cannot enable breakpoints because the code does not match the assembly.
There's one more thing, which in my opinion is a bug and a pain in the ass, but according to MS is by design (I have asked them):
Since Visual Studio 2015, the compilation of project B does NOT automatically include modified referenced assemblies, which in this example is assembly A. There is a local copy of A somewhere in B, which is used instead. Same result as above: up-to-date code, but outdated assembly.
Instead of compiling, you have to rebuild it!
There's another one more thing:
You have to compile for DEBUG mode. In Release mode, the default project settings do not allow proper debugging, like they did in VS 2008 for example.
You can not attach the debugger, because you are lacking the right to do so. You can get this right only be flipping a certain bit in the registry.
See my earlier Answer:
Also start VisualStudio as Administrator and allow, that a process can
automatically be debugged by a different user:
reg add "HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f
If nothing help from above than make sure your files are open from the relevant project, not from another (old) one.
Example:
You working on a project, close the VS, but you left files (tabs) open in VS.
Copy your project to a new folder and open solution. The files (tabs) will load from the old directory and if you want to debug then you cannot debug until you close them and reload them from the current folder.
I was very close to reinstall my VS because nothing helped for me from another answers, but fortunately I realised this in my project and I can debug now.
I accidentally deleted my project from visual studio2013/projects/myproject. I did a system restore and got the folder myproject. I am unable to see my code form or design form but I can run my application.
What d I have to do to be able to edit my code?
System Restore will only revert the computer's state (including system files, installed applications, Windows Registry, and system settings), not user files, and your sourcecode files are user files.
Since you can still run the application, then you must have a compiled executable somewhere. I suggest that you download dotPeek from JetBrains and then you can open your application up in it and decompile your assembly back into source code.
The code will be a bit ugly; your nice, meaningful variable names will probably be gone, but at least it's a starting point. Here's the link to dotPeek. https://www.jetbrains.com/decompiler/
BTW, I'm assuming that you've already tried to get the files back from the Recycle Bin.
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.