By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,711 Members | 1,123 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,711 IT Pros & Developers. It's quick & easy.

Resource Leak from XslCompiledTransform

P: n/a

Hello there,

Are there anybody who is using the XslCompiledTransform that comes
with .net framework, which was said to be a replacement of the
XslTransform class?

I found that the class has some issues when the xsl file contains scripts.

The XslCompiledTransform uses the CodeDom to compile the scripts
within the xsl file into .net assembly and load them into the current
AppDomain. Some temporary files would be generated during the
compilation in the temp folder.

This behavior leads to two issues.

1, The memory consumption of the current AppDomain, i.e. the
working application keeps growing up if we compile more and more
xsl files that contain scripts. We have no way to identify the assembly
generated from the compiled scripts within the xsl files. Thus we can
not release the resources associated with the xsl files.

2, The temporary assembly files can not be removed while the
application is executing, since they are engaged by it. The TempFiles.Delete
method always fails within the application, consequently. And after
running the application for several times, the temp folder might be
piled up with the those temporary files.

Are there any approaches to solve these problems?
--
Best Regards,
W. Jordan

Apr 27 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
This might be what you are looking for:
http://forums.microsoft.com/MSDN/Sho...67635&SiteID=1

--
Stan Kitsis
Program Manager, XML Technologies
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"W. Jordan" <wm******@163.com> wrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Hello there,

Are there anybody who is using the XslCompiledTransform that comes
with .net framework, which was said to be a replacement of the
XslTransform class?

I found that the class has some issues when the xsl file contains scripts.

The XslCompiledTransform uses the CodeDom to compile the scripts
within the xsl file into .net assembly and load them into the current
AppDomain. Some temporary files would be generated during the
compilation in the temp folder.

This behavior leads to two issues.

1, The memory consumption of the current AppDomain, i.e. the
working application keeps growing up if we compile more and more
xsl files that contain scripts. We have no way to identify the assembly
generated from the compiled scripts within the xsl files. Thus we can
not release the resources associated with the xsl files.

2, The temporary assembly files can not be removed while the
application is executing, since they are engaged by it. The
TempFiles.Delete
method always fails within the application, consequently. And after
running the application for several times, the temp folder might be
piled up with the those temporary files.

Are there any approaches to solve these problems?
--
Best Regards,
W. Jordan


Apr 28 '06 #2

P: n/a
Hello,

Thanks for pointing out that.

Actually I really suspect that whether the XslCompiledTransform should
replace the old XslTransform class, which looks lightweight and easier to
manipulate. If we cache the XslTransform objects into the memory,
just as we (they did in the discussion in the forums) might do in our
practices, once the XslTransform is loaded, it is there. And there won't
be any trash files in the temp folder, nor will the memory consumption
increase as we load (reload) more and more stylesheets--yes, in my
ASP.net application, we have the application automatically reload the xsl
files if they are modified during the runtime. The auto-reload, but
non-memory-
leak feature is quite important for ASP.net applications which are expected
to run long. If we use the XslCompiledTransform class, this won't be a
viable approach since every time we reload the stylesheet, the memory
consumption increases and after several scores of reloading, the ASP.net
application will hog a monstrous amount of memory, which is obviously
neither desirable nor necessary.

So, I personally will turn back and stick to the lagacy one, XslTransform
class, for not having to clean up temp files, nor worrying about memory
consumptions.
--
Best Regards,
W. Jordan

"Stan Kitsis [MSFT]" <sk***@microsoft.com> wrote in message
news:44********@news.microsoft.com...
This might be what you are looking for:
http://forums.microsoft.com/MSDN/Sho...67635&SiteID=1

--
Stan Kitsis
Program Manager, XML Technologies
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no
rights. Use of included script samples are subject to the terms specified
at http://www.microsoft.com/info/cpyright.htm
"W. Jordan" <wm******@163.com> wrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Hello there,

Are there anybody who is using the XslCompiledTransform that comes
with .net framework, which was said to be a replacement of the
XslTransform class?

I found that the class has some issues when the xsl file contains
scripts.

The XslCompiledTransform uses the CodeDom to compile the scripts
within the xsl file into .net assembly and load them into the current
AppDomain. Some temporary files would be generated during the
compilation in the temp folder.

This behavior leads to two issues.

1, The memory consumption of the current AppDomain, i.e. the
working application keeps growing up if we compile more and more
xsl files that contain scripts. We have no way to identify the assembly
generated from the compiled scripts within the xsl files. Thus we can
not release the resources associated with the xsl files.

2, The temporary assembly files can not be removed while the
application is executing, since they are engaged by it. The
TempFiles.Delete
method always fails within the application, consequently. And after
running the application for several times, the temp folder might be
piled up with the those temporary files.

