[.NET] <msxsl:script> and XsltArgumentList.AddExtensionObject interaction

[John Doe]

Hi,

I would like to call some AddExtensionObject-provided object method
from a script located inside a <msxsl:script> tag, like this :

XslTransform trans = new XslTransform();
trans.Load(...);
XsltArgumentList args = new XsltArgumentList();

class Foo
{
public string Bar()
{
return " world !";
}
}

Foo foo = new Foo();

args.AddExtensionObject("urn:foo", foo);

<msxsl:script language="C#" implements-prefix="user">
public string MyFunction()
{
// Would like to call Foo.Bar from here
// but don't know how to do it !
return "Hello " + getThisObject("urn:foo").Bar();
}
</msxsl:script>

<xsl:template ...>
<xsl:value-of select="user:MyFunction()"/>
</xsl:template>

MSXML 4.0 does allow embedded scripts to access external objects since
they are passed via xsl:param's.

Isn't there any way to do it with XslTransform ?

Thank you !
-J

[Oleg Tkachenko]

Post by John Doe
I would like to call some AddExtensionObject-provided object method

It's kinda strange approach and honestly speaking I cannot see how it
can be done. What's the point to have both embedded script and extension
objects?

[John Doe]

Post by Oleg Tkachenko

Post by John Doe
I would like to call some AddExtensionObject-provided object method

It's kinda strange approach and honestly speaking I cannot see how it
can be done. What's the point to have both embedded script and extension
objects?

Embedded scripts do not require previous compilation, keeping users
wanting to quickly add stylesheets to my program happy. Extension
objects do. Interaction between the two is kinda obvious.

There is no way to debug msxsl: scripts either. Don't you think this
is strange too ? Inline script debugging used to work fine with
MSXML3/4 and Visual Interdev 6.

[Kirk Allen Evans [MVP]]

They are processed very differently by the .NET framework, and you should
refrain from using msxsl:script elements within XSLT parsed by managed code.
See Q316775 [1], the assembly cannot be unloaded correctly and may lead to a
memory leak. There are several design patterns that you can use to mitigate
the changes, including dynamically loading an assembly that contains your
extension objects.

[1] http://support.microsoft.com/default.aspx?scid=kb;EN-US;316775
--
Kirk Allen Evans
Microsoft MVP, ASP.NET
XmlInsider
www.xmlandasp.net
Read my web log at http://weblogs.asp.net/kaevans

Post by John Doe

Post by Oleg Tkachenko

Post by John Doe
I would like to call some AddExtensionObject-provided object method

It's kinda strange approach and honestly speaking I cannot see how it
can be done. What's the point to have both embedded script and extension
objects?

Embedded scripts do not require previous compilation, keeping users
wanting to quickly add stylesheets to my program happy. Extension
objects do. Interaction between the two is kinda obvious.
There is no way to debug msxsl: scripts either. Don't you think this
is strange too ? Inline script debugging used to work fine with
MSXML3/4 and Visual Interdev 6.

[John Doe]

Thanks for the pointer Kirk.

I also don't manage to reference static members defined in the hosting
assembly. This is also weird, because the documentation seems to state
any assembly can be accessed, you just need to use fully qualified
names. Eg. this doesn't work :

Hosting assembly (using XslTransform) :

namespace MyNS
{
class MyClass
{
public static string MyString = "Hello world";
}
}

Stylesheet :

<msxsl:script language="C#" implements-prefix="user">
public string Foo()
{
return MyNS.MyClass.MyString;
}
</msxsl:script>

<xsl:template ...>
<xsl:value-of select="user:Foo()"/>
</xsl:template>

The XslTransform lacks the mecanism of manual referencing of
assemblies, a bit like with VSA.

Extension objects also solve the debugging problem.

Post by Kirk Allen Evans [MVP]
They are processed very differently by the .NET framework, and you should
refrain from using msxsl:script elements within XSLT parsed by managed code.
See Q316775 [1], the assembly cannot be unloaded correctly and may lead to a
memory leak. There are several design patterns that you can use to mitigate
the changes, including dynamically loading an assembly that contains your
extension objects.
[1] http://support.microsoft.com/default.aspx?scid=kb;EN-US;316775
--
Kirk Allen Evans
Microsoft MVP, ASP.NET
XmlInsider
www.xmlandasp.net
Read my web log at http://weblogs.asp.net/kaevans

Post by John Doe

Post by Oleg Tkachenko

Post by John Doe
I would like to call some AddExtensionObject-provided object method

It's kinda strange approach and honestly speaking I cannot see how it
can be done. What's the point to have both embedded script and extension
objects?

Embedded scripts do not require previous compilation, keeping users
wanting to quickly add stylesheets to my program happy. Extension
objects do. Interaction between the two is kinda obvious.
There is no way to debug msxsl: scripts either. Don't you think this
is strange too ? Inline script debugging used to work fine with
MSXML3/4 and Visual Interdev 6.