views:

925

answers:

1

I get this error in Visual Studio 2008 when developing a ASP.NET Web Application Project.

Unable to load referenced library 'Path-to-DotNetNuke\bin\file.dll': The process cannot access the file because it is being used by another process.

This is a DotNetNuke project with multiple modules. IIS loads all assemblies from /bin folder under the application root.

The projects in the solution are in their respective /DesktopModules/ProjectName folders and compile to a bin folder under the project.

The error occurs after I compile the solution and copy all the projects' dlls to the /bin with a script. Visual Studio does not let me recompile, but if I restart it, everything works ok. This is really annoying when recompiling and testing the whole solution. You have to restart Visual Studio between every recompile.

I couldn't find any file locks with Process Explorer when Visual Studio shows this error.


[UPDATE] There is an old MSDN document that tells you not to build all DLLs to a single folder if you reference any over 64KB DLL there. Particulartly, the document says:

It causes the build process to fail with file lock errors when a referenced assembly exceeds 64 KB in size.

We do have references to over 64KB DLLs in /bin folder and copying recompiled DLLs there seems to trigger this, at least with VB IDE's background compiler.

+1  A: 

The error occurs after I compile the solution and copy all the projects' dlls to the /bin with a script. Visual Studio does not let me recompile, but if I restart it, everything works ok.

I would suggest setting the output directory of each of your projects to be the bin directory of the DotNetNuke website. This will help you to avoid the manual step of copying files altogether.

To set the output directory of your project: Right click on your project in Solution Explorer and select properties. Select the build tab, select All Configurations (at the top) and set Output Path to "..\..\bin" (near the bottom). This assumes your project file is in it's typical spot within the module's home directory (e.g. DesktopModules/YourModule/YourProject.csproj) otherwise you can navigate to your web site's bin directory with the adjacent browse button.

Ian Robinson
Do you know if this is still current?http://weblogs.asp.net/bsimser/archive/2005/05/25/408850.aspxhttp://msdn.microsoft.com/en-us/library/ms998223.aspxI think it explains the problem.
mika
Setting up DNN modules in this manner is not only common, its somewhat of a 'best practice'. I have not experienced the issues you speak of in the last three years of developing DNN modules.
Ian Robinson
I believe those articles only apply up to VS .NET 2003, and I, along with @irobinson, have never seen those symptoms in VS2005 or VS2008.
bdukes