views:

122

answers:

2

I'm working on a .NET 1.1 assembly that does a number of huge XSL transforms. This is beginning to cause memory problems. I therefore want to use the XSLT engine in the .NET 2.0 framework, since I know it is much more efficient and less resource intensive. Note: Upgrading the .NET 1.1 assembly to .NET 2.0 is NOT an option at this time, due to time and budget constraints (beyond my control).

I've written a .NET 2.0 assembly that can do XSL transforms, and exposed it as a COM+ interop object. When I load this object from the .NET 1.1 assembly, it loads fine, but as soon as I load the XSL transform, an exception occurs, and it doesn't contain ANY useful information as to what went wrong.

Interestingly, if I call a simpler, unrelated test method in the .NET 2.0 assembly (like a method that just writes to the eventlog instead of doing a transform), it seems to work.

Any ideas on alternative approaches? Or is there something obvious I'm doing wrong?

Any help would be greatly appreciated! Thanks!

A: 

I'd suspect that COM interop alone kills any performance enhancement you'd get out of the upgrading the XSLT to 2.0. Probably also has something to do with the useless exception.

Have you tried running the 1.1 assembly under 2.0? See this page for instructions on how to target a specific version of the framework. I'm not terribly familiar with the underlying XSLT engines, but just switching the target might get you 2.0's toys there, and it will definitely get you 2.0 performance.

Wyatt Barnett
Unfortunately trying to run under .NET 2.0 has proved fruitless. The system is just too big to be able to just switch the target. Multiple parts fail when this is done. Sadly it's beyond my control. Thanks anyway!
A: 

Consider Process.Start() on the msxsl.exe tool. It does not use .NET. Or, if you are doing COM interop anyway, consider MSXML - it does XSL too, and it's FAST.

Cheeso
Thanks. I'm now considering command line, but not sure yet if I want to use msxml/msxsl, or write a command line .NET 2.0 app to do the work.
maybe benchmark MSXML6 vs System.Xml. The MSXML component has always been fast and efficient, even when called from Javascript or VBScript - most of the work for an XSLT is done in compiled C++ code within MSXML. And try the MSXML6 NewParser property, too. http://msdn.microsoft.com/en-us/library/ms767616.aspx . I think using msxsl.exe uses MSXML3 or 4. (not 6)
Cheeso
If the system is "really big" - too big to switch over to .NET 2.0, look at using an approach that lends itself to scale. Breaking the XSLT out into a separate process might not be such a bad idea. Maybe make it a Windows Service that listens on a named-pipe for socket comms.
Cheeso