We deploy twice a day to 24 front end web servers. We are sometimes seeing an issue when copying assemblies into the bin folder under our application. We think that the new assemblies are trying to be read before they have had a chance to be written to disk completely.
There are a few posts/blogs on the web with people having similar issues. Two workarounds I have read include the following,
Idea 1
You can take an AppDomain offline by simply placing a file called app_offline.htm into the root directory of the application. Once its offline all locks on files are released and this would allow them to be updated. After the file app_offline.htm is removed or renamed, the next time a request hits the app the appdomain is spun up again. The caveats with this are that it only works for ASP.NET content and requires some downtime.
Idea 2
Keep the assemblies unlikely to change in bin and put ones that will change regularly into a sub-folder of bin and name the folder according to the date and time of deploy (eg: bin\20090517-1400). Setup the web.config with the following,
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin\20090517-1400;" />
</assemblyBinding>
</runtime>
To update assemblies, upload them into a new sub-folder in bin with a name corresponding to the current date (bin\20090518-1555). After the upload is complete, upload the web.config with a change to the sub-folder name. The app re-starts and picks up the new assemblies and forgets about the old sub-folder assemblies which can be left or deleted. Apparently this works and has the added benefit of speeding up the app start since the sub-folder assemblies are ignored until needed.
So the question is...what is the best practice and supported method from Microsoft for achieving what we need? Is it one of the methods above or is there a better way?