[Mono-list] mod_mono and swapping out web application assemblies

[Jim Erwin]

Gonzalo,

Thanks for the reply, and for all of your hard work on mod_mono and all
of your other mono work.

I will look into the ShadowCopy report on bugzilla, and keep an eye out
for the next official release of mod_mono and all related packages so
that I can resolve this and some other issues I'm currently facing. 


I'm assuming that the changes you're talking about will require more
than just a recompilation of mod_mono against mono 1.0 and that there
will be some new packages that will be mono 1.0x that will accompany
these changes.

I have two or three other issues I'm working with at the moment that may
become bug reports, but I'll make sure to search for them on bugzilla
before reporting them.

In the meantime, I'll get a copy of Wilem's shell script for a temporary
partial resolution.

Thanks again,

Jim Erwin

On Tue, 2004-07-13 at 18:31, Gonzalo Paniagua Javier wrote:
> El mar, 13-07-2004 a las 18:23, Jim Erwin escribió:
> > I know mod_mono is a bit behind the core release of mono in terms of
> > maturity, however there is an issue I've come across that I'd like to
> > find a way to resolve, or at least find a best practice to handle it.
> > 
> > If I simply want to change the assemblies in the bin folder of a web
> > application with IIS/Windows from a VS.NET compiled project, I can
> > simply copy over the old ones. At this point, JIT compilation and
> > caching occur as soon as the next page hit occurs without any other need
> > for admin intervention. The same is not true when using mod_mono.
> 
> There are bug reports covering this issue. Search for ShadowCopy in
> bugzilla.
> 
> > 
> > When I simply swap out assemblies with mod_mono, I get errors that the
> > classes can't be found. At this point, the only thing I know to do that
> > works is to run "killall mono" from a root prompt. At this point, the
> > server processes are restarted and on the next page hit, the JIT
> > compilation takes place. All is well. The down side of this as I see it
> > is that this will kill ALL mono applications on the box. So if I'm
> > running multiple web applications, or other non-web mono applications on
> > the server, all of them get killed at this point.
> 
> Last week I did some changes to mod_mono. Now, if you let mod_mono fork
> mod-mono-server when needed, reloading/restarting/stopping apache will
> properly finish it and relaunch when necessary. Killing by hand is not
> needed any more.
> 
> > 
> > A perfect resolution would be to have mod_mono treat new assemblies the
> > same way IIS does on Windows. I'm assuming that this may take quite a
> > bit of work to implement or may never be done. The next option would be
> > to have a utility where you can pass which application needs to be
> > reloaded for a web application and have all of the behavior for that
> > handled in the background. The question is then how to determine which
> > instances of "mono mod-mono-server.exe" are attached to a specific web
> > application.
> > 
> > Thoughts and ideas on how to resolve this would be greatly appreciated.
> 
> Ideally, we would only need to unload the appdomain of the application
> you want to restart (or do it automatically when, for example,
> global.asax is changed) but there are still a few bumps on the road (all
> of them in bugzilla).
> 
> The «easiest» thing to do that would help us with this issues is
> supporting ShadowCopyFiles.
> 
> -Gonzalo
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list