Error Unable to write to output file - .PDB

07-26-2007, 11:33 AM
Last week I copied over a .Net2005 project from our development environment which is on the network, to the production environment, which is located else where on the network. Ever since then when I try to run this project or any other project in .Net 2005 or .Net 2003 that is on the network I get the following error: "Unable to write to output file 'F:\Application Development\Transit\Transit\obj\Debug\Transit.pdb': F:\Application Development\Transit\Transit\obj\Debug\Transit.pdb: The system cannot find the file specified." This also happens with any new projects since then that I have started.

If i run this or any other project locally from my hard drive, by copying it from the network then running it, it works fine. I have tried cleaning the project, rebuilding the project, deleting the debug and bin folders which is all I found during a google search, and thru suggestions here on this forum. I have also went as far as reformatting my computer and reinstalling everything.

Can anyone give me any ideas on what to try next? It kind of seems like a permissions issue to me, because all my projects work locally, just not off the network.

07-26-2007, 12:00 PM
It's clear the networking is what's breaking it, and I have three guesses.

My first guess is that file permissions are getting in the way; that would be a primary cause of not being able to write to a file. Check to ensure you have full access to the directory and its subdirectories.

My second guess is that multiple people are accessing the projects at once; if you try to build when someone else is debugging you won't be able to alter the files they are using. This probably is not the case since I believe the error message would be different and the problem would be intermittent.

My third guess is that some tool that is part of the build process is a .NET tool, and .NET programs require special permissions to do certain things when they are run from a network location.

Really those are just guesses; there's no telling what's really going on there. You should consider suggesting the implementation of a source control system, since one of their primary functions is to allow multiple locations to have consistent copies of an application.

07-26-2007, 12:38 PM

Thanks for the advice. I can rule out your first two guesses. I triple checked the permissions for the files and I have full access to them. And your second guess, I am the only one running this application right now, since it is still in development, so noone else can be debugging or rebuilding it at the sametime as I am.

I am looking into your third guess. How can I find out what tools are part of the building process in .Net. And can you give me a little more detail on what you mean with the "implementation of a source control system", you kind of lost me there.

Thanks again for the help.

07-26-2007, 01:29 PM
Well with the third issue I really don't know how to tell other then look at the build output window and attempt to manually build the project step-by-step; at some point it will fail and this might provide insight.

Oh also one no-brainer is double-check that the files aren't read-only; I find that sometimes Windows likes to set that attribute when you copy files for whatever reason.

For implementation of a source control system, it's kind of a large topic but I can provide a little bit of explanation. There are applications that ease the distribution and versioning of source code. Good free ones are CVS and SVN, with SVN being the better of the two. Perforce makes a good one that costs a good bit of money. Microsoft sells Visual Source Safe; comparing Visual Source Safe to the competitors is analogous to comparing Access to SQL Server.

When your code is checked in to a Source Code Control System (SCCS), there is one central location anyone will go to for the source. When you want to develop, you "check out" code from the SCCS. When you are finished, you "check in" your changes, which are merged with the code in the SCCS. A good SCCS (everything but Visual Source Safe) can allow multiple developers to work on the same project and the same files concurrently with a minimum of issues.

How it applies to this situation is I am assuming part of the reason for the project to be built from a server is so that the code can be accessed from multiple machines, possibly by multiple developers. The problems here are many but mostly concern the fact that eventually you will forget to copy a file, you'll break something, you'll lose a file, someone else will edit the file without your knowledge, and many other issues. An SCCS can solve all of those problems.

Even if the reason the code was moved is because it was being moved to a machine that is more similar to the production environment, an SCCS could help. An automated build application could be on the machine that checks the most current source out from the SCCS then builds it.

So I don't think it would solve this problem since I think it's a remote access issue, but honestly no one should be working without source control.

07-27-2007, 11:22 AM

Thanks for the explaination. I will get with the other developer here and talk to him about setting up a SCCS. One reason it is unable to find the PDB file in that directory is because it does not even exist. So evidently when I rebuild the project it deletes the PDB and then is not able to recreate it in that directory. That file appears in the debug and release directories under the bin, and in the debug directory in the obj folder, just not in the release directory in obj folder. Then once you get it to eventually to rebuild, and run it. Then go back in and make a change, the PDB might be in that directory but then be missing out of one of the other 3 directories, giving you the same error, with just a different path?!? This is starting to get really confusing.

I am also going to talk to one of our network guys and check the permissions of these directories to ensure they are set properly

07-27-2007, 12:37 PM

This reminds me of an issue I had a while back with 2.0 applications and the Microsoft XP x64 bit OS. Basically for whatever reason I couldn't get the debugger to jump to errors after a compile action failed. I couldn't reliably reproduce the problem under any other scenerio and I spent quite a lot of time running in circles with no answer.

