I get the same problem when building in studio and have noticed a few "quicker" work arounds. I generally run between 4-6 web projects and 2 class library projects in the same solution referencing each other. At least for me, when it indicates the file is in use and wont compile, the file really is not in use nor does VS.NET have a file lock on it. Just go to the .dll file in the bin folder it's complaining about and delete it and re-compile. I think I only had to close studio twice when I have recieved the error. Another thing I noticed is that I don't remember receiving these errors until I started using XP Pro. When using Win2K server as my dev machine, I don't recall getting these errors. It's possible that my project/solution configuration has changed since then enough to now get the errors. One other thing, ocassionally the indexing service can have a lock on your dll's temporarily and it may not be studio that is causing the problem. You assume it's studio, close it as usual, start it back up and everything works fine. By that time, the indexing service has released the lock. You may want to stop the service if it is running and see if this reduces the number of times your dll's are locked.
-Chad On Wed, 30 Oct 2002 13:49:34 -0800, Dave Adair <[EMAIL PROTECTED]> wrote: >WHEN is Microsoft going to fix the problem with VS.NET where it cannot >build the solution because it is locking DLLs that are >64k in size? This >has been a problem since day one and I have wasted DAYS of time over the >last 12 months battling this. I can't even work on one of the subprojects >because everytime I make a change and compile it, it fails because the DLL >is locked and I have to exit VS.NET, delete the project's bin and obj >folders and reload VS.NET. Another way that the problem manifests itself >is that the subproject will build fine but another subproject that >references that subproject will not build saying something like it can't >find the type of namespace in that project. > >(YES, all references to the project in question are Project references, not >File references - which, according the Microsoft, should make it work fine) > >Surely a hell of a lot of people out there are running into this problem... >or is no one out besides me and a few others foolish enough to try a large- >scale .NET project yet? > >Sorry for the ranting and raving but I have completely lost my patience >with this. > >You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
