Saxon

I believe it's correct that there's no way currently to do this.

I can see two possible ways forward.

The first is to use some kind of dynamic loading mechanism - whether assemblies are identified directly on the command line, or via environment variables, or in a configuration file, the essential problem is the same: we need to load an assembly given some kind of name that identifies it, and then we need to poke inside it to see what types it contains. This seems to be feasible but rather complex, and I'm a bit hesitant about the amount of effort needed (a) to make it work, and (b) to support it in the field. (I've been reading up on the dependency injection framework in .NET Core, and it's not obvious that it helps much with the problem.)

The second is to allow a user application to offer a command line interface which mimics the Saxon command line interface, but contains code for initialization the configuration (for example, by registering extension functions). This is similar to the mechanism we offer on Java where net.sf.saxon.Transform can be subclassed. This feels as if it's likely to be easier from our perspective, though not necessarily easier for the user.

I can't judge the complexity of going with the first approach as I don't understand enough about dynamic assembly loading or dependency injection.

As for the second approach, it is true that for an end user of the command line tool of SaxonCS going to write C#/.NET code is a hurdle but I think for extension library authors it would be rather easy, if there is a subclassing way, to create a SaxonCS command line tool derivation with the extension library present. And whether it is invisible XML or other stuff where perhaps a C# extension library is more powerful than one done in XSLT, I think that having command line tools to experiment with and even regularly use them is important. On the other hand, if every library author who wants to provide a command line tool needs to reimplement the SaxonCS transform/query functionality, it would be some kind of unnecessary effort if a reuse by subclassing is all that is needed.

The following tutorial suggests how we might go about meeting this requirement:

https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support

Using the above link, I have done a successful proof-of-concept showing how to implement an external -init hook calling an assembly referenced by filename on the command line.