Brian Scott

I hadn't run into this yet, but I was hoping it would have been fixed in VS2005.

its not antivirus, desktop indexing, custom defrag tool, or anything like that that could be locking it?

No, the dll is being loaded into the Visual Studio process during a build. Using SysInternals Process Explorer I can see it happening. Sometimes it is unloaded after the build, but once it is held on to, it starts happening every first build after a restart.

Desktop indexing is turned off, I don't use a custom defrag tool, and I turned antivirus off when the problem started. It also happens on two different machines. My desktop and my laptop.

I seem to have the same problem, but with an ASP.NET project. It gets pretty irritating having to restart VS2005 every so often. I read somewhere that apparently this could be caused by the Win XP indexing service locking the assemblies, and that the solution is to go to your source folder then right click->properties->advanced and disable indexing. I'm trying it now, have yet to see if it works though, but I'm sure I'll find out shortly.

I've experienced this once or twice but it goes away after I restart the IDE. If VS only had an open handle I could have used Process Explorer to close jsut the handle but because it is a loaded DLL module I can't.

I know what you mean :(
Every time i work with my custom controls part of the project i have to close and reopen the solution at every two builds. The exact same way as you.
Hope microsoft gets this fixed. It's so annoying.

I was getting the same problem (which is what brought me here), and I tried all the suggestions I could find on the web. The most popular suggestion was to make sure all assemblies compiled into their own project folder. This didn't work for me unfortunately.

I have eliminated the problem, but not really identified the cause (usually a cue for the problem to reappear). A custom form component of mine has a property that is a custom class with it's own customized serialization. This means that the designer initializes the component from the resource file (the object has been automatically serialized to the .resx version of the resouce file). If I delete the .resx entry for this object and remove the setting of the property (in the designer.cs file), the problem goes away.

My suspicion is that their is a flaw in my serialization code, and that it falls over during the compilation step. However, the compiler (or linker or something) doesn't handle the failure gracefully and the DLL gets stuck in memory thus locking the assembly on the disk. It is also popular that the resouce translation step is inherently buggy for custom classes - either way the compiler is at fault.

If you have any custom attributes or any entries in the .resx file, try removing them.

I've seen the same problem on VS 2003.Net. I closed the solution but left VS open and it still had the DLLs locked. SysInternals Process Explorer should this.

I have the same problem when developing a CAB application. It seems to happen if I build the solution (or project ... maybe?) with a designer window open. If I close down all the designer windows before building I do not get the problem ... big pain though, as I constantly forget to close the designer windows!!