msxsl:script blocks and non-default assemblies - inconsistency?

msxsl:script blocks and non-default assemblies - inconsistency?

Post by Alejandro Calbaza » Fri, 04 Jul 2003 23:11:33



Hello,

I am experiencing an inconsistency with non-default assemblies under
msxsl:script blocks.

According to the docs
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgu...),
non default assemblies are available to script blocks so long as the
class is fully qualified with the namespace.  This works only in the
case of System.IO and not for other assemblies.  System.IO, according
to the docs, is not a part of the default assembly.

The following is an example of a script block that does not work:

<xsl:stylesheet
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:msxsl="urn:schemas-microsoft-com:xslt"
        xmlns:dcl="http://www.mortgageramp.com"
        xmlns:vb="urn:vb:xslt"        
        version="1.0">

  <msxsl:script language="VB" implements-prefix="vb">

    <![CDATA[

                Function test()
                                Dim o As System.Web.Page
                            Dim s As String
                                o = New System.Web.HttpUtility()
                                        s = System.Web.HttpUtility.HtmlDecode("&gt;")
return s
                                End Function
                ]]>
  </msxsl:script>
</xsl:stylesheet>

This code snippet reports that the class can not be found.

I understand that the workaround is to use extension objects.  I
prefer this approach.  But this condition makes me wonder what a
developer is to do when they do not have access to the transform code
in order to add extension objects and only have the stylesheet to work
with.

I am not concerned about custom assemblies in this particular
situation.  Although, I am curious as to how custom assemblies would
work since System.Data and System.Web are in the GAC, should be able
to be referenced, but return errors.

Is accessing non-default assemblies something that is supported in the
current framework or not?

Thanks,

Alejandro

 
 
 

msxsl:script blocks and non-default assemblies - inconsistency?

Post by Dare Obasanj » Sat, 05 Jul 2003 02:47:06


Does your project have a reference to System.Web.dll? I seems you are
confusing namespaces and assemblies.

--
This posting is provided "AS IS" with no warranties, and confers no rights.


Quote:> Hello,

> I am experiencing an inconsistency with non-default assemblies under
> msxsl:script blocks.

> According to the docs

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgu...
ml/cpconxsltstylesheetscriptingusingmsxslscript.asp),
Quote:> non default assemblies are available to script blocks so long as the
> class is fully qualified with the namespace.  This works only in the
> case of System.IO and not for other assemblies.  System.IO, according
> to the docs, is not a part of the default assembly.

> The following is an example of a script block that does not work:

> <xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:msxsl="urn:schemas-microsoft-com:xslt"
> xmlns:dcl="http://www.mortgageramp.com"
> xmlns:vb="urn:vb:xslt"
> version="1.0">

>   <msxsl:script language="VB" implements-prefix="vb">

>     <![CDATA[

>                 Function test()
>         Dim o As System.Web.Page
>         Dim s As String
>         o = New System.Web.HttpUtility()
> s = System.Web.HttpUtility.HtmlDecode("&gt;")
> return s
> End Function
>                 ]]>
>   </msxsl:script>
> </xsl:stylesheet>

> This code snippet reports that the class can not be found.

> I understand that the workaround is to use extension objects.  I
> prefer this approach.  But this condition makes me wonder what a
> developer is to do when they do not have access to the transform code
> in order to add extension objects and only have the stylesheet to work
> with.

> I am not concerned about custom assemblies in this particular
> situation.  Although, I am curious as to how custom assemblies would
> work since System.Data and System.Web are in the GAC, should be able
> to be referenced, but return errors.

> Is accessing non-default assemblies something that is supported in the
> current framework or not?

> Thanks,

> Alejandro


 
 
 

msxsl:script blocks and non-default assemblies - inconsistency?

Post by Prajakta Joshi [MSFT » Sat, 05 Jul 2003 02:51:43


Are you referencing System.Web.Dll while building your source code?

--
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/copyright.htm.

Quote:> Hello,

> I am experiencing an inconsistency with non-default assemblies under
> msxsl:script blocks.

> According to the docs

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgu...
ml/cpconxsltstylesheetscriptingusingmsxslscript.asp),
Quote:> non default assemblies are available to script blocks so long as the
> class is fully qualified with the namespace.  This works only in the
> case of System.IO and not for other assemblies.  System.IO, according
> to the docs, is not a part of the default assembly.

> The following is an example of a script block that does not work:

> <xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:msxsl="urn:schemas-microsoft-com:xslt"
> xmlns:dcl="http://www.mortgageramp.com"
> xmlns:vb="urn:vb:xslt"
> version="1.0">

>   <msxsl:script language="VB" implements-prefix="vb">

>     <![CDATA[

>                 Function test()
>         Dim o As System.Web.Page
>         Dim s As String
>         o = New System.Web.HttpUtility()
> s = System.Web.HttpUtility.HtmlDecode("&gt;")
> return s
> End Function
>                 ]]>
>   </msxsl:script>
> </xsl:stylesheet>

> This code snippet reports that the class can not be found.

> I understand that the workaround is to use extension objects.  I
> prefer this approach.  But this condition makes me wonder what a
> developer is to do when they do not have access to the transform code
> in order to add extension objects and only have the stylesheet to work
> with.

> I am not concerned about custom assemblies in this particular
> situation.  Although, I am curious as to how custom assemblies would
> work since System.Data and System.Web are in the GAC, should be able
> to be referenced, but return errors.

> Is accessing non-default assemblies something that is supported in the
> current framework or not?

> Thanks,

> Alejandro

 
 
 

msxsl:script blocks and non-default assemblies - inconsistency?

Post by Alejandro Calbazan » Sat, 05 Jul 2003 04:55:04


Yes.  Even when with the reference added to the calling code (the app
which kicks off the transform) it fails.  Other than that, I am not sure
how a script would resolve a reference to an assembly?!

You are correct, I did confuse namespace and assembly.

Thanks,

Alejandro

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

 
 
 

1. Returning non-escaped strings from an msxsl:script function

Hi

I have some characters in XML which are appearing as little blocks in HTML when I
transform them using XSLT. Characters such as right single quotation and so on.

I understand how to insert them directly in XSL by using the xsl:text tag with
output escaping disabled, but how do I do it when the character is in the XML
input? I can't seem to convert them in any way, not even with an msxsl:script
block.

How can I return a non-escaped entity reference from an msxsl:script block to
insert into the resultant HTML? It always gets escaped, so I end up with
&amp;nbsp; or whatever, on the screen.

Ta,

Wangchuk

2. Wanted FAT32 IFS for OS/2

3. Non-default namespace in the OPENXML

4. Data Communications Cabling FAQ

5. msxsl namespace uri (for msxsl:script) in MSXML2?

6. copying files over net

7. <msxsl:script> vs. <xsl:script>

8. @@Probs With Plextor Help Needed@@

9. msxsl:script vs. xsl:script

10. script limitations in msxsl:script

11. XML load non-blocking? Help needed desperately!

12. xml/css containing block defaults

13. Xalan-C++: Escaping script blocks in CDATA sections