Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Any way to release a report dll without rebooting the server? 1
- Thread starter bigfoot
- Start date
- Thread starter
- #3
I don't give any guaranty for that solution. It may crash your IIS but can work also.
Download ProcessExplorer from that software show you all the process, files & handle in use on your systems. Then from the software search for your file (Search/Find) and close the handle from the handle windows (bottom).
You're manually killing the handle, so IIS might not like it!
Download ProcessExplorer from that software show you all the process, files & handle in use on your systems. Then from the software search for your file (Search/Find) and close the handle from the handle windows (bottom).
You're manually killing the handle, so IIS might not like it!
Oh the nightmare of dll's with IIS. I used to support Web Classes and I have gone as far as to call MS and talk to them for several hours. If the DLL is being called from an asp page the only way that we found was to restart service. Hopefully in the new version of IIS this will be fixed. If you find a way to unload the DLL with out stopping the service, please do post.
Note: We have tried several tools that claim you can stop a dll, which they can IF they are not being used by IIS
Note: We have tried several tools that claim you can stop a dll, which they can IF they are not being used by IIS
-
1
- #7
If you're familiar with MTS/Component Services/COM+ (depending on the windows version it could be called any of those things), you could host the .dll there. Doing that, IIS can still use it, but it runs in Component Services' process and ComSvcs lets you stop running jobs.
All you have to do is create a new package in ComSvcs (on the IIS machine) and drag and drop the .dll to it. This registers it and from then on, any processes instantiating classes from the .dll will do so via ComSvcs. To stop it, you just right-click and "Stop" the package. Once stopped, you should be able to replace the .dll file, and then drag/drop the new .dll into ComSvcs. Stopping the package will only affect web sessions currently accessing the package - nothing else. Much better than bringing down the IIS service or, heaven forbid, the entire server.
This works for me in most circumstances and adds very little overhead (and some great functionality, like db connection caching).
-DGuay
All you have to do is create a new package in ComSvcs (on the IIS machine) and drag and drop the .dll to it. This registers it and from then on, any processes instantiating classes from the .dll will do so via ComSvcs. To stop it, you just right-click and "Stop" the package. Once stopped, you should be able to replace the .dll file, and then drag/drop the new .dll into ComSvcs. Stopping the package will only affect web sessions currently accessing the package - nothing else. Much better than bringing down the IIS service or, heaven forbid, the entire server.
This works for me in most circumstances and adds very little overhead (and some great functionality, like db connection caching).
-DGuay
- Thread starter
- #9
I will be searching the net on anything I can find on how to work with MTS/Component Services/COM+. We are using Windows2000 Server with IIS 5.0.
Thanks for the info musik, and if you can add anything else, please do. This sounds like a step in the right direction. I thought about making a web application in IIS and setting it to highest thread, but it said it was only for development PC's.
Thanks for the info musik, and if you can add anything else, please do. This sounds like a step in the right direction. I thought about making a web application in IIS and setting it to highest thread, but it said it was only for development PC's.
Here's a few more things:
When you compile your dll, you'll have to change a few settings. Any Class that you need to be able to instantiate inside of MTS will have to have its "MTSTransactionMode" property set to a value other than the default "NotAnMTSObject". Since you said it's for reports, "1 - NoTransactions" will likely be adequate. Changing this property on each Class should be the only VB-side change you need to make.
Web side, there should be no changes. MTS handles doing the registry entries that inform W2K to host the .dll in MTS's process.
In Component Services, drill down as follows:
Console Root/Component Services/Computers/(My Computer or the web server name)/COM+ Applications.
Here, you'll need to create a new Application by right-clicking on COM+ Applications. Tell it to create an empty application, name it whatever you like (you won't be using this name anywhere other than here for reference), and make sure Server application is selected (the default). On the next page, you MUST specify a "This user" selection. If an MTS application is set to run as the "Interactive user" - it will only run _when_someone_is_logged_on_to_the_console. This is almost never what you want (except maybe for testing). You should have a domain account that it can run as that exists specifically to be a service account. You may already have one, such as the one used for the SQL service. Otherwise, you should create one. It's considered bad form (and a security hole) to use "Administrator". Whatever account you create, remember that you will have to change the password entry here in ComSvcs if you ever change the account's password! Hit Next and Finish. Now that the "Application" exists, drill down to "Components" and drag and drop the .dll file you created on the right pane. It will automatically register the .dll and set everything up. NB: The .dll must have a local path on the server where it is being installed.
There are ton of options you can set on the .dll once loaded, but it will work as is. Whenever you need to replace it, just navigate to the COM+ Applications folder, right-click on the application you created, and select Shut Down. Now you'll be able to replace the .dll file and drag it in again. (Unless you're doing binary compatibility in VB, you will have to let MTS re-register the component.)
Hope this helps!
Damien Guay
When you compile your dll, you'll have to change a few settings. Any Class that you need to be able to instantiate inside of MTS will have to have its "MTSTransactionMode" property set to a value other than the default "NotAnMTSObject". Since you said it's for reports, "1 - NoTransactions" will likely be adequate. Changing this property on each Class should be the only VB-side change you need to make.
Web side, there should be no changes. MTS handles doing the registry entries that inform W2K to host the .dll in MTS's process.
In Component Services, drill down as follows:
Console Root/Component Services/Computers/(My Computer or the web server name)/COM+ Applications.
Here, you'll need to create a new Application by right-clicking on COM+ Applications. Tell it to create an empty application, name it whatever you like (you won't be using this name anywhere other than here for reference), and make sure Server application is selected (the default). On the next page, you MUST specify a "This user" selection. If an MTS application is set to run as the "Interactive user" - it will only run _when_someone_is_logged_on_to_the_console. This is almost never what you want (except maybe for testing). You should have a domain account that it can run as that exists specifically to be a service account. You may already have one, such as the one used for the SQL service. Otherwise, you should create one. It's considered bad form (and a security hole) to use "Administrator". Whatever account you create, remember that you will have to change the password entry here in ComSvcs if you ever change the account's password! Hit Next and Finish. Now that the "Application" exists, drill down to "Components" and drag and drop the .dll file you created on the right pane. It will automatically register the .dll and set everything up. NB: The .dll must have a local path on the server where it is being installed.
There are ton of options you can set on the .dll once loaded, but it will work as is. Whenever you need to replace it, just navigate to the COM+ Applications folder, right-click on the application you created, and select Shut Down. Now you'll be able to replace the .dll file and drag it in again. (Unless you're doing binary compatibility in VB, you will have to let MTS re-register the component.)
Hope this helps!
Damien Guay
- Thread starter
- #11
Excellent! A more indepth I could not find.
A few questions though.
Do I need to change the way I call the DLL thru the ASP page?
Do I have to unload and reboot the server to get the "old" DLL out of memory, or how will the server know it needs to use the new DLL, and not the old one?
Thank you so much for all the help, and if you can point me in the right direction, I'll go and read everything I can get my hands on.
Gary Parkin
A few questions though.
Do I need to change the way I call the DLL thru the ASP page?
Do I have to unload and reboot the server to get the "old" DLL out of memory, or how will the server know it needs to use the new DLL, and not the old one?
Thank you so much for all the help, and if you can point me in the right direction, I'll go and read everything I can get my hands on.
Gary Parkin
ASP code should be unaffected. Just instantiate the object with Set var = Server.CreateObject("Library.Class"
as usual.
All you have to do to get the "old" DLL out is the "Shut Down" in MTS. Once you replace the .dll file and reload it into MTS, it will load that new one. That's all there is to it. That's the glory of hosting in MTS - there is no chance of there being a "stray" instance of the .dll running somewhere else. Once registered with MTS as their InProcessServer, they won't run anywhere else.
-DGuay
as usual.All you have to do to get the "old" DLL out is the "Shut Down" in MTS. Once you replace the .dll file and reload it into MTS, it will load that new one. That's all there is to it. That's the glory of hosting in MTS - there is no chance of there being a "stray" instance of the .dll running somewhere else. Once registered with MTS as their InProcessServer, they won't run anywhere else.
-DGuay
- Thread starter
- #13
Nice job musik,
As an administrator I want to add a few things to this.
First all developers should follow musik's advice and always try to run web application dlls in COM+. Seeing that lazy programmers do not do this, and force administrators to come in and fix their mess, here are a few tips for those unlucky administrators (like me) who have to clean up this mess without stopping web services.
If you go to Task Manager and look at it while your web application is in use, it will show up as dllhost.exe. To verify, in Task Manager go to View | Select Columns | and choose User Name. The username will be IWAM_MachineName next to the DLLhost.exe process.
What we do to kill these rogue applications while services are up is simple, If you run all COM+ applications under their own Domain Account specific to the application (which you should be doing for Security purposes anyway), only web applications not running in COM+ will show up under IWAM dllhost.exe in Task Manager. You can even go further detailed using Process Explorer utilities to determine exactly which dllhost.exe is which if you have multiple applications running out of COM+ on the same server.
In the end though, once you have determined exactly what process is your rogue application, you can use Kill.exe (available in the Resource Kit or online at to kill that individual process.
It is brute force and dirty, but it is the way to get rid of problems without having to restart services. In the end though, force your deverloper to follow musik's advice and in the long run, both your server and that application will be more stable (and more secure).
Galrahn
galrahn@galrahn.com
As an administrator I want to add a few things to this.
First all developers should follow musik's advice and always try to run web application dlls in COM+. Seeing that lazy programmers do not do this, and force administrators to come in and fix their mess, here are a few tips for those unlucky administrators (like me) who have to clean up this mess without stopping web services.
If you go to Task Manager and look at it while your web application is in use, it will show up as dllhost.exe. To verify, in Task Manager go to View | Select Columns | and choose User Name. The username will be IWAM_MachineName next to the DLLhost.exe process.
What we do to kill these rogue applications while services are up is simple, If you run all COM+ applications under their own Domain Account specific to the application (which you should be doing for Security purposes anyway), only web applications not running in COM+ will show up under IWAM dllhost.exe in Task Manager. You can even go further detailed using Process Explorer utilities to determine exactly which dllhost.exe is which if you have multiple applications running out of COM+ on the same server.
In the end though, once you have determined exactly what process is your rogue application, you can use Kill.exe (available in the Resource Kit or online at to kill that individual process.
It is brute force and dirty, but it is the way to get rid of problems without having to restart services. In the end though, force your deverloper to follow musik's advice and in the long run, both your server and that application will be more stable (and more secure).
Galrahn
galrahn@galrahn.com
- Thread starter
- #16
Thanks Galrahn, & musik for all the help. I am a developer and the Administrator.
It is for lack of knowledge that I built the dll's this way. If either of you can point me in the correct direction (in more detail), I would be greatfull. And I will re-do the few dll's I have floating out there, and put them into services. Do I want a new service for each dll(report)?
And New Jersey will be a safer place for dll's
It is for lack of knowledge that I built the dll's this way. If either of you can point me in the correct direction (in more detail), I would be greatfull. And I will re-do the few dll's I have floating out there, and put them into services. Do I want a new service for each dll(report)?
And New Jersey will be a safer place for dll's
- Thread starter
- #17
- Thread starter
- #18
- Thread starter
- #19
OK, now it works but one of my dll's return a recordset back to the web page. I need to sort it in the dll, but no matter how I sort it, it still comes out ascending. When in development, it works DESC, but then when I put it into Component Services, it sorts ASC. The recordset is created in the dll, and passed back to the web page. I'm using FSO to return a folder's contents.
Help please
Help please
- Status
Similar threads
- Question
- Locked
- Question
- Locked
- Question
