VS .NET 2003 is locking files

[Mountain Bikn' Guy]

I am having the problem described by many people and also discussed in the
Microsoft Knowledge Base Article - 313512. The solutions mentioned in that
article do not solve my problem, or apparently, the problems of many other
people using VS.NET.

I have several projects that produce DLLs > 64k and I also have several
levels of dependencies (as I would suspect should be a common situation in
well-designed modular projects). I have seen many posts from people with
similar problems, but I have not seen a solution that cures them.

Does anyone have a real solution? Or should we switch to Borland C# Builder?
Dave

For references to the prior threads, see:

From: Nikolai Sander (nikolai.sander@discreet_nospam_.com)
Subject: Re: VS .NET 2003 is locking files

View this article only
Newsgroups: microsoft.public.vstudio.general
Date: 2003-06-02 14:01:49 PST

>If this is a bug confirmed by Microsoft, when can we expect a fix ??

Yes. http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q313512

NikolaiFrom: Simon Weaver (fl...@simonweaver.com)
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.

What can I do about this? Is it fixed in Everett?

[Miha Markic]

> Does anyone have a real solution? Or should we switch to Borland C#
Builder?

Believe me, restarting VS.NET is way less pain :)

Miha

[Mountain Bikn' Guy]

Well, I'll have to take your word for that -- but the file locking problem
can be REALLY painful when it happens every 2nd build. VS.NET is a nice
app, but I sure wish I could find a solution for the file locking problem.
Dave

"Miha Markic" <ms...@spin.si> wrote in message
news:%23mi08DP...@TK2MSFTNGP11.phx.gbl...

[Alvin Bruney]

what is the error you get?
"Mountain Bikn' Guy" <v...@attbi.com> wrote in message
news:9gYgb.524796$cF.189094@rwcrnsc53...

[Miha Markic]

Hi,

Do you use assemblies with CopyLocal = true?

Miha

"Mountain Bikn' Guy" <v...@attbi.com> wrote in message
news:9gYgb.524796$cF.189094@rwcrnsc53...

[Mountain Bikn' Guy]

Hi Miha,
I've read all the articles such as Microsoft Knowledge Base Article - 313512
where the discussion of local copies is made. My contention has been that
there is some problem/bug that goes beyond the scope of the KB articles and
the other proposed solutions. I've tried all those solutions and they don't
solve the problem -- so I know something else is going on. I think I just
discovered what that "something else" is. On another group
(MS.public.vsnet.ide 10/9/03), I received the following reply from Chris. I
believe this is exactly the problem I'm experiencing (although I can' t
easily implment his solution to test it). Here is Chris's reply below:

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.

"Miha Markic" <ms...@spin.si> wrote in message

news:%23daX96i...@TK2MSFTNGP10.phx.gbl...