Visual Studio and locked Assemblies

A customer called with with a
very curious problem he was having with Visual Studio and compiling and
deploying a project.  Here are the details.

While restructuring a Visual Studio 2003 project, consisting of one
ASP.Net CS project and two dependent assembly's projects containing
Business Logic and Object models ,
error was counted when recompiling, indicating
that Visual Studio was unable to copy the dependent assembly's temporary
DLL into the output location in the web project (.\bin). 

The only way to compile these projects correctly was to shutdown Visual
Studio batch compile and then reopen Visual Studio

After a lot of analysis it was
discovered that the 
AssemblyInfo.cs files in the dependent projects
where accidentally deleted
corrupted, resulting in
the the DLLS associated with those dependent projects being locked by
Visual Studio. 

The only way to compile these projects correctly was to shutdown Visual
Studio batch compile and then reopen Visual Studio

The problem was resolved by:

  • Creating
    a new ASP.NET project and creating a new Virtual Directory on
    the IIS server.
  • Creating new
    class projects for each of the dependent class
  • Copying the old
    project's C# source code and resource files into the dependent projects,
    excluding the AssemblyInfo.cs file for each project.
  • Copying the old
    project's ASPX etc source file along with their associated C# class and
    resource files.
  • Copying
    the old project's Global.asa source file and its associated C# class
    file over the Visual Studio generated Global.asa
  • Copying the old
    project's web.config file over the Visual Studio generate web.config
  • Compiling the new

Since following this process there has not been any
recurrence of the experience DLL locking problem.

Many thanks to Ross Anderson
from for writting up the issue
and what he did to solve it.  Thanks you...

Comments (2)

  1. Sean Malloy says:


    I had the same problem with a couple of projects I worked on.

    I discovered that there is actually a bug in Visual Studio, where if you change the output folder for a project, to the same folder as another project (IE: modifying two seperate projects to place build output in C:ProjectNameOutputDebug, rather than leaving them as default ProjectNamebinDebug), then Visual Studio woul dhave problems with locked DLL’s.

    A mjaor pain, but solved by making sure each project places output into its own folder.

    I can’t remember the ms knowledge base article, but thats where I found the answer.

  2. Dave Glover says:

    Cheers and thanks Sean…

Skip to main content