views:

282

answers:

6

Hypothetical situation: let's say I have a 3rd party .net assembly being used in the ASP.Net web system that I'm working on that just kinda crashes every now and then. When it does so, all calls to it throw exceptions until the system is rebooted. This is, obviously, a little sub-optimal.

Is there a way to reboot just that assembly from the exception handler?

(Addendum: of course, the correct answer here is to get the vendor to fix their bug. However, the vendor in question is somewhat... "reluctant" to answer our emails. So, this reboot the assembly idea came about this morning as a MacGyver-eqsue piece of duct-tape. And then we realized none of us knew how to do it.)

+2  A: 

Hypothetically... go back to your 3rd party vendor and get them to fix their bug.

BoltBait
This is, of course, the correct answer. This is our attempt to slap some duct-tape on the problem while we try to convince the vendor it really is their problem.
Electrons_Ahoy
Have you considered the possibility that you may not be using the 3rd party assembly properly? Perhaps you are not releasing a resource, memory, or sql connection after use... I'd, seriously, check there first before doing anything drastic.
BoltBait
The short answer is yeah, we've been considering that quite a bit. It's a old-skool COM dll with a (poor) .net wrapper stapled on, and the thing leaks memory all over the place. We're pretty sure we've solved every resource problem we can at this point, and it works *better*, just not *right.*
Electrons_Ahoy
+4  A: 

you can recycle the app pool, but this will kick off all current users and lose their session info - which may not matter if the site is hosed already by the bad dll anyway

Steven A. Lowe
This is better than programmatically changing web.config, in my mind.
John Rudy
+4  A: 

OK, real answer... When the Web.Config file changes, the app gets recompiled and the app pool gets reset.

So, (and I hate to say this) programmatically change your web.config file.

BTW, I don't recommend doing this, so you can save your down vote for someone else.

BoltBait
+1 for living on the edge.
MusiGenesis
All things are excusable when it comes to crappy third party stuff. The real mistake was opting to use it in the first place - once that mistake has been made, you do what you have to do.
MusiGenesis
Drastic situations call for drastic measures!
BoltBait
That is exactly the kind of crazy answer I was looking for. +1 for sure. And yes, for the record this is a 3rd party component we're using over my protests (but, I'm naturally tasked with fixing the problems.)
Electrons_Ahoy
Rystal Creports? - I know you can't say.
MusiGenesis
A: 

It may be that when it crashes weirdly it still leaves an active process alive that hoses any subsequent attempts to call the DLL. If so, you may be able to find it programatically and kill it, which may fix the problem that was requiring a reboot.

MusiGenesis
+6  A: 

Calling HttpRuntime.UnloadAppDomain() will force the application to terminate itself and restart when the next web request arrives. This results in everything being reloaded from scratch and should eliminate the corrupted assembly data.

Granted, this will kill any active sessions, but if the application is essentially crashed anyway this is probably acceptable.

Eric Rosenberger
+1 as it is WAAAAY better than my solution. I didn't know this existed. I just hope I never need it. :)
BoltBait
+1 i like this best
Steven A. Lowe
A: 

Apart from modifying the web.config you can create an arbitrary file in your bin folder. This would restart your application.

korchev