Finally, after thinking outside of the box and then later FINALLY validating what I found as the problem buried deep in the Microsoft Known Issues database (never would have found it through just Google searching alone) it turned out to be an OS/path naming error.

I had a specific local folder for my development called "projects(x64)". The bug entailed the debugger being unable to resolve the virtual directory because of the "(" symbols in the name. This finally occured to me after hours of frusteration, or basically thinking maybe if I used only safe characters in my folder names that would fix the bug..and it did.

My point is, sometimes things like this drive us crazy and the answer is right under our nose, but not obvious.

Since we are all just stabbing in the dark here, a few other things which might help.

1) Do you have concrete evidence that only this particular server is the problem with no other variables? For example, can another developer create some test solution on their workstation, compile and run successfully locally, but then reproduce this erractic behavior on the same server?

2) What is the OS of this server? What service packs are installed? Is this Novell by any chance? Other? There have been circumstances where if the server is using the setting for long DOS filenames, this problem arises

3) Completely remove any server side configuration/path references from the equation. Does this temporary (not the solution, but area to look at) solve the problem:

-Delete all pdbs and your debug and release folders, etc
-Disable Debug symbols in your solution
-Enable Debug symbols

Under these circumstances, and what has already been mentioned before, I believe its a non issue that potentally another process is using these files, such as another application or instance of devenv.exe, and if that was the cause you would expect the error to be access denied, which is another flavor of PDB blow up, not this particular "file not found" prompt...but its worth investigating (but again, doubt this has anything to do with it)

Permissions are always a good place to start, keep sniffing around that as well.

Let us know if you get a resolution or other info....

07-27-2007, 02:23 PM

Thanks for the advice. I am definately trying to think outside the box and even attempting to look under the box(hopefully without it crushing my head at some point). Here are the answers to the questions you asked;

1) Another developer can open the exact same projects on his computer and my computer logged in as him and has no problems at all. However if I log into his computer, I get that same error as if i was logged into my computer. So this tells me that this is not computer related as far as the physical local machine itself or even the server where the application resides.

2) the server is 2000 service pack 4 and its not a Novell system/network, strictly all micro$oft

3) I have completely done all of these steps numerous times and it has had no effect on the problem.

4) I checked with our network people and I have the same rights and permissions as the rest of the development team. So permissions shouldnt be the issue?

I might just have to end up calling microsoft about this issue and see what they tell me about it *sigh*

07-27-2007, 05:32 PM
Well I'm not so sure you need to contact microsoft. You have a big clue to the issue in what you stated.
1) Another developer can open the exact same projects on his computer and my computer logged in as him and has no problems at all. However if I log into his computer, I get that same error as if i was logged into my computer. So this tells me that this is not computer related as far as the physical local machine itself or even the server where the application resides.
Since another developer and use you machine with his logon and you have the same errors with your logon on his machine this indicates an issue with the permissions/Configuration of your profile. This is the only thing that remains. There must be some permission or access that is being denied for your logon/profile. You may need to have the IT folks recreate your profile with the correct permission as it may even be a corrupt roaming profile (since I don't know how they have the profiles configured). This is the area I would focus on to see if it can be resolved.

Good luck

07-27-2007, 06:34 PM

I agree that it appears to be a permissions issue. I don't care what your admin says, if nobody but you is having the problem and it happens on more than one machine, it must be an issue with your user account.

07-31-2007, 06:27 AM
I worked with the network admin yesterday, and we discovered that the other developer is now having the same issue when he tries to build a VB.Net application, from his machine or mine. And the network admin has given me administrator rights to the network. As well as deleted my network user account and recreated it. None of these solved the problem. We still think it is a permissions issue, but can not think of what it could be. We have ruled out a flakey network switch, because we put my machine on a totally different part of the network and the problem was still present.

07-31-2007, 10:36 AM
Does this server have the most up to date service packs installed? The problem is we don't have a good repo of the problem. Meaning, there needs to be a level of isolation and targeting to determine the probability of when this occurs, if it occurs 100% of the time if x and y are true, etc.

1) Does any other server have this problem?

2) What are the differences between Server Good and Server nightmare, in relation to configuration, OS, and all aspects

3) So any user account gets the same results ONLY on this server

4) Create a brand new solution, with none of the same shared assemblies, if any exist. I am taking about a WinForm or console application with NOTHING in common with the original source application...they should share nothing besides the default .Net assemblies that come out of the box. Create something that literally has one project in it...deploy and test. Does the same problem occur?

5)Have you tried re-installing the .Net framework on this bad server?

08-02-2007, 10:50 AM
Thanks all for the help. Here is an update.

We found out what might be causing the issue, but we are not sure why. If we copy the project to a 2003 server it works fine. However if we try it from any of our 2000 servers, it gives us these errors. Not sure why this is happening, but atleast we have found a workable solution to the problem

EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum