Could not write to output file ...it is being used by another process

[Mountain Bikn' Guy]

I am having serious problems with the following IDE bug:
Could not write to output file 'x.dll' -- 'The process cannot access the
file because it is being used by another process. '

and

BUG: "Could Not Copy Temporary Files to the Output Directory" Error Message
When You Build a Solution That Contains Multiple Projects

I have tried all the solutions in Microsoft Knowledge Base Article - 313512.
They have not solved the problem for me. I have had these problems in VS.NET
2003 and VS.NET 2003 for more than a year. They happen on a project that has
several large assemblies and several levels of project dependencies.

My problem is very much like what was described in the folllowing post. Any
help is GREATLY appreciated!
Dave

From: Simon Weaver ([email protected])
Subject: still problems with Could not copy temporary files to the output
directory


View this article only
Newsgroups: microsoft.public.dotnet.languages.csharp
Date: 2002-12-11 11:45:46 PST

There appears to be a problem with DLLs > 64KB and i get errors like :

"Unexpected error writing metadata to file 'C:\Documents and
Settings\Simon.SIMON_DEV\My Documents\Visual Studio
Projects\XXX\BusinessCS\obj\Debug\BusinessCS.dll' -- 'Access is denied. '"

and

Could not write to output file 'C:\Documents and Settings\Simon.SIMON_DEV\My
Documents\Visual Studio Projects\ITD
Database\BusinessCS\obj\Debug\BusinessCS.dll' -- 'The process cannot access
the file because it is being used by another process. '

and more commonly

Could not copy assembly to output directory.... The file is being used by
another process.

This is a known problem. In the ASP.NET world it has something to do with
leading slashes on directory names.
I am using windows forms so this does not apply.

One of my core DLLS has just passed the 64kb barrier, and now this problem
has become so severe I cannot even continue working.

I do not have all my DLLs going to the same output path, which some people
says was the problem. All the DLLs go to different directories, but I have
the CopyLocal option enabled so effectively they do all end up in the same
directory.

I have a VB project referencing a C# project, both of which are > 64kb. The
problem seems to be more evident with cross language references, but I dont
see why.

 

[Grant Richins [MS]]

You also need to make sure the class browser is closed. It will keep open
and lock output files.

 

[Mountain Bikn' Guy]

Yes, I've read that too. There seems to be something else going on that is
not mentioned in any of the KB articles so far. I suspect it is related to
large assemblies together with more levels of dependencies (but I'm not
sure).
Dave

 

[Christian Boult]

One other problem I have found is concerning inherited forms.
If you have an inherited form and it's in an other project that is in
referenced it loads the dll from the obj directory, instead of the
temporary folder where you will see other dll's loaded from, while compiling
and then you are screwed...

Just start up a debugger session on devenv.exe then compile and you will see
the assemblies that are loaded and if any assemblies are loaded from the
obj directory forget it. Restart VS.

This was such a problem that we changed the way we worked. Split up projects
in multiple Solutions (so we have about 10 projects per Solution). We have a
common directory where all files from the builds are copied and we have
assembly references (to the assemblies in other solutions) in the projects
instead of project references. We built a tool that does all the compiling
and copying and running and attaching to a debugger. Ever since never had a
cannot copy file and life is good.

Chris.

 

[Mountain Bikn' Guy]

Wow! Thanks for the feedback. I think you have identified the cause of the
issue that I've been struggling with!

Now all I need is a custom tool like you have for compiling and debugging
the multiple solutions as one...

I hope MS takes note of this issue and provides some assistance. This
problem has existed in VS.NET in both 2002 and 2003 versions. Somehow it
seems MS doesn't understand the problem (or even that there is a problem
beyond the scope of Knowledge Base Article 313512) -- but you guys have
identified it and fixed it. Maybe your company could bring it to their
attention.

And maybe you should sell your custom tool to people like me...

Regards,
Dave