We are using a “copy deployment” to update our web server during installation of patches/updates of our software.
The web service is used to generate the reports (stream) as a response to request from the clients. If we have opened any reports before installing new patches (of our system), we get the exception:
System.IO.IOException: The process cannot access the file ‘c:\forrit\h3\server\Web\webservice\bin\cmBR28.dll’ because it is being used by another process.
The only workaround is to restart the IIS and reinstall the patch.
All references to LL are guarded by c# using statements, same with Streams.
We have been using copy deployment to update our web server installation for years without problems, it was only after we started to use List&Label that this came a problem.
PS. we are still using Crystal Report to generate reports on the web server side, and their DLLs are never locked.
Any suggestions?
Might be, but I would rather say not.
Like I said this only occur if we have opened any reports. So it is dependent on that LL reports have been processed on the server. If not, then this lock of DLLs does not happen.
Therefore I say that preloading of libraries and how IIS starts up its app pools doesn’t matter. It will do exactly that also in the case where no reports have been opened.
As I know the pattern of protection job while using List & Label within web applications, a global .NET object exists there which is just loaded (also its native modules like mentioned cmbr28.dll etc.) and it is not used for reporting tasks. And for real reporting tasks always new .NET objects are created - also by using statements which seems perfectly. But the global .NET object (Protection Job) seems to be still loaded in this application and of course locks the native modules all the time. Do you use this pattern? Other try to check which process holds/locks this modules - e.g. with Process Explorer from Microsoft I think. is it perhaps that simple?
No we are not using a global object.
We reply to a “give me that report stream” inside a using () {} statements.
The file is indeed locked by w3wp.exe - but why I still don’t know:
Some more details form the Process Explorer.
After iisreset:
And then after having opened one report on the client:
I am not sure what I can deduct from that.
List & Label also uses native DLLs. Therefore a short reboot is necessary to replace them. The following article describes this case: Using native DLLs from ASP.NET apps — Faithlife Code Blog
With a batch that stops the application pool briefly and starts it again, you can keep the time for this very short.
%systemroot%\system32\inetsrv\appcmd stop apppool /apppool.name: “AppPoolName”
%systemroot%\system32\inetsrv\appcmd start apppool /apppool.name: “AppPoolName”
For a WebDeploy, this should also be possible with the App_offline.htm file. See:
Thanks for the suggestion. I did follow your advice and tested out the solution. I did disable the shadow copy of assembles/dlls. And did put in “offline” file while monitoring Process Explorer.
But I think that there might be problems with the COMBIT package. Taking the website offline only removes part of the DLLs.
This is a snapshot taken just after a client has requested a report:
As I cannot put more than one picture into each post I have to send the snapshot that shows that there are still DLLs loaded in a new Reply 
…
This snapshot show you that many of DLLs are still loaded on the server after taking the website offine:
among them the problem maker cmbr28.dll that causes the deployment error:
System.IO.IOException: The process cannot access the file ‘c:\forrit\h3\server\Web\webservice\bin\cmBR28.dll’ because it is being used by another process.
If I understand your suggestion correctly all LL dlls should have been offloaded. But that does not seams to be the case.
Can you investigate this please?
Best regards,
Arni Jón Reginsson
For our online demo we use a batch to stop and restart the app pools with the appcmd tool. There are several app pools, because several web sites use List & Label. So just stop the app pools, replace the DLLs and start the app pools again.
