Jelle Druyts

I was having some trouble the other day with our Team Build server when building a project that is used by an open Visual Studio instance.

Our setup is that we build our enterprise framework on the build server and then copy it to a public share so it can be used by the client projects. Now when somebody is actively developing a project in Visual Studio that uses this enterprise framework, we receive something like the following error in the build log when building the framework:

Copying drop to final destination
Copying folder "\\BuildServer\Drop\Framework_20060530.2\Release" to "D:\PublicShare\References\EnterpriseFramework\Latest".
D:\Build\Team\EnterpriseFramework\BuildType\TFSBuild.proj(168,5): error : A task error has occured.
D:\Build\Team\EnterpriseFramework\BuildType\TFSBuild.proj(168,5): error : Message = Access to the path 'D:\PublicShare\References\EnterpriseFramework\Latest\EnterpriseFramework.Common.xml' is denied.

So the open Visual Studio instance on the developer's pc seems to keep a lock on the XML file (for IntelliSense) on the build server, causing the build to fail. Now I don't think it's very nice of Visual Studio that it locks the file, but apparently that's the way it is.

So here is the unclean (you won't catch me calling anything I do 'dirty' of course) workaround I used to get rid of this sticky problem. In the build script, right before copying the files to the public share, I execute the following task:

<Exec Command="net session /delete /y" />

This simply forces a delete of all connected client sessions, closing all the handles of the files that are opened remotely. Problem solved - as long as we don't have the race condition where somebody would lock another XML file just between that command and the actual copy, but what are the odds... The only minor side effect is that the opened Visual Studio instance loses IntelliSense for some of the files it had locked, but we can live with that. At least it's better than breaking the build, right?