Unable To Compile Assemblies In VS.NET 2003

This bug in VS.NET 2003 (yes, it is a bug!) has dogged us for two months now. It came out of the blue and has been causing too much inconvenience.

It all began with this error message during compilation:

Cannot copy assembly […] to file […].dll. The process cannot access the file because it is being used by another process.

My instincts where telling me something was holding on to a file handle and not closing it between recompilations. KB 843370 indicated the same, so I guess my instincts were right on the money. Most of the time this failure to compile reared its head after we “got latest” from Visual SourceSafe, just like KB 887818 described it.

The way to deal with a file locked by a rogue process is to shut down the process. Consequently, we had to shut down VS.NET and do iisrest (just in case), then start in again, load our multi-project solution and compile. Aaaaaah, it takes this little, doesn’t it?

We also tried this stunt: change compilation mode from Debug to Release, compile, change back from Release to Debug and compile again. It worked about 50/50.

Luckily, as both mentioned KB articles point out, there’s a fix. According to the new Microsoft Support policy you can’t download fixes any more. You have to call (overseas), insistently explain that you need it, then get redirected to a support person in the US, convince him/her too, and request a link and password by email. I wonder how this works outside of the US where toll-free numbers are not available.

Anyway, being happy owners of this patch, we’ll see if the vicious compilation bug leaves us alone.

Update: I must say Microsoft support folks have been very helpful. They go a long way trying to satisfy you. Every time they called me back and/or sent emails to see if the fix worked. In this sense I have no issues with them.

I recently ran into an ASP.NET bug for which a fix was available only via Microsoft. We were essentially forced to either live with it or pay for support (and the phone call).

However, since it was a common bug, I managed to find a download for the fix on a third-party site. The problem was fixed in 1.1 SP1.

As for the whole VS.NET file locking issue. I get that a bit too. I've noticed that VS.NET and NAnt don't play well together.

If they're both building the same configuration then we get problems. Normally, I'll build Debug in VS.NET and Release in NAnt. If the problem still crops up, a restart of VS.NET normally fixes it.

There's a free program called Process Explorer that can tell you what process has a lock on a particular file. Very useful.

Yep, I use Process Explorer once in a while. The problem was we knew it was devenv.exe locking the file, we just couldn't do much about it. Sometimes only a reboot helped.

We have also run into this bug, and one thing that helped us to at least reduce the number of times it pops up was to first check that everything was using project references (has obj in the file path). Then we made sure everything was building to it's own directory and being coppied to the common directory using post build events. That seemed to drasticly cut down the amount of times this shows up.

The last time I ran into this it was solved for me by turning of the Indexing service in Windows XP. This service was locking down the files and causing the error.

That can cause it too, although we had the list of catalogs stripped to the bone in our Indexing Service.

Since I made these changes ( http://blog.eriklane.com/archive/2004/11/02/191.aspx ) I've not had the issue any more.