Are there any approaches to solve these problems?
--
Best Regards,
W. Jordan



Apr 29 '06 #3

P: n/a
I agree with the last post. Stick to XsltTransform being cached in Memory using HttpRuntime.Cache, and having dependencies on the Xslt files.

See http://xsltfilter.tigris.org/ for an opensource project that does exactly this.

The project is called XsltFilter and it has been in use on many sites for over 2 years.

You can either use it as a Filter on an ASP.NET output stream, or simply call the XsltTransform Factory class to manage your XsltTransform class instances.

woric
May 17 '06 #4

P: n/a
I don't think there is any difference between obsolete XslTransform and
XslCompiledTransform with regards to scripts. XslTransform leaks the
same way, see http://support.microsoft.com/?id=316775. And this has
nothing to do with XslCompiledTransform, you just cannot unload assembly
in .NET.

Use extension objects instead of scripts.

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

W. Jordan wrote:
Hello,

Thanks for pointing out that.

Actually I really suspect that whether the XslCompiledTransform should
replace the old XslTransform class, which looks lightweight and easier to
manipulate. If we cache the XslTransform objects into the memory,
just as we (they did in the discussion in the forums) might do in our
practices, once the XslTransform is loaded, it is there. And there won't
be any trash files in the temp folder, nor will the memory consumption
increase as we load (reload) more and more stylesheets--yes, in my
ASP.net application, we have the application automatically reload the xsl
files if they are modified during the runtime. The auto-reload, but
non-memory-
leak feature is quite important for ASP.net applications which are expected
to run long. If we use the XslCompiledTransform class, this won't be a
viable approach since every time we reload the stylesheet, the memory
consumption increases and after several scores of reloading, the ASP.net
application will hog a monstrous amount of memory, which is obviously
neither desirable nor necessary.

So, I personally will turn back and stick to the lagacy one, XslTransform
class, for not having to clean up temp files, nor worrying about memory
consumptions.

May 17 '06 #5

P: n/a
wo***@woric.net wrote:
I agree with the last post. Stick to XsltTransform being cached in Memory using HttpRuntime.Cache, and having dependencies on the Xslt files.


There should be really serious reason to stick with old buggy slow
officially obsoleted piece of code.

--
Oleg Tkachenko [XML MVP, MCAD]
http://www.XmlLab.Net | http://www.XLinq.Net | http://blog.tkachenko.com
May 17 '06 #6

P: n/a
Hello,

I set up a smaller environment and tested with two simple XSLT files.
One had a small script inside and the other one did't.

The consumption of memory goes up as you said and I observed that
the Bytes of the Loader Heap of the process was increasing everytime
I did trasformations with the XSLT file that has a script.

The memory leaks in XSLT with scripts are not yet fixed in .net 2.0.
And actually this is my real headache. I don't wanna compel others to
use extension objects instead of scripts, yet the loaded script can not be
unloaded as you have said. Perhaps a separated AppDomain is the
way to go, if we are to have the application to survive a little longer and
keep its memory consumption at a reasonable level.

Thanks for all that has replied.
--
Best Regards,
W. Jordan

"Oleg Tkachenko [MVP]" <so**@body.com> wrote in message
news:Oq**************@TK2MSFTNGP03.phx.gbl...
I don't think there is any difference between obsolete XslTransform and
XslCompiledTransform with regards to scripts. XslTransform leaks the same
way, see http://support.microsoft.com/?id=316775. And this has nothing to
do with XslCompiledTransform, you just cannot unload assembly in .NET.

Use extension objects instead of scripts.

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

W. Jordan wrote:
Hello,

Thanks for pointing out that.

Actually I really suspect that whether the XslCompiledTransform should
replace the old XslTransform class, which looks lightweight and easier to
manipulate. If we cache the XslTransform objects into the memory,
just as we (they did in the discussion in the forums) might do in our
practices, once the XslTransform is loaded, it is there. And there won't
be any trash files in the temp folder, nor will the memory consumption
increase as we load (reload) more and more stylesheets--yes, in my
ASP.net application, we have the application automatically reload the xsl
files if they are modified during the runtime. The auto-reload, but
non-memory-
leak feature is quite important for ASP.net applications which are
expected
to run long. If we use the XslCompiledTransform class, this won't be a
viable approach since every time we reload the stylesheet, the memory
consumption increases and after several scores of reloading, the ASP.net
application will hog a monstrous amount of memory, which is obviously
neither desirable nor necessary.

So, I personally will turn back and stick to the lagacy one, XslTransform
class, for not having to clean up temp files, nor worrying about memory
consumptions.


May 21 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.