Dynamics CRM 2011 on premise.
I have a registered plugin DLL that is called when the case/incident entity is created.
An exception is raised when this happens. I am investigating this.
The plugin is on disk (C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly) and I have to update it manually when I want to change the code. (This situation was created before me and I won't change it now.)
Whenever the exception is raised, the DLL becomes locked and the only way I can find to overwrite it is to restart IIS.
How can I unlock the file without restarting IIS?
Responses to answers
Which application pool?
None of the pools list the location of the DLL in this list:
The DLL is in C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
Recycle the App pool. When you recycle the app pool, it'll start up a new one right away, and let the old one finish up, eventually killing any threads that don't finish in a configured amount of time. That should allow you to not have to kill all of ISS. Just make sure you wait long enough for the w3wp worker process to die.
Just rename the dll which is currently in use and dump the new new dll there. It worked for me.
Related
I'm currently in the process of migrating an ASP platform from Windows 2003 R2 IIS 6 web servers to Windows 2012 R2 IIS 8.5 web servers. I'm at the stage where I've migrated a number of sites across to two separate 2012 web servers, all looked great, clients and developers are happy... However the following error has presented itself after a few days hosting on one of the new servers.
Active Server Pages error 'ASP 0223'
TypeLib Not Found
/jobboard/conf/constants.vbs.inc, line 1
METADATA tag contains a Type Library specification that does not match any Registry entry.
The METADATA tag is below:
<!--METADATA TYPE="typelib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"-->
Restarting IIS on this server resolved the issue (albeit temporarily).
Subsequently the other 2012 web server in production presented the same error a couple of days later, again, restarted IIS and works for now.
I've checked the registry and the relevant tag exists with the right UUID and correct permissions.
It doesn't affect all sites on the server, only all sites in a particular application pool.
The application pools use a domain user identity and sites are split up into a number of shared pools.
I've now determined what was causing the above problem...
Our sites on IIS run in a number of shared application pools running as a domain user. We also have a Windows scheduler job which runs a number of scripts over night which also run as the same domain user.
It seems there are cases when this scheduler job runs it interferes with the IIS worker processes. When it completes and ends its user session it unloads the registry file in memory, which the w3wp.exe processes could also using.
This error is presented in the Event log...
Windows detected your registry file is still in use by other
applications or services. The file will be unloaded now. The
applications or services that hold your registry file may not function
properly afterwards. No user action is required.
Along with references to the w3wp.exe processes currently running.
It was replicated when I terminal serviced in as the domain user and logged out again after a period of time. The event log presented the error and the sites all bombed shortly afterwards.
Running the scheduled job as a different user has fixed this issue for us.
I remember having an include file for ADOVBS.inc with all the ADO constants inside and including it as a standard ASP include inside my global include file which is included on every page on the site.
This was before I used the META way of including the file.
So maybe a last resort is to revert to that method of loading in the ADO constants.
It seems like some sort of threshold is being hit, CPU/Memory?, which then prevents IIS caching/loading the file in from the registry. This then causes the error and a recycle of the pool. As no redirect is being done to the 500.100.asp error handler page which hides the error details from the user. It would suggest the error is in IIS and related to the server.
Thanks
What is causing these frustrating errors during every Visual Studio build operation?
Could not copy "obj\Debug\mywebapp.dll" to "bin\mywebapp.dll".
Exceeded retry count of 10. Failed. Unable to copy file
"obj\Debug\mywebapp.dll" to "bin\mywebapp.dll". The process cannot
access the file 'bin\mywebapp.dll' because it is being used by another
process.
I'm fairly certain that w3wp.exe is locking the file, because the error stops if I restart or shut down IIS from IIS manager. ProcessExplorer shows that w3wp and visual studio are the only processes with locks on the file. Obviously IIS is the issue, because the compilation succeeds when IIS is restarted.
I am using dynamic assemblies loaded into a child application domain. Could those be referencing the file? I tried added an event handler to the Global.asax application_end event to ensure the child app domain is unloaded, but the handler never runs. Also, the debugger's "modules" window shows various modules, but the AppDomain field is always blank, so I cannot even determine if that might be an issue.
Make sure that you've set up your web application within Visual Studio to use Local IIS for debugging:
I kept getting the exact same error. I deleted my old Web Application/Web Site from IIS and created a brand new one with a different name (not sure if you have to have a different name but that worked for me). Now it all works great!
I need to replace one dll-file in deployed azure worker role to one that I modified, because role contains a bug and I don't have a release tag. I'm trying to do that via rdp, but when I'm trying to copy new dll into approot folder VM tells me that old dll file is open in another program and can't be replayced.
This isn't a good idea. You should do this by repackaging the deployment and performing an update. By attempting to do this via RDP you may replace the file, but if the role goes down or gets moved then when Windows Azure bring the role back up the change will be gone since it will redeploy the last package it knew about, so you'd be back to the dll with the bug in it.
As for why it is telling you it is open is because the worker role is actively using it most likely. You'd have to stop the worker role process to be able to replace it. The best option is still to perform an update of the whole package.
You can see this documentation for more information about how the updates occur: http://msdn.microsoft.com/en-us/library/windowsazure/hh472157.aspx
I agree with MikeWo's suggestion about repackaging and updating the deployment.
However, if you want to drop the single DLL and check to see if fix works. you can kill WaWorkerHost.exe - the blue highlighted process in the picture. then you can replace the DLL.
Does the worker process restart if I replace a Dll on my website on IIS 7.5
For example while deploying my application I just copy paste stuff and do not restart the website or stop it would be worker process restart for the App Pool under
If you could actually replace the DLL, it means it was not loaded by the worker process at the time (or else, the .dll file would be locked). Seeing as it hasn't been used yet, the worker process will not restart - it will just load the new .dll file if/when it's needed.
However, I do not recommend "warm" upgrades like these since it leaves you in an undetermined state.
Yes, it does.
The process worker will restart for several other reasons also:
Web.config modification
Changing or adding any file to the /bin directory
It´s recommended that you stop the application pool and your web site, make any change, and then start it again, so you don't have weird behaviour on your app.
I'm trying to re-install a DLL in the GAC, everything seems to work fine but the web application accessing it still seems to be using the old one.
The old DLL is the same version as the new one with only a minor edit, it will be used by 50 different sites so changing the version then changing the reference in the web.config is not a good solution.
Restarting the IIS server or the worker process isn't an option as there are already 50 sites running that must continue to do so.
does anyone know what i'm doing wrong or what i can do to remedy this situation?
AFAIK, you need to restart IIS for it to get a fresh reference to the updated DLL. Your best bet is to perform the reset at a low traffic time. If you are running multiple servers with load balancing, you can prevent new connections from hitting one server until all connections have been closed. Afterwards, update the DLL, restart IIS, and bring the server back into the connection pool. Repeat for each server with no visible downtime to the end users.
Since you don't make a reference to application pools, I'm going to assume you are on the old version of IIS. In that case, what you'll need to do is to "touch" all the DLLs in each site that references the DLL.
The problem is that the code is already loaded and you need to find a non-intrusive way to re-load the application. Recycling app-pools is an effective way to do this. If you are on the old IIS that doesn't have app-pools, then updating the last-modified in the /bin/ folders or web.config files will reload the application without affecting the other sites.
So a script of some kind to do the above is in order. All it needs to do is update the lastmodified on the DLLs in every /bin application directory.