Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

XSL script block dynamic compilation and loading assemblies

22 views
Skip to first unread message

Greg Nagel

unread,
Oct 2, 2006, 10:27:15 AM10/2/06
to
Hi All

I've been experiencing OutOfMemory errors on our prodution webserver for a
few weeks now. I've finally managed to isolate (I think) the problem to our
use of c# script blocks in our xsl files.

While debugging I discovered that the app domain for one of our sites had
13000+ assemblies loaded. I did some digging and it seems that this is as a
result of the xsl user functions being compiled and loaded into memory and
never being unloaded. Unfortunately this happens on our home page which
needs 5 transforms for differing pieces of functionalities.

This is a documented problem: http://support.microsoft.com/kb/316775/en-us.

I've just read this article
(http://blogs.msdn.com/xmlteam/articles/Introducing_XslCompiledTransform.aspx)
over at the xml teams blog and from what I can see this behaviour doesn't
seem to have changed (look under the heading "Cleanup: TemporaryFiles
Property") in .Net 2 (we haven't migrated over to 2 yet, we're still on
1.1).

I've always known that user functions were compiled on the fly into
assemblies. But I never thought the assemblies would be recompiled and
reloaded into memory every time.

Have I made a fundamental design error here? I never heard of this problem,
but it would seem it's never safe to use xsl user functions in a "long
running" app e.g. a web application or service.

I've just read up about ExtensionObjects, should I be using those instead?

Thanks
Greg


Oleg Tkachenko [MVP]

unread,
Oct 3, 2006, 12:57:59 PM10/3/06
to
Greg Nagel wrote:
> Hi All
>
> I've been experiencing OutOfMemory errors on our prodution webserver for a
> few weeks now. I've finally managed to isolate (I think) the problem to our
> use of c# script blocks in our xsl files.
>
> While debugging I discovered that the app domain for one of our sites had
> 13000+ assemblies loaded. I did some digging and it seems that this is as a
> result of the xsl user functions being compiled and loaded into memory and
> never being unloaded. Unfortunately this happens on our home page which
> needs 5 transforms for differing pieces of functionalities.
>
> This is a documented problem: http://support.microsoft.com/kb/316775/en-us.
>
> I've just read this article
> (http://blogs.msdn.com/xmlteam/articles/Introducing_XslCompiledTransform.aspx)
> over at the xml teams blog and from what I can see this behaviour doesn't
> seem to have changed (look under the heading "Cleanup: TemporaryFiles
> Property") in .Net 2 (we haven't migrated over to 2 yet, we're still on
> 1.1).
>
> I've always known that user functions were compiled on the fly into
> assemblies. But I never thought the assemblies would be recompiled and
> reloaded into memory every time.


They are recompiled each time you reload stylesheet (which is also
something you should avoid).

> Have I made a fundamental design error here? I never heard of this problem,
> but it would seem it's never safe to use xsl user functions in a "long
> running" app e.g. a web application or service.

> I've just read up about ExtensionObjects, should I be using those instead?

Yes, just switch to extension objects.

--
Oleg Tkachenko [XML MVP, MCPD]
http://blog.tkachenko.com | http://www.XmlLab.Net | http://www.XLinq.Net

Greg Nagel

unread,
Oct 5, 2006, 7:36:09 AM10/5/06
to
Thanks. Switching to extension objects has fixed the problem. Will
definately be using this in the future.

"Oleg Tkachenko [MVP]" <so...@body.com> wrote in message
news:O53zA0w5...@TK2MSFTNGP04.phx.gbl...

0 new messages