Feature #4468


.NET API: mechanism to bind URI to class containing extension functions

Added by Michael Kay about 2 years ago. Updated over 1 year ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:


As illustrated by bug #4463, it can be frustrating on .NET to get dynamic loading working for extension functions: there are too many ways of getting the security settings wrong.

It would therefore be a good idea to expose in the API the mechanism that already exists for binding a URI to a class containing such functions. For example

Processor.BindExtensions(string uri, System.Type type)

The implementation can use

DotNetExtensionLibrary dotNetLib =  ((ProfessionalConfiguration) config).getExtensionBinder("clitype");
dotNetLib.declareDotNetType(uri, type);

After this, the stylesheet/query can use the specified URI to invoke methods defined on this class.

Actions #1

Updated by O'Neil Delpratt about 2 years ago

  • Status changed from New to In Progress
  • Applies to branch 9.9, trunk added

I have started working on adding this method to the .NET API. There seems to be some underlying problem with the mechanism therefore investigating it further.

Actions #2

Updated by O'Neil Delpratt almost 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100
  • Fix Committed on Branch 10, trunk added

Bug fixed as suggested in comment #0 by adding the BindExtensions method to the Processor object. Also added the interfacing method bindExtensions on the Configuration as a stub. Implementation added on the ProfessionalConfiguration for Saxon-PEN and SAxon-EEN.

Available for the next release of Saxon .NET.

Actions #3

Updated by Debbie Lockett over 1 year ago

Documentation under extensibility/dotnetextensions updated (as suggested over email) to suggest use of Processor. BindExtensions as alternative to dynamic loading.

Actions #4

Updated by O'Neil Delpratt over 1 year ago

Bug fix applied in the Saxon 10.3 maintenance release

Actions #5

Updated by O'Neil Delpratt over 1 year ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 10.3 added

Please register to edit this issue

Also available in: Atom PDF